如何提高知识库检索召回的准确性与上下文匹配能力？

核心回答

提高知识库召回准确性和上下文匹配能力，先定位正确证据在哪一步丢失，再针对该环节改进。重点区分“没有召回”“召回后排得靠后”和“已经找到却没完整进入上下文”，它们需要不同方案。

1. 先建立可回放的失败样例。 保留原问题、必要的正确证据、租户和版本条件，并记录候选、重排及最终上下文，确认问题发生的位置。
2. 正确证据没召回时，检查数据和检索。 看文档是否解析、入库，切块是否完整，过滤是否误删；再按查询特点改进改写、关键词与向量召回、Embedding 和索引搜索参数。
3. 候选里已有正确证据时，改排序。 合并去重后重排，区分相关性、精确实体和版本条件，让真正回答问题的片段排到前面。
4. 证据进入上下文后仍不匹配时，改组织方式。 保留前置条件、例外、来源和版本，必要时取父段落或相邻块；按 Token 预算选择内容，检查压缩和截断是否丢失关键句。

每次改动都用同一批问题比较证据召回、排序、最终答案及延迟成本。扩大 Top-K 或更换模型只是可选手段，效果取决于实际失败原因。

先把一次失败定位清楚

对每个样例，沿着原文、索引、候选、重排和最终模型输入逐步核对：

• 原文有，解析文本没有： 可能是表格错位、扫描内容未识别或章节丢失，先修解析与数据覆盖。
• 解析文本有，索引没有： 检查同步失败、版本未发布、切片或 Embedding 任务遗漏。
• 索引有，候选没有： 检查查询表达、过滤条件、相似度阈值和近似搜索的召回损失。
• 候选有，最终上下文没有： 检查融合、重排、去重、权限过滤和 Token 裁剪分别淘汰了什么。
• 上下文完整，答案仍错： 再查生成阶段是否误读、忽略条件或引用错误，继续扩大召回未必解决问题。

查询日志应保留原问题与改写结果、过滤条件、候选 ID 和来源排名、重排顺序，以及最终采用的片段和版本。这样才能确认一次改动补回了哪类证据，而不是只观察最终回答变得更流畅。

正确内容没有进入候选，怎么改

先改善可检索的内容。 按文档标题、条款、接口或表格结构切块，把结论与条件放在可关联的范围内；补充标题、章节和来源等元数据。过小的块容易丢背景，过大的块容易混入多个主题，大小应在自己的问题集上比较。

让查询保留真正的约束。 多轮问题可以补齐已确认的实体和指代，术语或口语差异可用改写及多查询补充；原问题应保留一条召回路径，避免改写偏离。HyDE 用假设答案帮助检索时，假设内容只是检索线索，不能直接当答案证据。

按查询特点补召回通道。 型号、错误码、版本号等精确实体可增加关键词或结构化匹配，语义改写问题可利用向量召回。多路结果按稳定的片段 ID 合并，保留各路来源；RRF 可以按排名融合，避免直接相加量纲不同的 BM25 和向量分数。混合检索是否改善效果，需要按查询类别验证。

检查过滤与向量索引。 租户、权限和明确的业务范围应参与检索；过滤返回过少时，要判断是范围确实狭窄，还是先截取候选再过滤造成不足。修正错误条件或在授权范围内扩大候选，不能通过取消权限限制补召回。

向量侧核对索引与查询的模型、预处理、维度和距离度量是否匹配。可在一部分样本上对比精确搜索与 ANN，区分近似搜索损失和语义表示问题，再调整搜索预算或评估更适合领域的 Embedding。

正确证据已经召回，怎么改善排序与上下文

召回阶段偏重覆盖，重排阶段进一步判断“这段内容是否回答当前问题”。Cross-Encoder 会联合输入问题与候选，适合在有限候选集上判断细粒度相关性，但补不回候选池里根本没有的证据。候选越多，重排计算也越多，需要按延迟预算取舍。

语义相近不一定适用：同名产品的不同版本、相同错误码的不同服务，都需要结合元数据检查。旧版本可以作为历史材料保留，但不要和现行内容混成同一事实。

上下文组织还要区分检索粒度与阅读粒度。小块更容易命中具体问题，命中后可按关联关系取父段落或相邻块，补齐条件；同时去重并限制扩展范围，避免整篇文档挤占预算。多问点问题要给各个子问题保留证据，不能让一个相似度高的主题占满上下文。

例如，一份假设政策写着“普通商品可申请退货，定制商品除外”。如果只召回前半句，模型即使严格根据片段回答，也可能误答定制商品的问题。把例外与规则一起返回，才解决了上下文不完整；仅提高前半句的重排分数没有帮助。

压缩时保留实体、数字、否定、适用条件和引用位置，并检查最终实际发给模型的文本。片段在检索结果里出现过，不代表它完整地进入了模型输入。

怎样证明改进有效

固定文档与索引版本，用标注了必要证据的问题集进行对照。既包含常见问题，也包含精确实体、多轮指代、跨文档问题、旧版本干扰和无答案问题。

分别观察：

• 候选覆盖： Recall@K 或必要证据覆盖情况；需要多段证据的问题不能只看是否命中其中一段。
• 排序与上下文： 正确证据排名、无关内容比例，以及从候选到最终上下文的证据保留情况。
• 最终结果： 答案正确性、引用是否支撑结论，以及证据不足时的处理。
• 工程代价： 检索和重排延迟、模型输入 Token、额外调用及索引维护成本。

一次优先改变一个可解释因素，按失败类别看收益与退化。最终 Top-K、阈值和切块参数由证据覆盖与预算共同决定，不应直接照搬其他系统的固定值。

追问：召回率提高了，答案反而变差怎么办

先比较最终上下文：是否增加了重复、旧版本或相似但不适用的内容，是否因预算裁剪挤掉了关键证据。可以保留较大的候选池，再用重排、去重和主题覆盖缩减最终输入，而不是把全部候选都交给模型。

若高质量上下文已经齐全，再检查生成提示、引用约束和模型对条件的理解。召回覆盖与答案正确性需要分开评估，不能只优化其中一个分数。

对应教程

参考资料

MaxKBPython

基于 MaxKB

核心回答

在 MaxKB 中，提高检索准确性要同时处理检索范围、问题表达、候选排序和最终上下文。它用 Python 实现知识库问答与工作流，PostgreSQL/pgvector 保存检索数据；工作流中的知识库检索节点先按范围召回段落，需要精排时再连接独立的重排节点。

具体来说，先限定允许查询的知识库或文档，检查有效段落是否完成索引；再用关联问题补充用户常见问法，选择 embedding、keywords 或 blend 模式，并分别调整召回与重排的 top_n、similarity。最后检查实际拼接文本，确认关键条件没有被字符预算截掉。分数高、返回段落多，都不等于回答所需的上下文完整。

范围和参数怎样影响召回

知识库检索节点既能使用配置的知识库列表，也能引用上游输出的知识库或文档列表。执行时先过滤可用的授权资源，检查所选知识库是否使用相同的向量模型，再排除禁用文档，并在检索查询中要求索引记录有效、排除指定段落。没有可用知识库时返回空结果。

top_n 控制返回段落数，similarity 是当前检索分数的筛选门槛。多库查询会逐库取结果，再按分数合并，最终只保留全局前 top_n 段，并非每个库各保留这么多段。因此，某个知识库有正确证据，仍可能在全局截取时被挤掉。范围过滤、逐库查询和结果截取分别见检索节点与向量存储查询。

三种模式的分数含义不同：

• embedding 按向量距离得到语义相似度，适合措辞不同但含义接近的问题。
• keywords 使用全文检索与 ts_rank_cd 排序，查询分词会采用知识库的自定义术语。
• 当前 blend 先取向量近邻窗口，最多 min(top_n × 10, 500) 条索引记录，再叠加这些记录的全文分数，按段落保留最高分并筛选、排序。它没有将两路独立候选做并集，也没有使用 RRF；向量窗口外的纯关键词证据不会因此补进来。

所以切换模式后，需要重新校准阈值。若精确术语始终漏召回，应对照关键词检索与混合检索的候选，而非只降低混合分数门槛。具体评分与窗口见混合检索 SQL。

关联问题和人工改答怎样补覆盖

MaxKB 可以把常见问法关联到已有段落。索引中既包含段落内容的分块，也包含关联问题的文本；每条记录都保留对应的 paragraph_id。用户命中某种问法后，系统按段落归并结果，再取回段落正文。因此，关联问题扩展的是找到答案的入口，返回的证据仍来自对应段落。

人工改答也能用于补充知识：聊天记录的改答操作在事务中新增答案段落，创建或复用问题并保存问题—段落映射，随后触发该段落向量化。这让经过修订的答案有机会被后续相近提问检索到，属于知识与索引更新；模型参数没有因此被训练，向量化完成后仍要用相关问题验证是否正确命中。实现见人工改答与后置向量化。

问题与段落的关联要覆盖真实问法，也要避免把适用条件不同的问题全部挂到同一答案上。若正文缺少必要条件，补再多关联问题也只能更容易找到一段不完整的证据。

重排与上下文各管什么

工作流的重排节点接收上游候选，把标题和正文交给所选重排模型，再按重排分数、top_n 和 max_paragraph_char_number 筛选输出。它能调整已有候选的顺序，无法补回检索范围或候选窗口外的段落；其 similarity 针对重排结果，不能与召回分数混为同一标准。

检索节点本身按相似度排序后拼接标题与正文，再按字符数切片；它不会自动按照原文顺序补回相邻段落。重排节点也有自己的字符预算。因此，正确段落命中却漏掉例外条件时，要查看实际输出文本，区分条件原本不在候选、排在预算之后，还是在段落中途被截断。可以调整分段，让规则与条件保持完整，再分别控制候选规模和最终引用长度。

验证时固定文档与问题集，比较各模式下的必要证据覆盖、正确段落排名、最终文本完整度、答案及延迟。对人工改答，还应补测同义问法和条件相近但答案不同的问题，确认改善覆盖的同时没有增加误匹配。

参考资料

• 国内：飞致云：MaxKB 问题管理：采用维护常见问题并关联文档分段的方式，解释正文中用问题表达补充段落召回入口的做法。
• 国外：Sentence Transformers：Retrieve & Re-Rank：依据候选检索与联合精排的分工，解释重排只能优化输入候选，以及候选数量与计算成本的取舍。