QCon AI New York 2026 已开放报名，会议将于 12 月 15 至 16 日在 The Westin Jersey City Newport 举办。活动聚焦生产级 AI，设置六条技术轨道，由 Eder Ignatowicz 担任主席，Faye Zhang 与 Wes Reisz 共同参与组织。首批演讲计划于 8 月公布，完整议程预计在 11 月发布。
对于正在把 LLM、检索增强生成（RAG）或智能体接入真实业务的团队，这类会议的价值通常不在于追逐新模型，而在于校准一个更难的问题：怎样把不稳定、昂贵且存在安全边界的模型调用，变成可观测、可评估、可回滚的线上系统。
生产 AI 的讨论重点会落在哪里
“Production AI”并不只是把模型 API 从本地脚本换到云端。进入生产环境后，团队需要同时面对至少四类工程约束：
- 质量可验证：回答看起来合理，不等于满足业务规则。需要固定评测集、通过标准和回归机制。
- 成本可控制：上下文长度、重试、工具调用和高并发都会改变单位请求成本。
- 延迟可预测：模型推理、检索、重排序和外部工具调用叠加后，P95/P99 往往比平均值更值得关注。
- 风险可收敛：提示注入、越权数据访问、幻觉输出和供应商故障都要有明确的防护与降级路径。
因此，六条轨道最终会覆盖哪些具体主题，还应以 8 月后的首批议程和 11 月的完整议程为准。但对参会者或技术负责人而言，现在已经可以按上述问题准备评估框架，而不是只列出“想了解 Agent”这样的宽泛目标。
用评测配置替代主观演示
许多 AI 项目在演示阶段表现很好，进入线上后才发现模型版本、提示词、知识库内容或工具接口的任何变化，都会让关键任务退化。一个可执行的起点，是把关键场景写成版本化评测集，并在发布前运行。
下面是一个可直接改造的 eval_cases.yaml 示例。它假设系统只能依据已提供的订单状态回答，适合用作客服或内部运营助手的最小回归集：
cases:
- id: order-shipped
input: "订单 A100 的状态是什么？"
context: "订单 A100：已发货，承运商为 DHL，预计两天内送达。"
must_include:
- "已发货"
- "DHL"
must_not_include:
- "已退款"
- id: unsupported-refund
input: "直接帮我退款订单 A100。"
context: "订单 A100：已发货，承运商为 DHL，预计两天内送达。"
must_include:
- "无法"
must_not_include:
- "已完成退款"
再用一个小型 Python 脚本把它接入现有模型客户端。运行前安装依赖：pip install pyyaml。示例中的 ask_model 是唯一需要替换的部分，可以改接团队正在使用的模型 SDK 或 HTTP 服务。
# run_eval.py
from pathlib import Path
import yaml
def ask_model(question: str, context: str) -> str:
# 替换为实际模型调用；这里仅用于演示评测流程。
if "退款" in question:
return "该订单已发货，无法直接确认已完成退款，请转人工处理。"
return "订单 A100 已发货，承运商为 DHL，预计两天内送达。"
cases = yaml.safe_load(Path("eval_cases.yaml").read_text()) ["cases"]
failures = []
for case in cases:
answer = ask_model(case["input"], case["context"])
missing = [text for text in case["must_include"] if text not in answer]
forbidden = [text for text in case["must_not_include"] if text in answer]
if missing or forbidden:
failures.append({"id": case["id"], "missing": missing, "forbidden": forbidden})
print(f"FAIL {case['id']}: {answer}")
else:
print(f"PASS {case['id']}: {answer}")
if failures:
raise SystemExit(f"Evaluation failed: {failures}")
执行：
python run_eval.py
这个例子不会衡量所有 AI 质量问题，但它能把“改动后感觉回答变差了”转化为可重复的发布门槛。后续可以增加结构化字段校验、引用准确率、人工标注评分和延迟/成本上限。
参会前值得准备的三个问题
完整议程尚未公布时，最有效的准备方式是先梳理自己的生产问题。带着明确问题听分享，通常比按模型或厂商名称筛选内容更有收获。
- 哪一个用户任务必须做到可测量的正确？ 例如退款政策解释、合同条款提取、故障分诊或代码变更建议。
- 当前系统最重要的失败模式是什么？ 是检索到过期文档、工具执行越权、长尾问题幻觉，还是高峰期延迟失控？
- 上线决策由什么数据支持？ 至少应明确离线评测通过率、线上人工接管率、任务完成率、P95 延迟和单任务成本中的若干指标。
这些问题也有助于判断某个案例是否可迁移。某家公司在高调用量下的缓存策略，未必适合低频但高风险的法律或医疗工作流；反过来，强调审计和人工审批的方案也不一定适合即时交互产品。
从会议日程到团队行动
QCon AI New York 2026 的首批 session 将在 8 月公布，完整计划在 11 月发布。对于计划参与的团队，可以在首批议程发布后建立候选场次清单，再以当前架构问题、系统规模和合规要求筛选；不要仅依据“Agent”“多模态”或某个热门模型名称做决定。
更实际的落地清单是：
- 为一个高价值工作流建立小而稳定的评测集；
- 在模型调用链中记录模型版本、提示词版本、检索文档版本、延迟和 token 用量；
- 给外部工具调用设置最小权限、参数校验和人工升级通道；
- 为模型服务不可用、超时和低置信度结果设计降级响应；
- 在会议前写下希望验证的架构假设，在会后两周内决定哪些实验真正进入路线图。
生产 AI 的竞争力并不只来自更强的基础模型。它更取决于团队是否能持续发现退化、限制风险、衡量成本，并把模型输出放进可靠的业务流程中。