企业官网建设流程全解析

很多第一次接触 RAG（Retrieval-Augmented Generation，检索增强生成）的开发者，都会把它理解成“给大模型配一个知识库”。这个说法没错，但只说到了一半。RAG 真正解决的，不是“多存一些知识”，而是“让大模型在回答时，能像人一样先去查资料，再开口说话”。我今天不打算给你复述一遍文档式的概念，而是直接从原理讲起，把企业落地时那些文档里不会写的环节，以及踩过的坑，一次性讲透。这篇文章适合正在做技术选型、准备把 RAG 接入业务系统、或者已经在做 RAG 项目但效果不理想的同学。目标只有一个：让你看完之后，能用自己的话讲清楚 RAG 原理，知道企业级应用该怎么设计，遇到问题时也有清晰的排查思路。

我最早接触 RAG 是在做企业内部知识库问答的时候，当时大模型刚火起来，老板拍板说“把公司几千份文档扔进去，让员工直接问”。听起来很酷，做起来才发现，从文档进库到答案出来，中间每一个环节都藏着坑。今天这篇文章，就是我后来把那些坑一个个填平之后整理出来的完整复盘。

1. RAG 原理拆解：从 DNA 到工作流

1.1 为什么需要 RAG：大模型的能力边界在哪

大模型的本质，是一个“语言先验概率模型”。它接受了海量文本的训练，学到的知识截止于训练数据那一刻。这意味着它天生有两个硬伤：一是不知道训练数据之后发生的时事，二是对于它没见过、没学透的私有领域知识，会一本正经地“编”。

我常用一个类比：大模型像一个博览群书但从不查证的优等生。你问它历史事件，它能答得头头是道；你问它公司上季度销售额，它只能猜，而且猜错了还嘴硬。这不是模型不够聪明，而是它根本没有渠道去获取这些信息——你不可能把一家公司的内部经营数据放到公开互联网上让它学。

这时候 RAG 出现了。它的思路非常朴素：既然模型不知道，那就先查出来给它看。回答问题时，先从外部知识库检索出相关内容，把检索结果放到提示词里，再让模型基于这些新信息生成答案。这样一来，模型不需要“记住”你的私有数据，它只需要“读懂”你给它的数据。

这个思路的价值在企业场景里怎么强调都不为过。企业知识库是高度动态的，新文档天天产生，旧的还在不断修订。如果靠微调，每次知识变化都要重新训一遍模型，时间和成本都是天文数字。RAG 完全绕开了这个问题——知识变化时，只需要更新外部知识库，模型本身一行参数都不用动。

1.2 RAG 的核心工作流程：索引、检索、生成三阶段

RAG 的完整流程可以拆成两个阶段、三个环节。第一阶段叫“索引”（Indexing），是离线完成的；第二阶段叫“检索与生成”（Retrieval & Generation），是在每次用户提问时实时发生的。

离线索引阶段做的，是把原始文档“翻译”成大模型和向量检索引擎都能理解的形式。首先是文档解析，把 PDF、Word、HTML 等各种格式的文本内容提取出来；然后是文本清洗，去掉页眉页脚、乱码、无关的图片说明；接着是文本切分，把长文档切成一个个有独立语义的段落，这个切出来的小块叫 Chunk；最后是向量化，用 embedding 模型把每个 Chunk 转换成一个高维向量，连同原文一起存进向量数据库。

在线检索生成阶段做的，是把用户问题也变成向量，去向量库里做相似度检索，找出最相关的几个 Chunk，然后把用户原始问题和这些 Chunk 拼成一个精心设计过的 Prompt，交给大模型去生成最终答案。这里有个很容易被忽略的点：检索出来的 Chunk 一定要带上原文来源，这样模型在回答时才能做到“言之有据”。

这两个阶段设计得很干净。离线索引就像建图书馆，把所有书编好目、摆上架；在线检索就像读者来问问题时，图书管理员先去书架上把相关的几本书找出来，再让人工智能助手翻开书来回答。

1.3 RAG 类别与流程演进：从 Naive RAG 到 Advanced RAG

如果你去看 RAG 相关的论文，会看到 Naive RAG（朴素 RAG）、Advanced RAG（进阶 RAG）、Modular RAG（模块化 RAG）这些名词。有些刚接触的人会被这些术语劝退，其实它们的差别说白了就是“往流水线上加了多少道工序”。

Naive RAG 就是最基础的“索引-检索-生成”三步走。它的特点是实现简单，用一个 20 行代码的脚本就能跑起来。但它的短板也很明显：检索出来的内容可能相关性不够，知识冲突时模型不知道怎么取舍，多个子问题纠缠在一起时只能笼统回答。我在博客开头说的“原理简单但落地难”，指的就是这个基础版本在实际业务数据上往往表现不稳定。

Advanced RAG 在 Naive RAG 的基础上做了一系列优化。比如在检索前增加查询改写和路由，把用户一句模糊的话拆成几个具体的小问题；比如在检索后增加重排序，用专门的 Rerank 模型把初步召回的结果重新精排；比如在生成时引入可引用的原文片段，增强可信度。以上每一步，都是从“能用”走向“好用”的关键升级，也是企业落地时我强烈建议采用的标准形态。

Modular RAG 则更进一步，把整个流程拆成独立的模块，允许根据任务灵活地组合和替换。比如同一个系统中，财务问答走“表格解析+SQL 查询”的模块，制度问答走“语义检索+重排”的模块，互不干扰。这已经不是单一的技术方案，而是一套可编排的技术架构了。

2. 企业级 RAG 应用：哪些环节决定成败

2.1 架构设计：企业级 RAG 的六层架构

把一个企业级 RAG 系统拆开来看，它不只是“向量库 + 大模型”这么简单。一个能应付真实业务压力的架构，从上到下至少要分六层。

第一层是接入层，负责对接收口，比如 Web 对话界面、IM 机器人、API 服务；第二层是应用逻辑层，负责处理用户请求，包括问题理解、对话状态管理、调用编排；第三层是检索增强层，这是 RAG 的核心，包含查询改写、检索策略、重排和上下文组装；第四层是数据管道层，负责文档接入、解析、清洗、切分、向量化、增量更新；第五层是存储层，包含向量数据库、关系数据库（存知识图谱、业务数据）和文档存储；第六层是模型层，包含最终生成用的大模型和 embedding 模型。

这种分层设计不是学究式的教条，而是工程上的必然。我在做过的一个合规问答项目里，就吃过“没有分离数据管道和检索”的亏。刚开始为了省事，文档更新直接用脚本重灌，结果线上检索时总返回旧版本的内容。后来把数据管道单独拆出来，加了版本管理和增量更新机制，问题才解决。分层不是为了好看，是为了让每一层能独立演化、独立排查故障。

2.2 企业知识接入：不只是把文档扔进去

企业数据远比公众想象的复杂。我问过很多准备做 RAG 的团队：“你们打算接入哪些数据？”得到的回答通常是“我们就把 PDF 传上去啊”。但等真正开始做，会发现数据接入是整个项目里第一个大坑，也是埋得最深的一个坑。

先碰到的是格式问题。企业里存量的文档格式非常杂，PDF（尤其是扫描件）、Word、PPT、Excel、邮件、网页、Markdown、甚至图片。每种格式都需要不同的解析方式。扫描件 PDF 必须走 OCR，不然提取出来的全是乱码；Excel 里的表格如果按普通文本抽取，行和列的对应关系就全丢了；PPT 上文字少、图片多，只提文字会丢失大量信息。

这里要专门说一下“RAG 知识库能存储图片吗”这个问题。答案是：直接放在传统 RAG 流程里存图片，效果很差。原因在于主流 embedding 模型只能处理文本，图片无法直接变成语义向量参与检索。如果一定要支持图片，比较靠谱的做法是走多模态路线：提前用视觉理解模型（如 GPT-4V、Qwen-VL）把图片内容转换成文字描述，再把描述存进向量库。用户提问时检索到的是图片的文字描述，生成时再把图片原图附上。这个方案我实测过，在识别产品结构图和流程图场景下非常可靠，但缺点是需要额外的模型调用成本和时间。

数据接入时还有几个经典坑。比如文档里的页眉页脚会大量出现在切片里，检索时常常被误当成正文；再比如表格拆出来后数字被解析成乱码；还比如同一份文档的多个版本同时进库，导致回答内容前后矛盾。这些都是数据管道层必须解决的脏活累活。

2.3 检索优化：三个立竿见影的实战技巧

检索是整个 RAG 系统的核心命脉——检索不到内容，生成环节再强也无米下锅；检索出错误内容，模型只会把错误顺着思路放大。这个道理我是在第一个生产事故里刻骨铭心学到的：当时用户问“出差补贴标准”，系统召回的却是“差旅管理办法”里一句无关的引言，大模型就凭这一句，自作主张生成了一篇前言不搭后语的解释。

第一个技巧是混合检索。向量检索擅长语义相似，但对关键词精确匹配不敏感；BM25 这类稀疏检索擅长关键词命中，但理解不了同义改写。把两者结果合并，再用 Rerank 模型做最终精排，是一种经过大量实战验证的有效组合。举个例子，用户问“报销流程怎么走”，向量检索能找到“费用报销管理办法”，但可能漏掉 A 部门专门写的“部门内部报销指引”；BM25 能从“报销”这个关键词命中后者。两者取并集，召回完整度会高很多。

第二个技巧是查询改写。用户真实提问往往是口语化的、模糊的、上下文依赖的。比如前一秒问“杭州的报销标准”，下一秒问“那出差呢”，后一个问题单独拿去检索就是句废话。合理的做法是先让大模型结合对话历史，把“那出差呢”改写成“杭州出差的报销标准是什么”，再去做检索。这一步看似简单，对召回准确率的影响是决定性的。

第三个技巧是重排序。无论混合检索召回了多少条，真正能塞进大模型上下文的只有顶部少数几条。如果直接用向量相似度排序，难免出现“语义相似但不直接回答问题”的干扰项。Rerank 模型是用标注好的“查询-文档”相关性数据专门训练的，它的排序准度显著好过纯向量距离。一般来说，召回 50 条、重排后取 top 5，比直接取 top 5 的效果要好得多。

3. 工程化实践：从框架选型到本地部署

3.1 主流 RAG 框架横向对比与选型建议

现在做 RAG 的框架非常多，很多同学上来就问“哪个框架最好”。我的回答是：没有最好，只有最合适。关键要看你的团队的技术栈、部署环境和业务复杂度。

LangChain 是生态最丰富的框架，它提供的模块化组件几乎覆盖了 RAG 的方方面面，从文档加载器、文本切分器到各种检索器、Agent 工具，都能找到现成的。但它的学习曲线比较陡，版本迭代快时 API 变动频繁，我见过不止一个项目被 LangChain 版本升级折腾得痛不欲生。

LlamaIndex 是另一个重量级选手，它对数据索引和检索的抽象非常深入，文档切分策略、索引类型、检索器组合都很专业。如果你的项目是数据密集型，比如要把一堆异构数据源统一成一个查询入口，LlamaIndex 会很顺手。

LangChain4j 和 Spring AI 则是 Java 生态的答案。很多正经企业和金融机构的后端是 Java 写的，要让团队用 Python 重写服务并不现实。LangChain4j 直接给 Java 开发者提供了类似 LangChain 的能力；Spring AI 也提供了 Spring Boot 风格的 RAG 支持，对已经深度使用 Spring 的团队来说上手成本很低。

工具链方面，向量数据库的选择也很关键。常见的选项包括专业向量库 Milvus、轻量级 Chroma、云原生托管服务（如云厂商的向量检索产品）以及带向量插件的 PostgreSQL。对中小企业或者快速验证的项目，用带向量能力的 PostgreSQL 就够了，少维护一个中间件；数据规模过千万级、对查询延迟有硬要求的，再考虑 Milvus 这类独立向量库。

3.2 用 Ollama 搭建本地 RAG 知识库：零基础可复制的实操记录

很多人在搜“RAG 教程”时，最想找的是一个能真正跑起来、不需要花大价钱买 API 的方案。这里分享一套我一直在用的本地部署方案，技术栈是“Ollama + 本地 embedding 模型 + Chroma + LangChain 或 LlamaIndex”，全程可以在自己电脑上跑通。

先说为什么选 Ollama。Ollama 是一个非常顺手的本地大模型运行工具，一行命令就能拉起模型服务，而且它对硬件要求相对友好，支持 Mac 的 M 系列芯片和带 CUDA 的 NVIDIA 显卡。相比直接部署原版大模型框架，Ollama 把依赖管理和启动流程简化了不止一个量级，对“零基础可复制”这件事来说，它就是最优解。

第一步是安装和拉取模型。以 Ollama 为例，装完后在终端执行两条命令，一条拉取对话用的生成模型（比如 qwen2.5 系列），一条拉取文本向量化用的 embedding 模型（比如 nomic-embed-text）：

ollama pull qwen2.5:7b ollama pull nomic-embed-text

第一次拉取会花一些时间，取决于网络和模型体积。拉取完成之后，可以用命令行直接测一下对话模型是否正常响应，确认环境没问题再往下走。

第二步是把文档接进来。这里我用的是 LangChain 的目录加载器。把需要建库的几个纯文本文件放在同一个文件夹里，按下面这段代码处理：

from langchain_community.document_loaders import DirectoryLoader, TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.embeddings import OllamaEmbeddings from langchain_community.vectorstores import Chroma loader = DirectoryLoader("./knowledge", glob="**/*.txt", loader_cls=TextLoader) documents = loader.load() splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50) chunks = splitter.split_documents(documents) embeddings = OllamaEmbeddings(model="nomic-embed-text") vectordb = Chroma.from_documents(chunks, embeddings, persist_directory="./chroma_db") vectordb.persist()

这段代码做了几件事：加载文件夹里所有 txt 文件，用递归字符切分器把长文本切成 500 字符一块、相邻块重叠 50 字符的片段，然后调用本地 Ollama 的 embedding 接口，把每块文本转成向量，最后存入 Chroma 向量库并持久化到本地目录。

第三步是检索回答。用 Ollama 拉起本地大模型，从 Chroma 里按相似度检索相关片段，组装成 Prompt 后发给模型。为简洁，核心就三行：

from langchain_community.llms import Ollama from langchain.chains import RetrievalQA llm = Ollama(model="qwen2.5:7b", temperature=0) qa = RetrievalQA.from_chain_type(llm, retriever=vectordb.as_retriever(search_kwargs={"k": 4})) print(qa.run("公司的出差补贴标准是多少？"))

这里把 temperature 设为 0 是为了让模型尽可能忠实于检索到的上下文，减少自由发挥。把 k 设为 4 意味着检索器每次召回 4 个最相关的文本片段，这个数值可以根据实际效果调整，不是固定不变。

这套方案在普通办公笔记本上就能流畅运行，适合拿来做概念验证、学习原理，也适合对数据保密要求极高、绝不能出内网的企业做内网部署。它虽然是“简易版”，但骨架完整，从文档接入、切分、向量化到检索回答，企业级 RAG 的所有核心环节都跑到了。

3.3 从“能用”到“好用”：性能评估体系怎么搭

很多团队做完 demo 之后欢呼“能答了”，但一上生产就发现问题的真正原因，往往是缺少一套“好不好用”的评估体系。RAG 项目没有评估标准，就像体检不验血、不拍片，光靠医生问诊，结果只能靠猜。

在业界，RAG 评估最常用的框架是 RAGAS。它围绕三个核心指标展开：忠实度，衡量“回答是否严格基于检索到的上下文，有没有自我发挥”；答案相关性，衡量“回答是否切实解决了用户的问题”；上下文相关性，衡量“检索到的文本片段本身跟用户问题是否相关”。这三个指标分别对应 RAG 的三个环节：检索、增强和生成。任何一个环节出问题，都能通过对应指标暴露出来。

搭建评估体系的实操方法是：准备一份带标准答案的评测集，至少包含 100 条有代表性的真实用户问题，每条问题标注好“标准答案”和“应召回的文档 ID”。然后跑一遍系统，计算 RAGAS 指标和人工抽检比例。因为答案由大模型生成，同一问题每次结果可能不同，所以还要固定随机种子。我在项目中通常还会加一个“不回答率”指标——模型明知没有相关内容时，能不能老老实实说“不知道”，而不是硬编。这一点在很多企业的合规场景里极端重要。

4. 企业落地常见问题与排查技巧实录

4.1 “答非所问”的追踪排查速查表

RAG 系统上线后被吐槽最多的现象就是“答非所问”。用户问的是一个，系统答的是另一个。可排查的链路却很长：解析、切分、向量化、检索、重排、提示词、生成，任何一环都有可能出问题。我给团队整理过一张追踪排查速查表，按嫌疑环节从高到低排列：

排查的核心方法论是“分段验证”。不要从用户问题直接跳到“模型答得不对”，而是先手工检索一遍，直接看到的召回片段到底相关不相关。如果检索结果已经错了，后面生成再怎么调都是白搭。这个问题我自己踩过最大的坑，就是花了大量时间调 prompt 想“让模型更准确”，后来发现语言模型根本没有拿到正确内容。

4.2 企业级特有难点：多租户隔离与权限控制

个人项目可以不管权限问题，企业级应用完全不行。举个例子，某部门的一份内部薪酬文档进入了知识库，一个没有权限的普通员工提问时，RAG 系统把这份文档的内容检索出来并生成答案，这就是严重的数据安全事故。

权限控制需要在检索引擎层面做，而不是在生成层面“叮嘱模型不要提”。可靠的方案是为每个文档打上权限标签，建立“文档级访问控制列表”，检索时根据用户的角色和组织关系做过滤，在召回结果进入 prompt 之前强制删除无权限内容。我在实际项目里还遇到过一种更隐蔽的情况：文档本身没有明确密级，但它是某位高管的个人汇报材料，系统应该基于“作者敏感度”做降权处理。这种规则很难用自动化穷举，所以最后设计成了“默认安全”原则——没有明确标注可公开的文档，默认不让普通用户检索到。

打个比方，知识库就像医院的门诊档案室。档案室管理员给医生调档案，先要验证“这个医生是不是这位患者的主治医师”，验证通过才把档案递出去。RAG 系统的检索过程也必须做到这一步，而不是把整个档案室复印一份送给所有人。

4.3 三个亲历教训与经验沉淀

复盘这些年做过的 RAG 项目，有三件事是我特别想让刚入门的同学避开的。

第一件是“不要神化 RAG 的检索能力”。RAG 检索做的是相似度匹配，不是逻辑推理。你给它一句话“公司最低温度是多少摄氏度”，它对“公司最低温度”可能一头雾水，因为它理解为物理温度，而你的文档里写的是“最低库存温度”。遇到这类情况，不要指望调整 embedding 或换更大的模型就能解决，更实际的思路是“规则兜底”——用关键词字典或小模型做一次粗筛，先判断用户问的是哪个领域，再进入领域对应的检索过程。

第二件是“生产环境的瓶颈不只是模型，更多在数据管道”。我参与过一个金融项目，模型选型、检索优化都做得不错，但数据管道每天凌晨跑批之后，向量库里总有几个文档重复、几十个文档带了脏格式。如果你只给业务方看 QA 效果，他们会觉得挺好；一旦遇到用户问“昨天的这份新文件里的数字为什么和一个小时前文件里不一样”，问题就暴露了。后来我把数据管道改造成支持“幂等更新”、带版本校验、每次更新产出一份数据质量报告，才算真正稳定。

第三件是“投入精力的优先级：高质量数据 > 高级模型 > 复杂提示词”。这句话我反复在内部技术分享里强调。团队的注意力总是本能地被新模型、新框架吸引，但真实拉低 RAG 效果的头号原因，永远是源头的问题：解析失败、脏数据、切分粒度不当。每当你准备花两周时间研究一个新的 RAG 框架时，先问问自己：当前这版数据如果人工肉眼检查，质量过关了吗？

4.4 可扩展的方向：RAG 与 Agent、Graph 的融合

RAG 不是终点，它只是一个组件。两条值得关注的演进路线是 Agent 和 GraphRAG。

Agent 与 RAG 结合，解决的是“多步推理任务”。传统 RAG 是一次问答一个轮回，而 Agent 可以在内部把复杂问题拆成多个子问题，分步检索、分步验证、再汇总回答。举例来说，“对比今年一季度和去年四季度的销售数据”这类问题，单次检索很难完整解决，Agent 方式会先检索今年一季度数据，再检索去年四季度数据，最后用大模型对比生成。这种模式本质上是把 RAG 从“单次查资料”升级为“多步查证”。

GraphRAG（严格说是 Graph-enhanced RAG）解决的是“分散信息整合”的问题。文档与某些信息散布在许多不同片段中，即使都检索出来，模型也很难把它们的关联关系串起来。GraphRAG 会先使用大模型从文档里抽取实体与关系，建成本地知识图谱，然后通过图和向量混合检索。这种思路在“某产品有哪些供应商”这类需要跨文档关联的问题上，效果比纯向量检索好得多。热词里有“ontology rag”，如果企业有现成的业务本体/知识图谱，可以尝试把图谱下的相关实体作为检索约束，能有效缩小候选范围，减少无关内容干扰。

5. 最后再说点实在的

说了这么多原理、框架和体面话，归根到底最重要的是摆清楚一条主线：对多数团队来说，先让一个足够窄但足够深的应用场景跑通，比如“制度问答”或者“产品手册问答”，哪怕知识和流程都不算宽，也比做一个什么都接、但什么都答不准的大而全系统好。RAG 项目的每一层都需要基于反馈持续调优，不是一次性交付。

我个人在实践中的体会是，先把数据质量管好、评估搭好，再去谈更高阶的技术。很多团队一上来就折腾 Rerank 和 GraphRAG，但本体的干净程度和切分粒度连第一次复查都过不了，最后只会一遍遍怀疑“RAG 是不是不行”。其实不是 RAG 不行，是你还没有把它该做的事做到位。从你手头最小的数据集入手，按这篇文章里的流程走一遍，先跑通，再调好，最后再让它变强大，你会发现所有高深技术都只是在你把基本功磨扎实之后自然生长出来的。