广告业务查数最怕“SQL 能跑、结果不对”。比如“每天符合在投条件的广告计划里，实际花费最多的是哪一个？”
这是广告运营里很常见的一句查数需求。要答对这个问题，我们得先知道问题里没写出来的规则，如哪些计划算“在投”，实际花费要扣掉哪些费用，金额并列时取哪一条。这些规则很少完整写在数据库列名里，它们通常分散在业务文档、代码逻辑、配置约定和历史口径里。
火山引擎 ContextSearch 给负责查数的 Query Agent 补上了这层业务上下文，仅声明业务文档和代码库两项知识来源，查询分析效果就从 36.8% 提升到 98.7%。
ContextSearch 是 AI Agent 的智能搜索服务，在本实践中核心使用了以下能力：
- Agentic Search（智能体搜索）： Agent 围绕任务检索资料，再根据已经查到的结果决定下一步还要查什么。
- 统一语义上下文层（下文简称统一语义层）： 把业务说法和数据库里的字段、取值、来源对应起来。比如用户说“只看在投计划”，它帮 Agent 找到“哪些状态算在投”的说明，再落到具体的状态列和筛选条件上。
Query Agent 先通过统一语义层找到相关的业务规则和字段依据，再生成 SQL、查询数据并解释结果。下文说的“知识增强”，就是指 Query Agent 接入统一语义层；关闭知识增强时，它只拿到问题和目标表说明。
01 业务规则藏在文档和代码里
查数据不能只看数据库的列名。哪些记录该算、特殊取值怎么理解，都由业务规则决定，而这些规则分散在两类资料里：业务文档写明统计口径，业务代码在写入数据时实际执行规则。
两类资料往往要合起来看，有些规则甚至只写在代码里：
缺了任何一类，查询语句照样能执行，结果却可能是错的。不同的查数任务，要先弄清的规则也不一样：
同样是“查计划数”，不同任务统计的对象和范围可能并不相同，Agent 如果没有这些业务规则，结果就会偏。
02 ContextSearch 把业务规则变成 Agent 可检索的上下文
我们不要求业务团队重新整理一套知识库，整个方案只需要做一件事：声明业务文档和代码库两项知识来源。之后，统一语义层负责把它们变成 Agent 能用的知识；用户照常用业务语言提问，Agent 在生成 SQL 前，先去找这次问题相关的口径、字段、取值和计算规则。
统一语义层负责“有什么知识”
- 数据纳管： 接入业务文档和代码库，只需声明来源。
- 知识治理： 自动从文档中提取统计口径、从代码中整理字段含义，并随资料更新持续维护；来源未确认的信息留作缺口，不靠推测补全。
- 知识发现： 把业务说法对应到数据，例如“在投计划”对应哪个字段、哪个取值。
- 搜索： 按用户的问题，找到这次查询真正需要的知识。
Agentic Search 负责“查什么、怎么用”
Agentic Search 的工作过程是让 Query Agent 围绕查数任务自主推进：
- 拆解问题： 把“每天在投计划里，实际花费最多的是哪一个”拆成“在投怎么判断”、“实际花费怎么算”、“并列取哪条”几件事，分别去统一语义层检索。
- 自主闭环： 按“感知—决策—执行—反思”循环推进，知识不够就继续补查，SQL 报错或结果异常就回头调整。
- 给出答案： 把检索到的规则和查询结果整合成带依据的回答，而不是把线索留给用户自己拼。
03 示意：一个自然语言问题，如何变成正确查询
回到开头的问题：“每天符合在投条件的广告计划里，实际花费最多的是哪一个？”
用户只说了三个业务概念，但每个概念背后都有规则：
- 在投条件： 需要找到文档或代码里对“在投”的定义，再落到具体状态字段和状态值。
- 实际花费： 需要确认花费字段是否已经扣减退款、返款或其他冲减项，必要时还要做金额单位换算。
- 最多的是哪一个： 需要按天分组排序，并处理金额并列时的取数约定。
关闭知识增强时，Agent 只能根据问题和目标表说明推断这些规则。开启知识增强后，Agent 会先检索相关口径，再把规则写进查询条件。SQL 生成后，Agent 会以只读方式执行，并根据返回结果或报错修正查询；资料不足时，会明确说明缺少什么。
04 实测：正确率从 36.8% 提高到 98.7%
对比测试在自建的广告计划日报数据上进行。团队准备了 76 道业务问题，分别让 Query Agent 在开启和关闭知识增强时回答，两组测试拿到的问题和目标表说明完全相同。
结果由人工核验，检查筛选条件、统计方式和执行结果。这里的 SQL 业务正确率，不只看语句能不能执行，还要看是否按业务约定算对。
耗时和调用次数下降，主要是因为开启增强后，Agent 先去查“怎么算、用哪一列”的说明，不再靠一条条 SQL 去试探数据含义。
错误减少在哪里
第一道题要的是：每天在投的计划里，花费最高的那个。
- 关闭增强时： Agent 把“当天产生过花费”当成了“在投”，选出了已经停投的计划——8 月 1 日它选的计划花费 121.25 元，正确答案对应的计划只有 19.00 元，连续 7 天都选错。
- 开启增强后： 先限定在投、再比较花费，工具调用从 19 次降到 4 次，耗时直接减少了 85%。
第二道题要的是：某个投放渠道里，既允许在搜索页展示、又仍在投的计划数。“搜索可投”只表示允许展示，不等于在投。
- 关闭增强时： 漏掉了在投这个条件，把停投计划和用于验证的影子计划也算进去，8 月 1 日算成 8 条；
- 开启增强后： 补上在投条件，得到正确的 3 条。
这些例子说明，自然语言查数出错不一定是模型不会写 SQL，而是它缺了业务知识。把业务规则补进上下文，往往比让 Agent 多试几次 SQL 更有效。
05 知识整理一次，可以持续复用
对业务人员来说，不用先学表结构，也不用把业务问题翻译成字段名，照常提问即可。Agent 在回答里写清楚用了哪些关键规则，业务人员可以核对，也可以继续追问。
对数据和研发团队来说，可以减少重复解释。同一套数据含义、统计口径和字段约定，被整理成可检索的上下文后，可以被不同查询任务反复复用。
这套知识也不是一次建完就结束。回答出错时，系统会沿着文档和代码来源定位原因，补上或改正知识，再用同一组问题复测。这样，知识增强效果可以被持续验证，而不是停留在“感觉更懂业务”。
06 下一步：让业务直接治理知识
目前，知识的提取和维护已经自动化，团队只需声明知识来源。下一步，我们将提供面向业务的端到端知识干预与治理平台和工具，让真正掌握口径的人也能参与知识维护。
了解更多 ContextSearch 产品信息。
