还原MELFOR明晟云服Daisy知识库的一次技术决策：在200余条Q&A的规模下，对比向量检索与本地关键词匹配（bigram加双向覆盖率），从规模、延迟、可解释性与运维成本四个维度说明为何选择后者，并给出规模扩大后向量召回加关键词精排的混合演进路径。
摘要
技术选型的答案，往往不取决于哪个方案更"先进"，而取决于它是否匹配当前的规模与约束。MELFOR明晟云服的Daisy知识库目前承载200余条结构化Q&A，用于匹配用户的自然语言提问。在引擎选型上，我们没有采用业界讨论度很高的向量检索（embedding + ANN近似最近邻），而是选择了本地关键词匹配（bigram分词 + 双向覆盖率打分）。原因很朴素：在当前规模下，后者延迟更低、无外部服务依赖、结果可解释、维护成本也更可控。本文还原这次选型的对比过程与权衡逻辑，并说明规模扩大后的演进路径。
技术选型的答案，往往不取决于哪个方案更"先进"，而取决于它是否匹配当前的规模与约束。MELFOR明晟云服的Daisy知识库目前承载200余条结构化Q&A，用于匹配用户的自然语言提问。在引擎选型上，我们没有采用业界讨论度很高的向量检索（embedding + ANN近似最近邻），而是选择了本地关键词匹配（bigram分词 + 双向覆盖率打分）。原因很朴素：在当前规模下，后者延迟更低、无外部服务依赖、结果可解释、维护成本也更可控。本文还原这次选型的对比过程与权衡逻辑，并说明规模扩大后的演进路径。
问题：200条Q&A如何匹配用户提问
知识库匹配要解决的核心问题是：用户用口语化的方式提问，系统需要从已有的标准问答中找出最相关的一条或几条。
这个问题的难度与数据规模强相关。当知识库只有200余条Q&A时，候选集很小，匹配的本质是"在一个小集合里做精排"，而非"在海量文档里做召回"。这一点决定了选型的天平——很多为大规模检索而生的重型方案，在小集合上反而会引入不必要的复杂度。
我们对方案的要求可以归纳为四条：响应要快（用户在对话中等待，延迟敏感）、依赖要少（不希望为一个匹配功能引入额外的常驻服务）、结果要可解释（运营人员需要理解"为什么命中这一条"，以便持续优化知识库）、维护要轻（小团队没有专职的检索工程师）。带着这四条标准，我们对比了两类主流方案。
两类方案的对比
方案一：向量检索（embedding + ANN）。 思路是把每条Q&A和用户提问都通过嵌入模型转成高维向量，再用近似最近邻算法（如HNSW）在向量空间中找距离最近的候选。它的优势在于语义泛化能力强——"怎么开发票"和"发票如何申请"即使字面不同，向量距离也很近。这是它在大规模、长尾查询场景下被广泛采用的原因。
但向量检索也带来相应的成本。其一，需要引入嵌入模型与向量数据库两类组件，无论是托管服务（如Pinecone、Weaviate等提供的云服务，按存储与查询量计费）还是自建（如部署开源向量库），都意味着额外的运维与费用支出。其二，匹配结果是"向量距离"，对运营人员而言是个黑盒，难以直观解释为什么命中某一条。其三，嵌入模型本身有调用延迟与依赖，对一个200条的小知识库来说，这部分开销并不划算。
方案二：本地关键词匹配（bigram + 双向覆盖率）。 思路是把文本切成相邻两字组成的bigram（如"发票申请"切成"发票""票申""申请"），分别在用户提问与候选Q&A上建立词项集合，再用双向覆盖率打分：既看"提问的词有多少落在候选里"（召回方向），也看"候选的词有多少被提问覆盖"（精确方向），两个方向加权后得到相关性分数，取最高分作为命中结果。
它的优势恰好对应我们的四条要求：纯本地计算、无网络往返，单次匹配在毫秒级；不依赖任何外部服务，知识库即数据、匹配即函数；打分逻辑透明，运营人员能理解"命中是因为这些关键词重合"，从而有针对性地补充同义词或调整标题；代码量小，小团队即可维护。它的局限同样明确：对字面差异大但语义相近的提问，泛化能力弱于向量检索，需要靠人工维护同义词与别名来弥补。
| 维度 | 向量检索 | 本地关键词匹配 |
|---|---|---|
| 语义泛化 | 强，字面不同也能命中 | 弱，依赖同义词维护 |
| 响应延迟 | 含模型与检索往返 | 纯本地、毫秒级 |
| 外部依赖 | 嵌入模型+向量数据库 | 无 |
| 可解释性 | 弱（向量距离黑盒） | 强（关键词重合可见） |
| 运维成本 | 较高（服务/计费/调优） | 低 |
| 适用规模 | 大规模、长尾查询 | 中小规模、可控候选集 |
需要强调的是，这不是"先进与落后"的对比，而是"适配与否"的取舍。向量检索在大规模语义搜索场景下的价值已被广泛验证，我们放弃它，仅仅是因为它解决的问题（海量召回、强语义泛化）超出了我们当前的实际需要。
决策依据：规模、延迟与可解释性
最终选择本地匹配，是三个因素共同作用的结果。
第一是规模匹配。 200余条Q&A是一个"小到可以全量比对"的集合。即便对每一条都做完整的bigram打分，计算量也微不足道，无需ANN这类为加速海量检索而设计的近似算法。引入向量数据库去检索一个200条的集合，相当于为短途出行配备重型卡车——能力过剩，成本却实打实地产生。
第二是延迟与依赖。 Daisy的匹配发生在对话交互中，用户对等待敏感。本地匹配没有网络往返、没有模型推理排队，延迟稳定可控；同时不引入任何外部服务，也就没有外部服务的可用性、计费与版本变更问题需要操心。对一个小团队而言，"少一个常驻依赖"本身就是实打实的收益。
第三是可解释性。 知识库不是一次性建成的，而是需要运营人员持续打磨的资产。当某条提问没有命中预期答案时，运营人员需要知道"差在哪里"——是缺少同义词，还是标题措辞偏离用户习惯。本地匹配的打分过程是透明的，能直接指导知识库的迭代；而向量距离的黑盒特性，会让这类优化失去抓手。
演进路径：规模扩大之后
选型不是一锤定音，而是随规模演进的。我们为知识库预留了清晰的升级路径。
当知识库规模扩大到数千乃至上万条、且用户提问的长尾化程度显著提高时，纯关键词匹配的泛化短板会逐渐显现。届时的演进方向是引入向量检索做"召回层"——先用向量检索从小集合中快速圈出语义相近的若干候选，再叠加现有的覆盖率打分做精排，形成"向量召回 + 关键词精排"的混合架构。这样既获得语义泛化能力，又保留了可解释的精排环节。
更进一步，还可以引入查询改写（把口语化提问扩展为多个近义表达）、同义词词典、点击反馈等手段持续优化命中率。这些手段与底层引擎正交，无论用哪种检索方式都能叠加。
明晟云服在这次选型中坚持的原则是：用匹配当前规模的方案解决当前的问题，把复杂度留给真正需要的时刻。技术的价值不在于用了多新的名词，而在于它是否恰当地解决了手头的问题——这既是工程取舍，也是对客户资源负责的态度。
*了解更多关于MELFOR明晟云服的信息，请访问官网 melfor.cn 或致电 400-867-9819。*