切片要尊重文档结构
固定 500 字切片容易切断表格、步骤和上下文。更稳的方式是先按标题、章节、列表和表格结构解析,再根据长度做二次合并。 每个 chunk 应保留来源、标题路径、更新时间和权限标签。这样模型回答时能引用出处,也能避免越权访问。
- FAQ:一问一答尽量保持在同一个 chunk。
- 教程:步骤和前置条件不要拆太散。
- 政策文档:保留章节编号和生效日期。
- 代码文档:函数签名、参数和示例要放在一起。
召回不是越多越好
召回数量过少会漏答案,过多会把噪声交给模型。常见做法是向量检索加关键词检索,再做 rerank。 对业务知识库来说,权限过滤、时间过滤和文档类型过滤经常比 embedding 模型更重要。
query -> rewrite
-> hybrid search
-> permission filter
-> rerank top 20
-> answer with citations
建立问题集,而不是凭感觉调参
评估集至少包含三类问题:能直接回答的问题、需要跨文档综合的问题、知识库没有答案的问题。 每个问题标注标准答案和应召回文档。测试时分别看 recall、引用准确率、拒答准确率和答案可读性。
Recall:正确文档是否出现在 top 5 或 top 10。
Faithfulness:答案是否只依据召回内容,不编造。
Citation:引用是否指向真实来源和正确段落。
Refusal:知识库没有答案时是否能明确拒答。
上线后看这些指标
RAG 上线后要记录查询、召回文档、模型回答、用户反馈和失败类型。每周分析高频无答案问题、低评分答案和过期文档。 知识库不是一次性项目,而是持续维护的数据产品。