告别幻觉，从0到1搭建生产级RAG｜基于华为云ModelArts+昇腾实践

前言

大模型本身存在知识截止、幻觉、私有数据无法识别三大痛点，RAG（检索增强生成）是目前产业落地最成熟、成本可控的方案。 但很多开发者踩了同一个误区：文档上传、切片、入库、调用大模型，就认为RAG做完了。上线之后才发现：召回无关文档、长文档信息丢失、多跳问题答不对、模型强行编造不存在的内容。

RAG的核心不是“向量库+大模型”的简单拼接，而是一套检索、过滤、重排、约束、评测的工程体系。本文使用华为云ModelArts搭配昇腾算力、向量检索服务，搭建企业内部文档问答系统，记录完整流程、调优手段和踩坑经验。

一、RAG整体架构

标准链路： 

用户Query → 查询改写（Query Rewrite） → 多路检索（向量检索+关键词检索） → 结果重排Rerank → 上下文组装 → 大模型生成 → 答案溯源输出

为什么不能只做简单向量检索？ 向量相似度只代表语义相近，不代表内容和用户问题强相关。纯向量检索很容易召回语义相似但无关的段落，模型拿到错误上下文，自然输出错误答案。

二、数据预处理：RAG效果的根基

数据质量直接决定RAG上限，这一步最容易被忽略。

1. 文档清洗：过滤页眉页脚、水印、重复页面、乱码、空白行；PDF、Word、Markdown统一转为结构化文本。
2. 智能切片，拒绝固定长度切块 不要粗暴设置固定512/1024token切片。优先按章节、标题、段落语义边界切分。长表格、代码块单独作为一个切片，避免被拦腰截断。
3. 切片元数据打标 给每一段落带上来源文档、页码、章节标题、更新时间，后续输出答案时可以展示引用来源，实现溯源，方便排查错误。
4. Embedding向量化 在ModelArts中调用Embedding模型，把文本转为向量，写入向量检索服务。Embedding模型优先选择领域适配版本，通用模型在专业文档场景召回效果会明显下降。

三、检索链路优化（重点）

3.1 查询改写

用户提问往往口语化、简短、信息不全。 示例原始问题：“这个服务怎么扩容？” 改写后：“华为云XX服务扩容操作步骤、约束条件、注意事项” 同时生成多个子查询，做多路检索，也就是RAG-Fusion思路，提升复杂问题召回覆盖率。

3.2 混合检索（向量+关键词）

• 向量检索：抓语义相似，适合模糊提问；
• BM25关键词检索：抓专有名词、接口名、错误码、版本号； 两路结果融合，再做归一打分，兼顾语义和精确匹配。

3.3 Rerank重排

多路检索拿到Top50候选段落，送入重排模型，重新计算和用户问题的相关性，过滤低相关内容，保留Top3~Top8送入大模型。 重排是性价比极高的优化手段，很多时候比换更大的Embedding模型收益更高。

四、Prompt约束，压制幻觉

拿到检索片段之后，交给大模型之前，必须在系统提示词增加强约束：

你是文档问答助手，仅允许使用提供的参考资料回答用户问题。
1. 如果参考资料没有相关信息，直接回复：当前知识库暂无相关内容，不要编造；
2. 回答内容必须标注引用来源；
3. 禁止推理资料以外的信息，禁止猜测；
4. 复杂问题分步说明，不要合并无关信息；

仅仅依靠模型自身能力很难杜绝幻觉，必须用Prompt做边界锁定。

五、基于华为云ModelArts的部署方案

两种落地路线，可以按需选择：

1. MaaS托管路线（快速验证） 直接调用盘古大模型、Embedding服务，不用自己部署推理服务。文档上传、向量库、检索、问答全部在ModelArts Studio完成，适合业务快速验证、小团队。
2. 昇腾私有化部署路线（数据敏感、高并发） 在昇腾资源池部署开源模型（Qwen、GLM等），vLLM-Ascend推理框架，向量检索服务独立部署，数据不出租户，适合企业内部核心文档、运维手册、涉密资料。

部署要点：

• 开启批处理推理，提升吞吐，降低单问答成本；
• 接入API网关，增加限流、鉴权、日志审计；
• 缓存高频问题的检索结果与答案，降低模型调用压力。

六、RAG效果评估，持续迭代

RAG不是一次性开发完成就结束，需要建立评测集持续监控：

• 相关性指标：召回率、精确率；
• 幻觉指标：答案是否存在文档没有的信息；
• 引用正确性：答案内容是否和引用片段匹配；

可以在ModelArts评估模块，批量跑测试集，自动统计幻觉率、答错率，发现切片策略、检索策略退化之后及时调整。

常见退化场景：新增文档之后向量库膨胀、业务术语变更、用户提问方式变化，检索效果慢慢变差。

七、常见坑与解决方案

1. 固定长度切块 → 破坏语义，表格、代码断裂 → 语义切片+结构化文档单独处理
2. 只使用向量检索 → 专有名词召回差 → 向量+关键词混合检索
3. 不做重排，直接把Top10丢给大模型 → 无关内容干扰模型 → 增加Rerank
4. 没有溯源机制 → 出问题无法定位是文档错还是检索错 → 切片携带元数据，输出引用链接
5. 知识库长期不更新 → 知识过时 → 建立定时同步、增量更新向量库机制

八、进阶方向：走向Agentic RAG

普通RAG只能回答静态文档里的内容；Agentic RAG可以让模型自主判断：是否需要改写查询、是否需要多轮检索、是否需要调用外部工具。 比如运维场景：先检索故障手册，再调用API查询实例状态，结合两者给出故障排查方案。这也是RAG和Agent融合的主流方向。

总结

RAG的瓶颈往往不在大模型本身，而在数据治理、检索链路、工程约束。 依托华为云ModelArts+昇腾底座，开发者可以把重心放在文档治理、检索策略调优，而不是耗费精力搭建算力集群、推理服务。 一个稳定可用的企业RAG系统，核心追求不是模型参数越大越好，而是答案可溯源、幻觉可控、成本可控、效果可评估。