RAG 知识库搭建教程：文档问答系统部署与检索调优

摘要

RAG 把大模型的生成能力与自有文档的检索能力结合起来，让模型基于企业内部资料回答问题，而不是凭训练记忆编造。本文完成一套 RAG 知识库的部署，涵盖工作原理拆解、组件选型、环境部署、文档切分与嵌入配置、检索效果验证与调优，以及回答不准确时的定位方法。文中重点说明如何判断问题出在检索环节还是生成环节。

一、先理解 RAG 的工作流程

搞清楚流程才能知道效果不好时该改哪里。一次完整的 RAG 问答分为两个阶段。

离线阶段：把文档变成可检索的形式

1. 解析文档，提取纯文本内容。
2. 把长文本切分成较小的片段。
3. 用嵌入模型把每个片段转换为向量。
4. 把向量和原文片段存入向量数据库。

在线阶段：回答一次提问

1. 把用户问题也转换为向量。
2. 在向量库中检索出与问题最相似的若干片段。
3. 把这些片段和问题一起组织成提示词交给大模型。
4. 模型基于给定片段生成回答。

这个流程里有个关键推论：模型只能基于检索到的片段回答。如果检索出来的片段本身不相关，无论用多强的模型，回答都不会准确。 实践中大部分效果问题出在检索环节，而不是生成环节。

二、组件选型与资源规划

一套 RAG 系统需要四类组件：

选型上有两条路径：

用集成平台，例如 LLM 应用开发平台，文档处理、向量库、检索和问答界面都已打包好，配置几项参数就能跑通。适合快速落地和中小规模使用。

自行搭建，用框架自己组装各组件。灵活性高，可以精细控制每个环节，但工作量大得多。适合有特殊检索需求或需要深度定制的场景。

本文以集成平台路径为主，因为它能让你先把流程跑通、看到实际效果，再决定是否需要深度定制。

资源规划：

内存是关键项。文档批量导入时要同时运行解析、切分和向量化，4 GB 在处理大批文档时容易触发内存不足。如果知识库规模较大，建议 8 GB 起步。

关于 GPU：如果大模型和嵌入模型都调用外部 API，不需要 GPU。如果要在本机部署本地模型，则需要按模型规模配置显存。两者也可以分开部署在不同机器上。

三、部署应用平台

以 Docker Compose 方式部署一个 LLM 应用平台。这类平台通常由多个容器组成，包括 API 服务、前端、后台任务处理、关系型数据库、缓存和向量数据库。

前置条件确认：

docker --version
docker compose version

按官方文档拉取部署文件并配置环境变量，重点修改会话密钥、数据库密码和缓存密码这几项，不要沿用示例中的默认值。

启动后确认所有容器运行正常：

docker compose ps
docker compose logs api --tail 50
docker compose logs worker --tail 50

这里要特别关注后台任务处理容器。文档解析和向量化都由它执行，它异常时的表现是文档一直处于处理中，而前端界面看起来完全正常，很容易误判为平台问题。

四、配置嵌入模型

这是 RAG 部署中最容易被漏掉、也最影响效果的一步。

除了用于生成回答的对话模型，还必须单独配置一个嵌入模型用于文档向量化。缺少嵌入模型时，上传文档会一直卡在处理中或直接报错。

在平台的模型供应商设置中配置。嵌入模型有两种来源：

调用外部 API：配置简单，按调用量计费，适合文档量不大的场景。

本地部署：用本地模型服务提供嵌入接口，数据不出自己的环境。接入时基础地址的填法要注意：

填 http://127.0.0.1:11434 一定不通，因为在容器内这个地址指向容器自身。

嵌入模型的选择会显著影响检索质量。 中文文档要选择对中文支持良好的嵌入模型，用英文为主训练的模型处理中文时检索准确率会明显下降。这一点在测试时很容易发现：明显相关的内容检索不出来，往往就是嵌入模型不匹配。

需要注意，更换嵌入模型后已有文档必须重新向量化。不同模型产生的向量不在同一空间，混用会导致检索完全失效。所以嵌入模型应当在导入大批文档之前定好。

五、导入文档与切分策略

创建知识库并上传文档。切分策略是这里的核心决策。

为什么要切分：大模型的上下文长度有限，不可能把整份文档塞进去。切分后只把最相关的片段交给模型，既节省上下文也提高准确率。

切分参数的影响：

实践建议：

• 结构规整的文档（有清晰标题层级的手册、规范）可以用自动切分，并尽量按标题边界切分，保持每个片段语义完整。
• 长段落文档（合同、论文）建议适当增大片段长度和重叠长度，避免一句话被切成两半后两边都不完整。
• 问答对形式的资料（FAQ、工单记录）适合较小的片段，每个问答独立成段效果最好。
• 表格类内容需要特别注意。表格被切断后会失去表头，检索出来的片段无法理解。这类内容建议预处理成文字描述，或单独保留完整表格。

切分完成后平台会开始向量化处理。文档数量多时耗时较长，可以在任务列表中查看进度。

六、验证检索效果，这一步最关键

很多人上传完文档就直接去问答，发现回答不准就归咎于模型不行。正确做法是先单独验证检索环节。

用命中测试单独验证检索

平台通常提供命中测试功能：输入一个问题，直接查看检索出的片段，不经过模型生成。

准备一组真实业务问题，逐个测试并判断：

• 检索出的片段是否确实包含答案？
• 最相关的片段是否排在前面？
• 是否有明显应该被检索到但没出现的内容？

检索不准时的调整方向

混合检索与重排序

纯向量检索擅长理解语义，但对专有名词、编号、型号这类精确匹配的内容表现一般。如果知识库中有大量这类内容，启用关键词检索与向量检索结合的混合模式效果会明显改善。

重排序模型的作用是对初步检索结果做二次排序，把真正相关的内容提到前面。它会增加一次模型调用的开销，但对准确率提升通常很明显。

检索环节确认无误后，再看生成环节

如果检索片段是对的但回答跑偏，问题在提示词。在应用编排中明确要求：

• 严格基于提供的资料回答，不要用训练记忆补充。
• 资料中没有相关信息时，明确说明未找到，不要编造。
• 回答时引用具体来源片段。

第二条尤其重要。不做约束的话，模型在检索不到内容时会用训练知识编一个看似合理的答案，这在企业场景中是很危险的。

七、完整验证清单

容器全部健康运行

docker compose ps

模型连通性正常：对话模型和嵌入模型都显示为可用状态。

文档处理完成：知识库中文档状态为已完成，而非一直处理中。

检索有效：命中测试返回的片段与问题相关。

问答准确：用真实业务问题测试，回答基于文档内容且无编造。

边界情况正确：问一个知识库中确实没有答案的问题，确认模型明确说明未找到，而不是编造答案。这一项必须专门测试。

API 可调用：如果需要集成到其他系统，用接口调用验证。

后台任务正常：查看任务处理容器日志，确认没有持续报错。

八、常见问题与排查

文档一直处于处理中

首先确认嵌入模型已正确配置，这是最常见原因。其次查看后台任务容器日志，任务由它执行。文档量大时处理确实需要时间，通过日志中的进度判断是卡住还是在正常推进。

上传文档失败

检查反向代理和 Web 服务器的请求体大小限制，两处都要放宽。平台自身也有文件大小上限配置。

回答内容明显是编造的

两个层面处理：检查检索是否命中了相关片段；在提示词中明确约束模型不得使用训练知识补充，并要求在无资料时如实说明。

同一个问题多次回答不一致

模型生成本身有随机性。降低温度类参数可以提高一致性。如果差异很大，也可能是检索结果不稳定，检查是否有多个相似片段在竞争。

响应缓慢

RAG 的延迟由检索和生成两部分构成。检索通常很快，主要耗时在模型生成。使用本地模型时检查资源占用；调用外部 API 时受网络和对方服务影响。启用重排序会增加一次额外调用，需要权衡准确率与速度。

更换嵌入模型后检索全部失效

这是预期结果。不同嵌入模型的向量不兼容，必须删除原有向量数据并重新处理所有文档。

磁盘占用增长快

原始文档、向量数据和对话记录都在累积：

df -h
docker system df

数据增长较快时可为数据目录单独挂载云硬盘，扩容不必迁移整台服务器。

九、维护与合规

备份要覆盖两部分：数据库中的知识库结构、切分配置和对话记录，以及存储卷中的原始文档文件。只备份其中之一恢复后都是残缺的。建议同步到对象存储，不要只留在本机。

变更前创建快照：升级平台版本、调整嵌入配置前给实例创建快照。回滚会把整块系统盘恢复到快照时间点，之后写入的数据会被清除，运行中的实例会自动关机。使用存储型套餐的实例不支持创建快照。

文档授权边界：这一点在企业场景中必须明确。导入知识库的文档必须是你有权使用和处理的内容。不要把未获授权的第三方资料、采购的付费报告在超出许可范围的情况下导入。涉及客户资料时，要确认处理方式符合与客户的约定。

个人信息保护：知识库中不应包含不必要的个人敏感信息。如果文档中含有员工或客户的个人信息，导入前应做脱敏处理，并限制知识库的访问范围。

访问控制：知识库内容通常属于企业内部资料，平台后台不应对全网开放。建议在防火墙规则中限制来源 IP，或通过反向代理叠加认证。给不同部门使用时，用平台的权限功能划分可见范围。

输出审核：模型回答需要人工抽查，尤其是用于对外答复客户或辅助业务决策的场景。回答可能包含不准确信息或对资料的错误理解，不宜直接采信。

定期维护知识库：文档会过期。建立机制定期清理失效内容、更新变动的资料。检索到过期文档并据此回答，比检索不到更有害。

部署完成后，如果需要接入本地模型以降低对外部 API 的依赖，或为平台配置统一的域名入口与访问认证，可以作为下一步方向。

需要在同一环境部署本地模型时，高性能应用服务 HAI 的预置 GPU 镜像可以省去驱动配置；只部署平台并调用外部模型 API 的话，云服务器 CVM 在规格调整上更灵活，文档与备份归档可使用对象存储 COS。