"张三上周跟'字节'的所有沟通记录，发我一下。"
"王五手里金额超过 100 万的商机，最近有啥进展？"
"'火山引擎'最近的续约意向有没有啥变化？"
在火山引擎客户经营平台 C360（Customer 360）上，每天都可以看到一线销售、销售管理者和运营在问这样的问题。听起来就是一次次普通检索，答案也就在系统里，可是关键词搜索却行不通，这是因为：
- "字节"可能指字节跳动，也可能指某家关联子公司；
- "上周"是相对时间，我们要先换算成日期；
- "续约意向有没有啥变化"的答案，我们要把对同一个客户最近的数条跟进记录读完，才能归纳总结好。
客户每一次拜访、每一轮沟通，都会被销售留在系统跟进记录里，作为管理者判断商机走向、发现流失风险时最依赖的数据。火山引擎 ContextSearch 团队基于 Agentic Search 改造了 C360 跟进记录的检索体验。经 200 道业务实际问答测试，Agentic Search 在整体正确率和可接受率上明显优于传统 RAG：正确率达到 84.0%，可接受率达到 90.0%，尤其在实体歧义处理场景、结构化精确查询和零答案问题上，正确率分别达到 91.7%、93.3% 和 100%。
本篇文章就聊三件事：关键词搜索及通用 RAG 在销售语料上为什么不好用？Agentic Search 靠怎样的链路把这些难题解决掉，以及用到业务里之后效果到底怎么样。
01关键词搜索在跟进记录上的三个难题
我们每个人的表达记录方式是不同的，所以跟进记录不可能按标准字段填写，销售用自己的话记录进展，记录里有客户简称、产品缩写、口语化描述和相对时间，还夹着合同附件、聊天截图、会议照片等等。
传统关键词搜索在这类语料上天然存在着三个躲不过去的难题：
- 语义鸿沟： 搜"字节跳动"，搜不到只写了"字节"的记录；"上周""上个季度"这类相对时间系统不认识；产品缩写和销售口语基本等于零召回。
- 信息孤岛： 关键词只匹配正文中的文本内容，技术对接人、图片和备注里的关键信息可能在合同附件里，搜索做不到精准到位。
- 上下文断裂： 一个商机往往跟进数月、来回十几轮沟通，关键词搜索只能返回零散片段信息，没法围绕"这个客户"建立一个完整的过程。
如针对开头提到的每个查询，要实现正确的回复，都需要直面多个挑战：
02通用 RAG 解决了"相似"，却没解决"准确"
RAG 比关键词进一步：它能做语义匹配，让大模型基于召回的片段组织回答。对照三个难题看，它的能力边界很清楚------"字节跳动"能召回"字节"，语义鸿沟被部分填平；但信息孤岛和上下文断裂依旧，片段还是片段、问答仍是单轮。更关键的是，销售语料里有三道业务硬约束，通用 RAG 很难同时满足。
- 强业务语义。 问题里的客户、人员、团队、商机都是业务实体，这当中简称、同名、集团上下级公司充满了歧义。我们把"字节"向量化成一段语义，代替不了精确判断，我们还是无法确定"这个词在业务库里到底指哪家公司"的。
- 强权限约束。 销售只能看自己名下的客户，管理者能看整个团队，数据边界被业务系统定下了。权限必须在检索环节就生效，越权数据不召回；等答案生成后再删，来不及也不可靠。
- 强统计口径。 "华东区本季度跟进次数前十的客户"这类问题，答案要按明确口径从结构化数据里算出来，不能让大模型随便就从片段里估计出一个。
Agent 在这里有具体含义：系统自己承担"理解问题、拆解步骤、选择数据源、执行检索、组织证据"这条认知链路，承接了原来丢给用户的拼图工作。这也是 Agentic Search 和"接了大模型的搜索框"最根本的区别。
03Agentic Search 的完整链路
用户的每一次提问，实际上后台走的都是一条带反馈的完整链路：问题进来先做业务意图理解，再由实体对齐和提前建好的业务知识库共同支撑多路检索与过滤，结果按权限返回并附上证据，最后进入持续评测，反哺下一轮检索。
图一：Agentic Search 跟进记录场景业务链路
业务意图理解
Agent 拿到问题先分类：查明细，比如最近谁拜访过这个客户；做统计，比如某团队本季度跟进了多少次；做分析，比如这个客户有没有流失风险、对某款产品感不感兴趣。相对时间、客户简称、团队的口语叫法，都在这一步转成稳定的查询条件。
实体对齐
平台为客户、人员、团队、商机建了独立的实体库，支持拼音、中英文缩写、曾用名、关联公司等多维别名，配合专用的命名实体识别与纠错模型。"字节"指哪家公司由实体库判定，同名客户、集团上下级公司也能区分开。遇到名称或范围有歧义、答错代价高的情况，Agent 会先反问确认，而不是硬给一个可能误导人的答案。
业务知识库
业务知识库在用户提问前就建好了，检索时与实体对齐并行调用。跟进记录、客户信息、人员与组织关系统一接入，形成面向销售场景的业务知识库，查询口径与源业务系统保持一致。数据时效按两档保障：跟进记录分钟级增量同步，每天再做一次全量校准，上午写的记录下午就能被搜到。
多路检索与证据生成
关键词匹配、语义理解、结构化约束三条路并行。针对"上下文断裂"，检索结果按跟进人、客户 ID 聚合，把跨数月的十几轮沟通还原成一条完整时间线，而不是返回零散片段。明细类问题在时间线上定位原始记录，统计类问题走结构化约束按口径计算，分析类问题基于聚合后的记录归纳。每条结论都能溯源到具体数据（Grounding），用户可以顺着引用回去核对，大模型幻觉在这里没有多少空间。
权限过滤
所有查询沿用业务系统既有的权限体系（ACL），在检索阶段完成过滤，只返回当前用户有权查看的数据；检索链路完整留痕、可审计。人员转岗、客户移交后的权限变更随业务系统同步生效。
接入成本也压得很低：业务系统通过标准的 context-search-agent Skill 对接，只需配置 api_key 和 base_url 即可启用，不用改造现有数据链路。
至此，前面的提到传统搜索及通用 RAG 在销售语料上的难题和约束都有了明确的承接环节：
04业务效果
业务侧与 ContextSearch 团队共建了一套 200 道题的标准离线评测集，题目来自业务实际提问，覆盖精确查询、语义证据、零结果、歧义澄清等类型。经过测试，Agentic Search 的整体正确率高于传统检索增强方案。收益最明显的是这三类题：带精确条件的明细查询、客户与人员重名简称的歧义处理、按业务口径计算的统计问题。 开放式语义分析没有一味追求"模型说了算"，而是结论和证据结合，一起给出让销售自己判断答案是不是可行。
业务围绕着跟进记录检索和分析展开，9 月中旬统计，数据规模的覆盖已达到如下量级：
- 数百万级： 跟进记录样本，覆盖多年历史沟通信息
- 百万级： 客户覆盖，支持客户维度查询、统计与风险线索发现
- 千级： 销售与跟进人员，支持个人、团队、组织范围分析
ContextSearch 让 Agent 的每个判断都基于可追溯的跟进事实 ，把 C360 平台沉淀的数据真正变成了销售决策和行动的输入，当前已在风险预警、洞察提炼、能力传承等多类销售核心场景落地应用：
- 季度续约盘点： Agent 调出跟进记录，识别出"销售一直汇报、但是决策人三周没回复"的停滞客户，从而提前预警、推动干预，防流失。
- 新品反馈洞察： 新产品上线一个月后，Agent 归拢客户评价，提炼出"制造看权限、互联网看速度、销售不推"三个要点，从而优化点直接落到产品和话术。
- 新人交接： Agent 还原出对客的历史承诺和沟通结果，新销售一天内找到了"要逾期、没兑现、需重建联系"的三个问题，从而能快速上手，不重复问、不传错口径。
05经验与展望
跟进记录这一战，验证了 Agentic Search 的落地方式很适合强业务场景。对要建设同类系统的企业，有四点经验可以直接参考：
- 业务说人话，系统也得听懂人话： 不要要求用户按字段检索，简称、口语、相对时间由系统侧消化。
- 实体先对齐，再谈检索： 客户和人没对上，语义召回做得再好也是错上加错。
- 数字按口径算，结论给出处： 统计问题走结构化计算，分析问题附带原始记录，这样的答案才用的放心。
- 权限和评测与功能一起交付： 进真实业务系统，权限边界、审计留痕、离线回归这些一个都不能少。
销售跟进记录不是孤例，ContextSearch 高精度与复杂混合检索已经进入科研、法律、金融、电商 等数十个行业，覆盖论文检索、类案检索、专利文书检索、保单检索、综合信息检索 这些 "数据量大、行业术语多、权限分级、既要查事实又要做分析" 的场景。而搜索的评价标准也在随之改变：用户要的不再是"找到文档"，而是"问得出、搜得准"并能直接拿到"信得过"的答案。
了解更多 ContextSearch 相关信息，请点击这里。