知识库检索匹配的服务化实践

知识库检索匹配这事儿，听上去挺技术，但说白了，它解决的是一个非常实际的问题：用户丢过来一句话，系统得从茫茫文档海里，挑出最相关的那几篇。这不只是搜个关键词那么简单，背后涉及到文本语义的理解、排序策略的优化，以及工程层面的稳定落地。今天，我们就把这套完整的实践路径拆开看看。

一、背景

知识库，对很多企业来说，是面向客户和内部员工的一个“知识沉淀池”，里面装着各种教程、问答、案例。而检索匹配，本质上就是自然语言处理领域里一个经典的语义相似度计算问题。说得更直白点，就是判断两段文本在意思上有多接近。这个能力，几乎贯穿着从搜索引擎到智能客服、从知识检索到信息推荐的各个应用场景。

所以，知识库检索匹配的核心任务可以这样定义：给定一个用户的

，以及一个包含海量候选文档的知识库，系统需要从中找出与这个query语义最匹配的TopK个文档。

二、架构流程

（图片位置）

（图片位置）

三、算法实现

3.1 DSL改写

检索优化的第一步，往往是调整DSL。刚接手这块业务时发现，之前业务方已经尝试过优化——调整不同字段的匹配权重。但这招到了一定阶段，天花板就很明显了。

换个思路，从知识运营的视角出发，能不能在用户检索时，主动把运营认为“更重要”的文档推到前面？文档之间通常有互相引用的关系，这正好是PageRank算法的用武之地。PageRank的核心逻辑很简单：被引用次数越多的文档，越重要。

想象一下，假如只有四个网页A、B、C、D，箭头从B指向A，就意味着B引用了A一次。对B来说是链出，对A来说是链入。L(B)代表B的链出数量，PR(B)是B的PageRank值。假设所有文档初始PR值都是0.25，经过迭代计算，PR值会最终收敛到一个稳定值，这就是每个文档的最终PR分数。

而这个PR值，正是改写DSL的关键信息：

new score = old score * log(1+2*PageRank)

这里的old_score是ES基于BM25算出来的原始分数，PageRank缺失的文档用1代替。

3.2 文本召回

文本召回是召回层最常用的策略。做法很简单：对query进行分词，把分词后的关键词丢到ES基于倒排索引做tf-idf相似度计算。这种方式实现简单、不需要训练模型、资源需求低、检索速度快。但短板也很明显——文本是有语义和语法结构的，文本召回完全忽略了这些信息，更无法处理一词多义或同义词的问题。如果query本身语义层面比较模糊，那文本召回的效果就会大打折扣。

3.3 向量召回

向量召回的出现就是为了弥补文本召回的不足。它的思路是：分别计算query向量和文档标题（或相似问）向量的余弦相似度，然后返回分数最高的TopK个文档。这一步计算可以交给Milvus这样的向量检索库来做，性能上有天然优势。

文本转向量的模型结构通常是这样的：embedding层提取特征，经过两层transformer和MLP，最终对编码向量做L2归一化。典型的双塔结构，左塔输入检索词，右塔输入文档标题，左右塔结构分离但参数共享。这种结构天生适合做召回——左塔的query向量实时推理，右塔的海量文档向量离线计算完刷入Milvus即可。

向量召回的大致流程：工程实现上，DP离线任务负责计算文档标题和相似问的向量，并导入Milvus。需要注意的是，Milvus对string类型的属性支持不算友好，所以在数据库阶段，会通过请求MySQL来对召回结果进行扩展和补全。

3.4 精排序

经过召回和粗排，相关性高的文档基本已经被提到了前面。但要真正对齐用户意图，还得再做一轮精排序。基于全场景的用户检索点击数据，有点击行为的就视为正样本，否则就是负样本。

模型设计上采用in_batch负采样，这样就不需要提前构造负样本。query与正负样本的相似度会进入InfoNCE函数计算损失，用这个损失来更新模型参数。这种由大量负样本构成的双塔结构，在学术界也被称为对比学习——核心思想是拉近相似的样本，推开不相似的样本，最终目标是从样本中学习到一个好的语义表示空间。

精排模型与文本转向量的算法原理是相通的。

InfoNCE公式可以理解为带温度超参的CrossEntropy。分子是正例对的相似度，分母是正例对加上所有负例对的相似度。最小化InfoNCE loss，本质上就是在最大化正例对的相似度，同时最小化负例对的相似度。

计算损失时，label可以在batch内生成。query和文档的编码向量做一次矩阵乘法，得到相似度方阵，对角位置就是互相匹配的样本。假如batch_size=4，那每行的label就是[0,1,2,3]。

模型训练好之后，就得到了一个文本编码器。输入两段文本，就能输出一个匹配分数。把这个模型部署到小盒子服务，排序时只需要输入候选文档标题和query，按分数从高到低重新排列即可。

3.5 排序优化

前面提到，基于小盒子的精排方式在只处理20个文档（一页）时是没问题的。但每个文档往往还包含多个相似问，如果只用20个标题来代表整个文档，效果并不稳定。如果能利用文档的标题和全部相似问，那效果会更扎实。

问题是，这样做会导致每次进入小盒子的文档数不确定，少则20，多则上百。batch_size一上去，耗时和超时风险就同步飙升。即使切成小batch，也存在“一个失败，全部失败”的风险，整体RT也没降多少。

换个思路，模仿向量召回的做法，让模型只接受单个文本输入，输出这个文本的向量。然后分别计算query向量与每个文档标题以及所有相似问向量的相似度，取均值。等价于先算文档标题和相似问的向量均值，再与query向量算相似度。这样一来，

。

在进入Milvus之前，先按向量召回和ES召回的文档ID做过滤，单次计算的RT就得到了保障，支持的QPS也比小盒子版本高出了一截。

这种方法当然也有局限：它只能优化“取均值”这个计算逻辑。如果需求变成“取最大相似度”，这套流程就不适用了。而且query与文档的交互太少，只在最后算一次相似度，效果上可能不如多轮交互模型。

四、工程实现

线上收到一条检索请求后，首先调用在线推理的小盒子服务计算query向量，然后去Milvus向量库中与知识库的向量做相似度计算，返回距离最近的TopN个Item，作为向量召回的结果。

4.1 离线训练（DP平台）

海量知识语料的向量化计算依托自研的DP平台离线运行，保证全库文本匹配的速度。主要包含三个步骤：

• 语料库预处理：文本清洗、筛选等逻辑

• 语料库向量化：利用向量计算模型完成

• 导入Milvus库：将集合部署在Milvus集群，批量导入并更新，保证线上可用

4.2 在线推理（Sunfish平台）

自研的算法平台Sunfish为模型训练提供了一站式闭环服务，支持分布式训练、GPU/CPU切换、模型版本管理、一键式运行和部署。其中：

• 算法工程模块：一键运行训练、任务作业管理、模型输出

• 模型管理模块：训练任务、地址导入、本地上传等多来源模型选择

• 模型部署模块：简单配置、模型格式选择、线上资源配置等便捷方式

4.3 Milvus向量检索

Milvus是一款开源的高性能向量相似性检索引擎，集成了Faiss、Annoy等广泛使用的向量索引，成本低、性能高、灵活稳定。十亿级别向量的检索仅需毫秒级响应。

选择Milvus索引时的简单原则：

• 数据量小且需要100%召回率时，选FLAT；

• 追求高性能且召回率尽可能高时，选IVF_FLAT；

• 资源有限（磁盘、内存、显存）且需要高性能时，选IVFSQ8H；

• 只有CPU资源且资源有限时，选IVFSQ8。

目前Milvus支持多种距离计算方式，主要采用内积（IP）来计算。内积更适合判断向量的方向。在向量归一化之后，内积与余弦相似度等价，因此Milvus没有单独提供余弦相似度的计算接口。

4.4 算法接口服务

算法模型接口由ai-service和ai-app两个服务组成。ai-service负责调用模型在线推理、Milvus实时向量召回等底层能力；ai-app负责业务逻辑的开发。

ai-service配置示例（代码部分保留）

ai-app接口设计：实现业务逻辑开发测试后，发布上线即可提供前后端调用。

（Ma ven示例、请求示例、返回示例等代码部分保留）

五、服务实践

5.1 官网帮助中心

（图片位置）

5.2 相似商品推荐

（图片位置）

六、总结

这篇文章大致梳理了知识库检索匹配从算法到工程服务化的全过程。目前这套方案已经在多个业务场景中得到广泛应用，并且针对类似场景做了低代码封装和策略配置，方便快速、轻量地服务化落地。回顾整个实践过程，有几个方向值得持续关注：

1）对于知识库中低频或全新出现的文档或商品，模型对它们的Embedding学习还不够充分。可以考虑引入图结构算法，把更多query和其他属性的语义信息聚合进来，进一步提升语义表征能力。

2）Embedding的实现算法五花八门。可以根据业务需要，考虑把词嵌入模型做成内置模块，方便按需调用。

3）服务的性能和稳定性，始终是重中之重。在高准确率和高QPS的双重压力下，保证系统响应能力，是永远不能松懈的一条底线。