RAG与知识库高频疑问：为什么总说难用？这几个坑你踩了几个

把知识库接入大模型，结果却总答非所问？本文把用户反馈最多的几个疑问集中梳理，逐一拆解背后的真实原因与可行的调整方向。

检索不准：根源在分块还是向量

用户最常问的就是“我的知识库明明有内容，为什么回答还是错？”底层原因往往是检索环节没召回相关片段。很多人第一反应是换向量模型，但实际场景中，分块策略不当才是头号杀手。

分块切割的常见问题

技术文档里的一个完整步骤，如果被硬生生截成两段，丢失了前因后果，向量再强也匹配不到。此外，分块大小直接影响检索粒度：小块（128 tokens）适合精确查找术语定义，但可能缺少上下文；大块（512 tokens）上下文丰富，却容易混入噪声。2026年不少社区实践推荐用重叠窗口——每块保留前后各10-30%的字符，减少信息断裂。

向量模型不是万能的

即便用当前较新的embedding模型，如果原始文档分块内容本身就含糊，向量距离也无法确保高相似度。建议先手工抽几条测试查询，看看召回的前几名是不是真有用。如果前三名都不相关，问题多半出在分块，而非模型。

分块大小：128、256还是512？

分块大小没有银弹，但可以根据文档类型和查询特点做取舍。常见做法：对于条款、规范类文档用128-256 tokens，因为每条规则相互独立；对于叙述性文章（如产品说明）用256-512 tokens，保留叙事线索。

实践中的调优步骤

• 准备一批真实用户查询，标注期望匹配的段落。
• 用几种分块大小分别检索，计算召回率（前N个命中率）。
• 观察哪种粒度在top-5内命中更多。
• 结合重排序（rerank）放大候选池，先拉取较多候选（比如30-50个），再精排。

小技巧：按语义边界切分

自然语言有标题、段落、列表等结构。用专门的文档分割工具（如基于句子embedding的层次分块）能比固定token数切分更贴近语义单元。2026年这类工具已经比较成熟，可以降低不少试错成本。

向量检索 vs 关键词搜索：到底该用哪个？

不少人以为RAG必须靠向量，忽略传统关键词。实际两者各有用武之地。向量检索擅长捕捉语义相近但字面不同的查询（比如“汽车”和“轿车”），关键词则精准匹配专有名词（比如“A100 GPU”）。

混合搜索是较优解决方案

多数实用案例都推荐同时跑向量和关键词，然后融合结果。具体做法：

• 关键词用BM25或更现代的SPLADE召回一批段落。
• 向量用余弦相似度召回另一批。
• 两者按权重合并或通过重排序模型统一打分。 这样既能确保专有名词的精确性，又能覆盖同义表述。

何时可以只用关键词？

如果知识库内容极度结构化（比如API文档），且查询总是包含准确术语，那么纯关键词检索配合少量上下文窗口也可能够用。但多数场景下加入向量能提升容错力。

更新维护：知识库变了，索引要重建吗？

知识库内容会持续增删改，每次变动都全量重建不现实。2026年主流向量数据库都支持增量更新——只重新索引变动的文档块，维持其余不变。

常见更新场景与应对

• 追加新文档：直接插入新块索引，不影响旧数据。
• 修改现有文档：需要先删除旧块，再插入新块。注意删除后要确保后续查询不返回已废弃内容。
• 删除文档：同步删除对应索引记录，避免在线查询匹配到过期信息。

版本一致性的坑

如果知识库和索引不同步，用户可能查到旧答案。建议用事务性写入：更新数据库时先标记待更新文档，等索引完成后一次性切换。或者在检索时附加一个时间戳过滤，只返回最新版本。

检索结果太多或太少？怎么调？

检索返回的片段数量直接影响生成质量。返回太少（如1个）可能遗漏关键信息；返回太多（如50个）容易让大模型分心。

调整候选数与重排序

• 先设定一个较宽的候选范围（比如20-30个），再用轻量级重排序模型（如Cross-encoder）精排，只取前3-5个送入大模型。
• 如果重排序后top1依然不相关，说明初始召回向排名靠前的作品本身就不好，需要回去调整分块或向量模型。

相似度阈值设多高合适？

向量检索会返回距离分数，可以设阈值过滤明显不相关的片段。但阈值设太严可能漏掉需要模糊匹配的场景。建议阈值保留率在80-95%之间，再靠重排序把关。

查询改写也能提高召回

用户输入往往简短或模糊。可以用一个小模型把用户问题改写成更完整的查询（比如把“价格多少”改成“该产品当前市场参考价格是多少”），再送检。这在很多线上系统中被验证有效。

常见问题