Spring AI 知识库 RAG：从文档到可追溯回答

大语言模型并不知道刚刚更新的内部资料，也不能保证每个事实都正确。检索增强生成（RAG）会先从应用自己的知识库中找相关内容，再把检索结果作为上下文交给模型生成回答。

1. RAG 的两条流程

离线导入流程：

1
读取文档 → 清理与拆分 → 添加元数据 → 生成向量 → 写入向量存储

在线问答流程：

1
用户问题 → 可选查询改写 → 向量检索与过滤 → 组装上下文 → 模型生成 → 返回答案和来源

Spring AI 将文档读取、转换和写入向量存储组织为 ETL 组件，也提供向量存储和 RAG Advisor 等抽象。具体类名和依赖会随版本变化，应先固定 Spring AI BOM，再按对应版本文档实现。

2. 文档拆分与元数据

切块太大时，检索结果可能包含大量无关内容；切块太小则上下文断裂，答案缺少必要定义。可以从段落、标题和 token 长度综合拆分，再在相邻块之间设置适量重叠。

每块最好保留来源文件、标题、章节、更新时间、访问范围等元数据。元数据有助于过滤和展示引用，也能支持文档更新时删除旧版本。敏感文档需要在检索之前按用户权限过滤，不能把所有内容送给模型后再要求模型自行保密。

3. 向量检索不是全文搜索的替代品

Embedding 把文本映射为向量，系统按相似度找候选内容。向量相似不等于事实相关，也可能漏掉精确编号、专有名词或否定条件。可以结合关键词检索、元数据过滤和重排，并通过真实问题集调节 top-k 与相似度阈值。

如果检索结果为空或相关度不足，系统应允许回答“资料中没有找到依据”，而不是强迫模型编造答案。返回答案时尽量附上文档标题、章节或链接，方便用户核对。

4. 评估要覆盖检索和生成

只看回答是否流畅不够。至少分别评估：

  • **检索质量：**正确文档是否进入候选结果，是否有过多无关内容？
  • **答案忠实度：**回答中的事实能否在检索上下文中找到依据？
  • **拒答行为：**没有证据时是否明确说明不知道？
  • **权限隔离：**不同用户是否只能检索有权访问的文档？
  • **数据更新：**删除、修改和重新导入后，旧向量是否被清理？

用一组人工标注的问题建立回归集，记录文档版本、检索参数和模型版本，才能判断改动是否真的改善结果。

5. 安全和数据治理

检索到的文档本身也可能包含恶意指令或过时内容。把文档内容作为数据处理，而非系统指令；限制模型可调用的工具权限，并避免向模型发送完成任务不需要的个人信息。日志中也要处理敏感问题和检索片段。

6. 小结

RAG 的质量取决于文档治理、分块、检索、权限、提示和评估的整体流程。向量数据库只解决其中一环，不会自动保证答案准确。先建立一个小而可评估的知识集，再逐步扩展文档和检索策略。

参考：Spring AI Retrieval Augmented Generation 文档、Spring AI ETL Pipeline 文档。