企业官网建设流程全解析

最近不少读者在后台问我同一个问题：企业内部的文档越来越多，想让大模型直接回答各种规章制度、技术手册和项目沉淀，但试了几次都不理想。直接问模型，它要么一本正经地编答案，要么只能回答训练数据里那些过时的内容；把文档拿去微调，成本高、周期长，文档一变又要重来。那套被反复提起的 RAG 方案，到底能不能真正落地，又该怎么落地？

这篇文章要讲的，就是 RAG 知识库从零到企业级落地的完整路径。先说结论：RAG 目前是知识库问答场景里，在成本、效果、可维护性三者之间平衡得最好的方案，但它不是一个“装好就能用”的插件，真正的难点在切块策略、检索质量、多轮交互设计和工程化保障。文章会从原理讲起，给出技术选型建议，再用完整可运行的代码演示一套知识库问答系统，最后讲清楚企业级部署时的常见坑和最佳实践。

如果你正在做私有知识问答、客服助手、内部文档检索，或者只是想把一堆 PDF 变成可以对话的知识库，这篇文章都值得看完。全文较长，建议先收藏再阅读。

1. 这篇文章真正要解决的问题

1.1 为什么你搭的知识库问答总是“答非所问”

很多人第一次接触 RAG，是在大模型对话界面里上传了一个 PDF，然后问模型：“这个文档讲了什么？”如果文档短，效果还不错；一旦换成几十上百个文档组成的知识库，问题就来了：模型经常把无关内容拼进答案，或者干脆回答“我没有找到相关信息”。于是有人得出结论：RAG 不行。

其实问题往往不在 RAG 本身，而在于三个环节没有做好。第一，文档切分得太随意，关键信息被截断；第二，检索到的内容不够相关，甚至检索错了；第三，生成环节没有约束模型，让它凭“感觉”补充了知识库里不存在的内容。这三个问题，恰恰是 RAG 项目里最考验工程能力的地方，也是本文要重点拆解的部分。

1.2 先理清路线：RAG、微调、长上下文怎么选

在动手之前，有必要把三条主流技术路线放在一起看。

从实际项目来看，RAG 是“知识更新频繁”和“答案需要可追溯”场景的首选。微调更适合改变模型“本身的能力”，而不是用来背文档。长上下文适合处理少量高价值文档，但不适合做成企业级知识库。

1.3 这篇文章能帮你解决什么

读完这篇文章，你会得到三样东西。第一，一套可复用的知识库搭建方法论，包括文档加载、切块、向量化、检索、生成五个环节的取舍；第二，一份可以直接运行的代码示例，基于 Python 生态，跑通最小闭环；第三，一份企业级落地的检查清单，告诉你上线前哪些配置必须调，哪些雷千万不要踩。

2. RAG 的核心概念与适用场景

2.1 什么是 RAG：一场“开卷考试”

RAG 全称 Retrieval-Augmented Generation，检索增强生成。名字看起来很学术，但用开卷考试来类比，一下就懂了。

传统的大模型问答是“闭卷考试”，模型只能依靠训练时记住的知识。你问它一份 2025 年的内部制度，它训练数据里根本没有，自然只能胡编。RAG 的思维是：考试前先给你一本参考资料，你答题的时候，从书里翻出相关段落，再结合自己的理解组织答案。模型参数没有变，但它看到的信息变多了，而且看到的是实时、准确的私有知识。

这个设计带来的直接好处有三个：知识可以秒级更新，不需要重新训练模型；答案可以追溯到原文片段，减少幻觉；私有数据不出内网，降低了数据合规风险。

2.2 RAG 的完整链路

一个标准 RAG 系统由离线索引和在线问答两部分组成。

离线索引阶段：把文档加载进来，清洗后切成小块，每一块用 Embedding 模型转成向量，存入向量数据库。在线问答阶段：用户提问，先把问题转成向量，在向量库中检索最相似的若干文档块，再把问题和文档块一起交给大模型生成答案。

这里有一个新手容易忽略的点：嵌入向量用的 Embedding 模型，和生成答案的大模型，是两个独立的模型。Embedding 模型负责“找资料”，大模型负责“写答案”，两者可以自由组合。这也意味着，检索效果不好时，可以先换 Embedding 模型，不一定非要动生成模型。

2.3 RAG 和 MCP 的区别

最近 MCP（Model Context Protocol）这个概念也很火，很多人会把 RAG 和 MCP 混在一起。简单来说：RAG 是一种“拿什么喂给模型”的范式，MCP 是一种“模型如何调用外部工具和数据”的协议。RAG 关注知识检索与拼接，MCP 关注模型与外部系统之间的标准化通信。

在实际项目里，两者完全可以共存。知识库场景用 RAG 做基础问答，需要查天气、查订单、操作数据库时，可以通过 MCP 接入对应工具。一句话总结：RAG 解决“模型不知道的”，MCP 解决“模型做不了的”。

2.4 从传统 RAG 到 Agentic RAG

传统 RAG 是“用户提问 → 检索一次 → 生成答案”的单轮流水线。它的局限是：问题比较复杂时，一次检索可能不够；有些问题根本不需要检索，直接让模型回答即可；还有的问题需要先检索 A 再根据结果检索 B。

Agentic RAG 的改进是把决策权交给智能体：模型先判断要不要检索，然后决定检索哪些库、检索几轮，甚至根据中间结果调整下一步动作。它的效果更灵活，但也更依赖模型能力，并且推理延迟更高。在做企业级项目时，建议先从传统 RAG 跑通基线，再逐步引入 Agentic 能力，不要一上来就做复杂编排。

2.5 适用场景与不适用场景

RAG 擅长处理的是“知识密集但结构相对固定”的内容：规章制度、产品文档、技术手册、科研论文、客服话术、项目总结。它不擅长处理强推理任务，比如多步骤数学推理；也不适合作为实时事务系统的入口，比如直接让模型根据知识库执行扣款操作。

一句话判断标准：如果任务是“从知识里找答案”，RAG 很合适；如果任务是“根据知识做决策并执行操作”，需要的是 RAG 加上决策流程和权限控制，而不是单纯一个问答接口。

3. 技术选型与架构设计

3.1 向量数据库选型

向量数据库是整个 RAG 系统的核心组件，选型直接决定检索性能和运维复杂度。以下是对比：

个人项目或教学演示，优先选 Chroma 或 FAISS；企业项目如果已有 PostgreSQL 或 Elasticsearch，优先考虑扩展方案；从零搭建并且数据量预估会快速增长的，Milvus 是主流选择。

3.2 编排框架选型

LangChain、LlamaIndex 和 Dify 是目前最常被提到的三个工具。

LangChain 胜在生态丰富，内置大量文档加载器、切块器、向量库适配器，适合开发者深度定制链路。LlamaIndex 的定位更聚焦数据连接与索引，在文档解析、索引结构上做得更细，适合做“数据密集型”应用。Dify 则是可视化低代码平台，把知识库、工作流、模型管理集成在一起，团队里如果有非开发人员，用 Dify 能大幅缩短交付时间。

从企业级实战角度，我给出的建议是：小而美的项目用 Dify 快速验证，复杂定制场景用 LangChain 作为底座，数据管道复杂时考虑结合 LlamaIndex。三个工具并不互斥，也可以配合使用。

3.3 Embedding 模型与生成模型的选择

Embedding 模型决定“检索得准不准”，生成模型决定“答得好不好”。

Embedding 模型的选择标准是：与业务语料分布匹配、支持中文效果好、向量维度与向量库兼容。开源领域常用 BGE、m3e 等系列模型；闭源 API 也有多种选择。判断一个 Embedding 模型是否合适，最直接的办法是拿业务里典型的 50 个问题做召回测试，看 top 5 命中率。

生成模型的选择标准是：指令跟随能力、上下文长度、部署方式和服务稳定性。如果数据不出内网是硬性要求，那就要选可私有化部署的开源大模型；如果没有这个约束，调用成熟 API 能获得更好的生成效果，同时省去 GPU 运维成本。

3.4 企业级架构的分层设计

一个可以支撑生产环境的 RAG 系统，架构上应该分成四层。

接入层负责文档上传、格式转换和数据源管理。处理层负责切块、清洗、Embedding 计算。存储层包含向量数据库、原始文档存储和元数据库。服务层提供检索问答 API、权限校验、审计日志和监控指标。

很多项目失败，不是因为某个组件选错了，而是因为把这四层揉在一起，导致后续每改一个环节都要动全局。建议从一开始就按分层思路设计，哪怕代码量多一点也值得。

4. 环境准备与前置条件

4.1 环境清单

这里以 Python 生态为主，操作系统不限，Windows、macOS、Linux 都可以。建议使用 Python 3.10 或以上版本，创建独立虚拟环境，避免依赖冲突。

硬件方面，如果只做检索和调用外部大模型 API，普通开发机即可。如果需要本地部署 Embedding 模型和生成模型，建议内存 16GB 以上，并配备支持 CUDA 的 GPU。具体的显存要求取决于模型规模，这一点请以实际模型要求为准，本文代码演示默认使用外部 API，不强制要求 GPU。

4.2 安装依赖

创建一个项目目录，并初始化虚拟环境。

mkdir rag-demo cd rag-demo python -m venv venv source venv/bin/activate # Windows 下执行 venv\Scripts\activate

安装核心依赖。这里给出的是一些基础包，版本请以实际安装时为准，建议安装最新稳定版。

pip install langchain langchain-community langchain-openai pip install chromadb pip install pypdf pip install python-dotenv

到这一步，环境已经具备跑通最小示例的条件。下面还要准备一个模型访问配置。

4.3 配置文件

在项目根目录创建 .env 文件，用来保存模型 API 的密钥和基础配置。

# .env OPENAI_API_KEY=your-api-key-here OPENAI_BASE_URL=https://api.example.com/v1 EMBEDDING_MODEL=text-embedding-3-small LLM_MODEL=gpt-4o-mini

这里做两点说明。第一，上面的地址只是占位示例，实际请填入你的模型服务商地址和密钥，注意不要提交到代码仓库。第二，如果你想体验国内开源模型的私有化部署，可以替换为相应模型的本地服务地址，代码逻辑不变。

4.4 准备测试文档

在项目目录下创建 docs 文件夹，放入一个或多个 PDF 或 txt 文件作为测试语料。建议先用 1 到 2 个主题集中的文档跑通，再逐步增加数据量。测试文档的内容最好是知识型的，比如产品说明书、制度文档或者技术教程，这样效果容易判断。

5. 核心流程拆解

5.1 文档加载：格式混杂是第一个坑

文档加载的目标是把 PDF、Word、Markdown、HTML 等不同格式统一提取为纯文本。实际项目中，这一步最容易被低估。

PDF 看起来简单，但扫描件需要 OCR，表格和分栏排版经常导致文字顺序错乱。Word 文档里嵌入的图片和文本框也可能丢失。更麻烦的是，同一批文档往往来自不同系统，格式五花八门。稳妥的做法是：先做格式归一化，统一转成 Markdown 或纯文本，再做清洗，去掉页眉页脚、重复标题和无关字符。

5.2 切块策略：RAG 效果的隐形决定因素

切块是 RAG 里最容易被忽视，却又直接影响检索质量的环节。

切得太小，比如一句话一块，语义不完整，检索出来的片段可能缺少上下文；切得太大，比如整个章节一块，向量表示会被稀释，检索精度下降，而且占用的 token 也多。常见的选择是按固定字符数切块，并设置重叠区域，保证跨块语义不断裂。

更高级的做法是结构化切块：按标题层级把文档切成树状结构，或者按段落、句子边界做语义切块。对企业文档来说，先按章节切、再按段落切，通常比纯固定长度效果好。在代码里，LangChain 提供了多种切块器，最常用的是 RecursiveCharacterTextSplitter。

5.3 向量化：Embedding 的选择与注意点

向量化就是把文本变成一串浮点数，让语义相近的文本在向量空间中距离更近。这里的关键是：Embedding 模型对中文的支持度、向量维度和成本。

如果你用的是开源 Embedding 模型，通常需要先启动一个本地推理服务，再通过 API 调用。如果你用云 API，只需要配置好密钥。这里有一个实战建议：评估 Embedding 模型时，不要只看榜单分数，要用自己的业务问题去测试召回效果。

5.4 向量存储：不只是存向量

向量数据库存入的不仅仅是向量本身，还要保存原始文本和元数据。元数据包括文档名、页码、章节标题、更新时间等。这些信息在后续做权限过滤、来源追溯和结果展示时非常重要。

建索引时的参数也要注意，比如距离算法选余弦相似度还是内积，索引类型选 HNSW 还是 IVF。不同向量库参数不同，但对中小数据量，默认配置通常就能满足需求。

5.5 检索与生成：把结果拼成好答案

检索阶段，把用户问题转成向量，在向量库里找出最相似的 Top-K 个片段。K 的取值需要根据上下文长度和数据质量调整，太小可能漏信息，太大可能引入噪声。

生成阶段，把检索到的片段按一定模板组织成上下文，连同用户问题一起交给模型。关键在于提示词的设计：要让模型优先基于上下文回答，无法回答时明确说不知道，不要强行编造。同时要求答案带有来源标注，便于用户核验。

6. 完整示例代码实现

6.1 示例一：构建知识库索引

下面的脚本实现文档加载、切块、向量化并写入 Chroma 的全部流程。文件路径：rag_demo/build_index.py

# rag_demo/build_index.py import os from dotenv import load_dotenv from langchain_community.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_openai import OpenAIEmbeddings from langchain_community.vectorstores import Chroma load_dotenv() # 1. 加载文档 loader = PyPDFLoader("docs/产品手册.pdf") documents = loader.load() # 2. 切分文档 text_splitter = RecursiveCharacterTextSplitter( chunk_size=500, chunk_overlap=50, separators=["\n\n", "\n", "。", "！", "？", " ", ""] ) chunks = text_splitter.split_documents(documents) print(f"切分后文档块数量: {len(chunks)}") # 3. 初始化 Embedding 模型 embeddings = OpenAIEmbeddings( model=os.getenv("EMBEDDING_MODEL"), base_url=os.getenv("OPENAI_BASE_URL"), api_key=os.getenv("OPENAI_API_KEY"), ) # 4. 写入向量库 vector_store = Chroma.from_documents( documents=chunks, embedding=embeddings, persist_directory="./chroma_db", ) print("向量索引构建完成，已保存到 ./chroma_db")

这段代码的关键逻辑：PyPDFLoader 用来读取 PDF；RecursiveCharacterTextSplitter 按层级分隔符切块，优先保留自然段边界；OpenAIEmbeddings 负责将文本转成向量；Chroma.from_documents 完成向量入库并自动持久化。

6.2 示例二：RAG 问答链

索引构建完成后，写一个问答脚本。文件路径：rag_demo/ask.py

# rag_demo/ask.py import os from dotenv import load_dotenv from langchain_openai import OpenAIEmbeddings, ChatOpenAI from langchain_community.vectorstores import Chroma from langchain_core.prompts import ChatPromptTemplate from langchain_core.output_parsers import StrOutputParser from langchain_core.runnables import RunnablePassthrough load_dotenv() embeddings = OpenAIEmbeddings( model=os.getenv("EMBEDDING_MODEL"), base_url=os.getenv("OPENAI_BASE_URL"), api_key=os.getenv("OPENAI_API_KEY"), ) vector_store = Chroma( persist_directory="./chroma_db", embedding_function=embeddings, ) retriever = vector_store.as_retriever(search_kwargs={"k": 4}) prompt = ChatPromptTemplate.from_messages([ ("system", """你是企业内部知识助手。请基于以下检索到的资料回答问题。 如果资料中没有答案，请直接回答"根据现有知识库无法回答该问题"。 回答末尾标注引用的文档来源。 资料： {context}"""), ("human", "{question}"), ]) llm = ChatOpenAI( model=os.getenv("LLM_MODEL"), base_url=os.getenv("OPENAI_BASE_URL"), api_key=os.getenv("OPENAI_API_KEY"), temperature=0.2, ) def format_docs(docs): return "\n\n".join(doc.page_content for doc in docs) rag_chain = ( {"context": retriever | format_docs, "question": RunnablePassthrough()} | prompt | llm | StrOutputParser() ) if __name__ == "__main__": while True: question = input("请输入问题（输入 exit 退出）：") if question.strip().lower() == "exit": break answer = rag_chain.invoke(question) print("\n" + "=" * 50) print("答案：", answer) print("=" * 50 + "\n")

代码的核心是构建了一个 RAG 链：先用 retriever 检索相关文档块，format_docs 把文档块拼成上下文，然后填充到提示词模板中，交给大模型生成答案，最后通过 StrOutputParser 输出为纯文本。

6.3 示例三：文档来源追溯

生产环境里，答案必须能追溯到原始文档。可以在格式化上下文的函数里把元数据一并输出，也可以单独实现一个带来源的问题脚本。文件路径：rag_demo/ask_with_sources.py

# rag_demo/ask_with_sources.py from ask import vector_store, llm, prompt, format_docs retriever = vector_store.as_retriever(search_kwargs={"k": 4}) def ask_with_sources(question: str): docs = retriever.invoke(question) context = format_docs(docs) final_prompt = prompt.invoke({"context": context, "question": question}) answer = llm.invoke(final_prompt).content print(f"问题：{question}\n") print(f"答案：{answer}\n") print("参考来源：") seen = set() for doc in docs: source = doc.metadata.get("source", "未知来源") page = doc.metadata.get("page", "") key = f"{source}-{page}" if key in seen: continue seen.add(key) print(f"- {source} 第{page}页") print("=" * 50) if __name__ == "__main__": ask_with_sources("产品支持哪些无线协议？")

这段代码演示了如何把检索到的文档元数据暴露给用户。注意 ask_with_sources.py 与 ask.py 在同一个目录下，这里以模块导入的方式复用了 ask.py 中的对象。实际项目中，更推荐把公共初始化逻辑统一放到一个模块，避免重复创建连接。

7. 运行结果与效果验证

7.1 运行方式

按顺序执行两个脚本。

python rag_demo/build_index.py python rag_demo/ask.py

如果索引已经存在，build_index 脚本会继续追加文档，不会重复构建整个库，但要注意幂等性设计。在真实项目中，建议为每个文档生成哈希，避免同一文档反复入库。

7.2 预期输出

build_index 脚本正常运行会输出切分后的文档块数量，并提示索引已保存。ask.py 启动后，输入问题即可得到答案。

请输入问题（输入 exit 退出）：产品支持哪些无线协议？ ================================================== 答案：根据手册内容，产品支持 Wi-Fi 6 和蓝牙 5.2 两种无线协议。 ==================================================

这里要提醒一句：输出结果的质量高度依赖检索到的文档块。如果答案明显不对，优先检查检索环节，而不是怪大模型。

7.3 如何判断 RAG 系统“好用”

判断 RAG 效果，可以从两个层面来看。

检索层面，看召回率：针对测试问题集，检查 Top-K 结果里是否包含正确答案相关的文档块。生成层面，看答案正确性和忠实度：答案是否准确，以及是否严格基于检索到的内容，有没有画蛇添足。

实操中建议先准备 30 到 50 个有标准答案的测试问题，跑一遍系统，统计人工评估的正确率。正确率低于 70% 时，先不要优化提示词，而是回头检查文档加载和切块策略，这通常才是瓶颈所在。

7.4 常见失败场景的快速定位

如果检索为空，先确认向量库是否写入成功，再打印检索到的文档块内容。如果检索有结果但答案不好，把检索到的内容打出来人工看一遍，判断是切块切碎了，还是检索到的内容本身不相关。如果答案好但速度慢，检查 Embedding 和生成模型各自的耗时占比，再做针对性优化。

8. 常见问题与排查方法

这些问题是知识库项目里最高频的几类。大部分情况下，问题的根源不在模型，而在数据管道的某个细节。定位问题时，先看数据流到哪一步断了，比反复调整模型参数更有效。

9. 最佳实践与工程建议

9.1 切块参数怎么调

没有通用的黄金参数，chunk_size 和 chunk_overlap 需要根据文档类型测试。一般建议从 300 到 800 字符开始尝试。技术手册类文档可以稍大，对话类语料可以稍小。overlap 设置为 chunk_size 的 10% 到 20%，重点保证跨块句子不断裂。

调整后，用一组固定的测试问题对比召回效果。把每次实验结果记录下来，形成一份“切块参数调优记录”，这对后续团队协作和问题回溯都很有价值。

9.2 检索质量是 RAG 的生命线

检索质量不高，后续生成再好也白搭。提升检索质量的常见手段包括：多路召回，即把向量检索和关键词检索的结果合并去重；元数据过滤，比如按部门、文档类型、时间范围过滤后再检索；混合检索，用 Rerank 模型对召回结果做二次排序。

在企业级项目中，Rerank 是非常值得投入的一环。向量检索负责“召回够宽”，Rerank 负责“排序够准”，两者配合能明显提升最终答案准确率。

9.3 多轮对话怎么设计

很多知识库问答系统做到了单轮问答，却卡在了多轮对话。

多轮对话的核心问题是：用户说“那它的价格呢”，如果不结合上文，“它”就无从解析。常见的做法有两种。一种是在检索前做 Query 改写，把“它”替换成上文中的实体，再拿去检索；另一种是把历史对话摘要和当前问题一并作为检索输入。比较稳妥的是先做 Query 改写，再检索当前问题，最后把历史对话摘要也放入生成提示词，保证模型理解上下文。

不要把所有历史对话全部塞进上下文，既浪费 token，又容易引入噪声。控制在最近三轮到五轮，配合摘要压缩，效果通常更好。

9.4 安全与权限设计

知识库里的文档往往带有部门敏感属性，不能一刀切开放。生产环境需要注意：向量检索结果在返回给模型之前，先做权限过滤，确保用户只能看到有权访问的文档块；API 层加入身份认证与访问控制；对用户提问和模型回答做审计日志，便于追溯。

这里特别提醒：不要把密钥和配置写进代码仓库。.env 文件加入 .gitignore，生产环境建议使用配置中心或密钥管理服务。

9.5 从 Demo 到生产的注意事项

Demo 能跑通和系统能上线，差别很大。上线前建议逐一确认：数据更新链路，文档变更后索引是否需要增量更新；并发能力，多个用户同时问答时的队列和限流策略；监控告警，检索失败率、响应耗时、模型调用错误率都要有指标；回滚方案，提示词或索引配置修改后，如何快速回退。

还有一个容易被忽略的细节：评估体系要提前建立。哪怕是简单的 50 道测试题加人工评分，也比上线后凭感觉判断“好不好用”可靠得多。建议固定一个版本化的测试集，每次改完能力后都跑一遍，用分数说话。

9.6 下一步可以怎么深入

跑通本文的最小闭环之后，可以往几个方向继续深入：引入 Rerank 做重排序；用 Milvus 替换本地向量库，支撑更大数据量；为知识库增加增量更新和版本管理；探索 Agentic RAG，让模型自主决定检索策略和多轮查证；还需要关注 RAG 评估体系，比如用 LLM 自动评判答案正确性和忠实度。

无论往哪个方向走，都建议保持一条主线：先把一条链路做深做透，再扩展分支能力。知识库系统表面上是一套检索加生成的技术组合，真正拉开差距的，是对数据管道的打磨和对评估闭环的坚持。这也是企业级 RAG 项目从“能跑”到“好用”之间，最值得投入的部分。