数据团队的新战场：上下文工程

还记得你的公司把 BI 工具直接连到生产数据库上的时候吗数据总是错的。没人信任那些仪表板——所以我们构建了数据栈来解决这个问题。今天的 AI 智能体就相当于直接连到生产数据库的 BI 工具。每个公司现在都有了内部 AI 智能体接入了原始上下文源网盘、Notion、邮件。它勉强能用但你不能完全信任那些答案。上下文工程是为了以可靠和高效的方式为所有公司知识创建真相来源。而这正是数据团队多年来一直在为数据做的事情。上下文工程需要数据团队拥有的核心技能上下文工程 数据治理 数据工程 数据科学上下文工程需要治理来定义上下文真相来源上下文工程需要工程来摄取和整合它们上下文工程需要科学来衡量和提升 AI 可靠性1、什么是上下文工程上下文工程旨在为 AI 智能体创建最优的上下文。什么是对智能体来说的最优上下文回答率智能体实际能回答的问题百分比准确率答案正确的百分比成本智能体产生的 LLM 费用速度智能体响应的速度需要优化的权衡是什么**上下文太少 → 答案错误或无法回答。**智能体知道的不够。它会幻觉、遗漏细微之处或者完全放弃回答。**上下文太多 → 昂贵且混乱。**输入 token 会让 LLM 账用快速飙升Claude Opus 4.5 中 100 万 token 是 5 美元。一个上下文密集的调用每次查询很容易发送 5-10 万 token大约 50 美分。除了成本之外不相关的上下文会稀释信号——模型会被噪音搞混。如何进行上下文工程选择要包含哪些来源排除哪些来源。澄清哪个内容是某个主题的真相来源正确定义、最新来源。有时你可能会发现自己一开始也不清楚。创建尚不存在的上下文。格式化上下文使模型能够高效解析它让它更模块化、结构化。简而言之上下文工程遵循与数据工程相同的原则衡量、迭代、优化。跟踪你智能体的表现。识别失败原因。添加缺失的上下文。测试改进。重复。2、上下文治理上下文真相来源就是新的数据真相来源。我们对上下文治理有着与数据治理相同的需求。我们需要数据治理因为没有它收入意味着三件不同的事情取决于你问谁。营销团队算的是总预订额。财务团队算的是净 ARR。产品团队算的是活跃订阅数。没有指标层没有规范定义——所以每个仪表板讲述不同的故事。今天我们需要上下文治理因为公司知识有完全相同的问题。问我们的退款政策是什么答案取决于智能体先找到哪个文档——过时的 Notion、最新的 Zendesk 回答还是法务上季度发在 Slack 里的消息。有时候没有人真正想过这个问题的正确答案是什么。很多数据人都经历过可怕的时期他们到一家公司发现 BI 直接接在生产数据库上。所有数据都在这里没有两个数字看起来一样一切都慢且痛苦。今天我们通过把 AI 接入整个公司知识库做着完全一样的事情。我们都知道公司知识充满了不准确、过时的内容和矛盾。所以把智能体直接接上这个混乱局面似乎不是最好的做法。我们需要的是一个上下文层一个单一的、被治理的、有版本的、公司知识的真相来源。智能体可能面临的每个问题的清晰答案。我们需要基础设施来构建和维护它。3、上下文工程上下文栈就是数据栈为了拥有数据真相来源我们构建了数据栈。 为了拥有上下文真相来源我们需要上下文栈。今天的情况和 10 年前的数据领域一样我们有来源有消费工具。但我们没有中间层没有上下文 ETL 层。我们需要摄取工具来自动拉取上下文来源转换工具来挑选上下文真相来源上下文层作为公司知识的真相来源编排以保持上下文的新鲜度AI 监控来衡量和跟踪我们的上下文在 AI 智能体中的表现一些数据团队已经开始内部构建这些组件了。我见过团队编写脚本来从仓库拉取模式元数据和概要统计、从数据目录同步文档、或从 BI 工具中整理经过验证的查询到 markdown 文件中。它有效——但需要大量的脚本和维护。监控更加落后。大多数分析智能体工具还不支持评估框架所以没有简单的方法来构建单元测试来验证你的上下文在更改后仍然产生正确的答案。一旦我们有了治理和栈我们需要使用我们的数据科学技术来迭代和改进我们的上下文。4、上下文科学像调优 ML 模型参数一样调优你的上下文。在 ML 中你定义一个成功指标准确率等并拥有标注数据的训练测试集。然后你调整参数、特征、训练集。你在每次更改后衡量表现直到找到最优值。在上下文工程中应该是相同的循环。你定义你的成功指标可靠性、成本等。你的参数是上下文真相来源、上下文格式化、工具。你可以创建提示词/预期答案的单元测试集。你更改上下文重新运行测试提示词衡量影响保留有效的部分。但需要攻克的额外问题是如何衡量你的指标→ 成本、速度很容易衡量但你需要更定制的工具来衡量智能体的可靠性检查使用的文件来源精确匹配LLM 作为评判者要做到这一点你需要为自己构建一个**评估框架**。定义你要跟踪的 KPI——什么是智能体成功如何衡量它还有哪些其他参数很重要成本、速度等。然后构建单元测试通过在不同上下文集上的表现来微调你的上下文。5、如何现在开始转型如你所见上下文栈还没有出现。我们仍然缺少工具来公开地整理和改进我们的上下文。我认为数据团队的第一步应该是在自己的范围内展示他们掌握了上下文工程你真的能为你分析智能体构建有效的上下文吗正如我在之前关于分析智能体基准测试的文章中所探讨的现成的解决方案不起作用而且它们是上下文黑盒。如果数据团队投资于他们自己的分析智能体的上下文工程我相信他们能够证明它比现成的智能体效果更好。两种设置已经可以用来开始上下文工程了文件系统 AI 智能体Cursor、Claude Code、Cowork、Codex、nao这些工具直接从你控制的文件中读取上下文。你可以确切地看到智能体知道什么通过编辑文件来改变它并立即衡量影响。此外你还可以在上面构建评估框架因为一切都通过代码可访问。内部智能体如果你构建了自己的智能体你控制整个上下文管道你想添加哪些上下文片段以及你打算如何评估你的智能体。创建一组提示词单元测试然后开始在不同的上下文场景中运行它们。原文链接数据团队的新战场上下文工程 - 汇智网