在企业知识库、技术文档和商品搜索中，单纯依赖全文检索容易错过同义表达，单纯依赖向量检索又可能弱化型号、编号、专有名词等精确条件。更实用的方案，是让 Ollama 在本地生成文本向量，由 Elasticsearch 同时执行 BM25 全文检索与 kNN 向量检索，再对两路候选结果进行融合排序。这样既能保留关键词命中的可解释性，也能获得语义召回能力。🔍
一、整体架构与数据流
完整链路可以拆成四步：首先对原始文档进行清洗和分段；其次调用 Ollama 的嵌入接口，将每个文本块转换为向量；然后把正文、标题、标签、权限字段及向量一并写入 Elasticsearch；最后在查询阶段同步执行全文检索和向量检索，并通过 RRF 或加权评分合并结果。
Ollama 提供 /api/embed 接口，既支持单条文本，也支持数组形式的批量输入。官方建议索引和查询使用同一个嵌入模型，并优先采用余弦相似度进行语义搜索，具体说明可参考 Ollama Embeddings 文档。
关键原则：文档向量与查询向量必须来自同一模型、同一版本以及一致的预处理流程，否则相似度将失去可比性。
二、准备 Ollama 嵌入服务
部署时可以选择适合中文或多语言场景的嵌入模型。执行模型拉取后，通过 Ollama 的本地服务生成向量。请求内容至少包含 model 和 input 两个字段，其中 input 可以是一段文本，也可以是一组文本。批量生成通常比逐条调用更高效，但仍应根据显存、内存和文本长度控制批次大小。🚀
文档切分不宜只按固定字符数粗暴截断。更稳妥的方式是优先沿段落、标题或语义边界切分，并保留少量上下文重叠。每个文本块应记录 document_id、chunk_id、title、content、tags 和更新时间，便于聚合、过滤与回溯原文。
三、设计 Elasticsearch 索引
索引中可将 title 和 content 定义为 text 类型，用于 BM25 检索；将 embedding 定义为 dense_vector，用于 kNN 相似度搜索；业务分类、租户、权限和状态等字段则使用 keyword、date 或其他适合过滤的数据类型。
dense_vector 的 dims 必须与 Ollama 模型输出的向量维度一致，同时应启用向量索引，并根据模型特性选择 cosine 等相似度。Elasticsearch 对自带向量的字段映射和检索方式，可参考 自有向量接入指南。
- title：设置较高的全文检索权重，突出标题命中。
- content：承担主体召回，可结合中文分词器进行配置。
- embedding：保存文本块向量，并用于近似 kNN 检索。
- metadata：保存分类、来源、时间和访问权限等过滤条件。
写入数据前应先校验向量长度和数值格式。若中途更换嵌入模型，建议创建新索引并全量重建向量，而不是把不同模型生成的向量混入同一个字段。
四、并行执行全文与向量检索
查询到达应用后，先使用与建库阶段相同的清洗规则处理文本，再调用 Ollama 生成查询向量。一条检索请求中，全文分支可以使用 multi_match 查询 title 和 content，向量分支则使用 knn 检索 embedding 字段。
全文检索擅长处理产品型号、错误码、姓名和明确术语；向量检索更适合“如何降低接口延迟”与“优化 API 响应速度”这类语义相近但措辞不同的表达。两者并行召回，可以减少单一检索方式造成的遗漏。
向量检索中的 k 表示最终保留的近邻数量，num_candidates 表示近似搜索阶段参与竞争的候选规模。候选范围越大，通常越有利于召回，但也会增加计算开销。生产环境应结合数据规模和延迟目标压测，而不是直接照搬固定参数。Elasticsearch 对近似与精确 kNN 的差异有专门说明，可参考 kNN 检索文档。
五、使用 RRF 完成融合排序
BM25 分数和向量相似度分数不在同一尺度上，直接相加容易出现某一路结果长期占优。Reciprocal Rank Fusion，即 RRF，主要依据文档在各结果列表中的名次计算融合得分，因此不要求两类原始分数具有可比性。
实践中可以把 standard 全文检索器与 knn 检索器作为 RRF 的两个子检索器，再设置 rank_window_size 控制每一路参与融合的候选窗口。其核心思想是：某文档在任一路排名越靠前，获得的融合贡献越大；若它同时出现在两路结果中，通常会得到更稳定的最终排名。相关参数可查看 Elasticsearch RRF 文档。⚖️
如果业务确实要求“关键词优先”或“语义优先”，可以在应用层使用加权融合，但需要先对 BM25 与向量分数进行归一化，并通过标注查询集调节权重。相比之下，RRF 参数更少，适合作为首个可上线版本。
六、上线前的效果与性能优化
- 建立评测集：收集真实查询，为每条查询标注相关文档，分别比较全文、向量和融合检索。
- 加入业务过滤：在两路召回中保持一致的租户、权限、状态和时间条件，避免融合后出现越权结果。
- 缓存查询向量：对高频问题缓存 Ollama 输出，减少重复推理和首字节等待时间。
- 批量生成文档向量：离线任务采用可控批次，并记录模型名称、版本和处理时间。
- 观察分路贡献：记录文档来自 BM25、kNN 还是两路共同命中，便于定位排序问题。
还要注意，向量召回不是越多越好。候选窗口过小可能漏掉相关内容，过大则会增加内存和排序成本。建议从较保守的参数开始，通过 Recall、MRR、NDCG、P95 延迟以及人工满意度共同判断，而不是只观察某一个离线指标。
总结
Ollama 与 Elasticsearch 的组合，能够在本地化模型能力和成熟搜索基础设施之间取得平衡。落地时，应重点保证模型一致、向量维度正确、文档切分合理、权限过滤同步，并优先使用 RRF 融合 BM25 与 kNN 的排名。先建立可评测、可观测的最小闭环，再逐步调整候选窗口、字段权重和切分策略，通常比一开始设计复杂的评分公式更可靠。✅
