企业官网建设流程全解析

收藏！小白程序员轻松入门RAG知识库构建，让大模型更懂你的私有数据

最近半年，我几乎每天都能收到类似的问题：公司有几百份内部文档、合同、技术方案，能不能让大模型学会这些内容？直接丢给大模型又不现实，上下文窗口再大也塞不下，而且它随时可能在关键细节上编造答案。很多人第一反应是“训练一下模型嘛”，但真正走上这条路之后才发现成本高、周期长、更新慢。我跟几个做开发的同事私下聊，发现大家最终都收敛到了同一个方案：RAG，也就是检索增强生成。

RAG的核心思路其实很简单粗暴：与其试图让模型记住你的文档，不如在每次问答的时候，先从你的私有数据里找出最相关的内容，把这些内容连同问题一起喂给大模型，让它基于这几段“参考资料”来回答。这样一来，模型不需要被重新训练，你的数据也不需要外泄到第三方，而且每次更新知识库只需要改文档，不需要重新跑训练流程。对于手里有大量内部文档、想做企业知识库问答、或者想给个人笔记做个AI助手的开发者来说，这是当前性价比最高的落地方式，没有之一。

这篇文章我就用最直白的方式，从原理到代码一步步拆解，把我自己从零搭建RAG知识库时候踩过的坑、调过的参、换过的方案全部摊开来讲。不管你是刚转行做AI应用的新人，还是后端开发想快速上手大模型应用，这套流程照着走一遍，基本就能跑通自己的私有知识库问答。

1. 先把RAG的原理和工作机制搞清楚

1.1 为什么是RAG而不是微调

聊RAG之前，必须先把“为什么不用微调”这个问题讲清楚，因为这是我被问得最多的一句话。很多第一次接触私有知识库的人，天然觉得“要让模型懂我的数据，就得让模型学习我的数据”，这个思路本身没有错，但微调的成本和风险往往被低估了。

微调意味着你要准备一批高质量的训练数据，要对数据做标注和清洗，要花钱租GPU跑训练，训练完还得评估效果、防止灾难性遗忘。这一整套流程下来，轻则一周，重则一个月。更关键的是，你的业务文档是持续更新的——合同在签、制度在改、方案在迭代。每次文档一更新，你都要重新做一轮训练，这个节奏绝大多数业务团队都受不了。

RAG的思路则完全不同。它把知识库变成了一个“外挂数据库”，大模型本身不用动，我们要做的工作只是“把文档切成片段、存进向量库、用户提问时检索相关片段、把片段拼进提示词里”。文档更新了，直接替换向量库里的片段就行，全程不需要训练模型。用生活类比来解释，微调是让员工把公司手册背下来，RAG则是告诉员工“遇到问题时，先翻一下手册找到对应章节，再照着回答”。后者显然更灵活、更可控，也更省钱。

1.2 RAG的三段式工作流

RAG的完整流程可以拆成三个阶段，整个架构图其实就是一个标准的流水线：

第一阶段是“离线索引”。把私有文档加载进来，做格式解析和清洗，然后按照一定长度切分成块，对每一块做向量化，也就是把文本变成一串数字向量，最后把向量写入向量数据库。这个过程只需要做一次，除非文档更新。

第二阶段是“在线检索”。用户输入一个问题，系统先把问题也用同样的模型转成向量，然后在向量库里做相似度搜索，找出跟问题最相关的那些文档片段。这里的核心就是语义匹配——哪怕用户的提问跟文档里的文字不完全一样，只要意思相近，向量检索也能找到对应内容。

第三阶段是“增强生成”。把检索出来的片段按一定格式拼接进一个提示词模板，连同用户问题一起发给大模型。大模型的任务不再是“凭记忆回答”，而是“对着这几段材料做总结和归纳”。这样一来，答案的准确性和可追溯性就大大提升了。

三个阶段各管一摊，也各自有坑。离线索引的坑在切分不合理、向量模型选得差；在线检索的坑在召回不准、排名不靠谱；增强生成的坑在提示词写不好、模型乱发挥。理解了这些，后面的每一步才不会糊涂。

1.3 私有数据的安全边界

还有一个大家特别关心的问题：数据安全性。RAG一个非常突出的优势就是私有数据不需要离开你自己的环境。嵌入模型可以用本地部署的开源模型，向量数据库可以跑在内网服务器上，大模型既可以选本地的开源模型，也可以通过对内网网关封装好的API来访问。整个链路里，原始文档和切片都留在自己的系统内部，只是把文档的“向量摘要”拿来做了检索匹配，最后把检索结果和问题一起送给大模型处理。

当然，如果把RAG接到了云端的模型API，那检索到的文档内容还是会发送到模型服务商的服务器上。所以对有保密要求的业务，我的建议是优先用本地化部署的模型，至少也要先做好脱敏和权限管控再接入外部API。这个点放到后面实操部分会再提到。

2. 技术选型：小白第一版系统怎么搭最省心

2.1 基础技术栈的选择逻辑

RAG系统的技术栈说不上复杂，主要就是四块：文档解析与切分、嵌入模型、向量数据库、大模型。对于第一版系统，我建议遵循一个原则：能白嫖就白嫖、能少配就少配、能单机跑就不上集群。先跑通，再谈优化。

• 开发语言选Python。这个领域生态最成熟，LangChain、LlamaIndex这些框架对Python支持最好，社区教程也多。
• 文档加载和切分直接用框架自带的能力就行，后面细说。
• 嵌入模型这块，中文场景我首推开源模型，比如BGE系列和M3E系列，它们的中文语义效果比很多通用模型稳定，而且都有轻量版本，CPU也能跑。
• 向量数据库第一版强烈建议用Chroma，它有个巨大的优势：不需要单独部署服务，就是一个本地的嵌入式库，pip安装就能用。后续数据量上来再迁到Milvus或者PGVector都不难。
• 大模型是唯一一个比较灵活的环节。本地派可以用Ollama跑中小参数模型，比如Qwen系列，效果不错而且完全离线。还有一派走云端API，通过OpenAI兼容接口接入大厂模型，效果更强但数据会出境，看你自己所在环境的要求来定。

这套组合拳打下来，一台16G内存的普通开发机就能跑完整套流程，非常亲民。

2.2 框架选型：LangChain还是LlamaIndex

选框架的时候，很多新手会在LangChain和LlamaIndex之间纠结。我的看法是：入门阶段，LangChain更合适；如果你就是纯粹想做一个文档问答机器人，LlamaIndex也很香。两者不冲突。

LangChain像一把瑞士军刀，各种组件都齐全，从文档加载、文本切分、向量检索再到调用模型，每个环节都有对应的接口。网上资料极多，遇到问题搜一下基本都有解决方案。缺点是抽象层级多，版本更新快，API变动频繁，看老教程容易踩版本坑。

LlamaIndex的定位更聚焦，就是做“数据与模型的连接”，尤其是文档索引和检索这块做得非常出色。如果你想从底层理解RAG的每一步，直接读它的源码也是不错的选择。

我给小白用户的建议是：第一版直接用LangChain，因为参考资料最多、组件最全、出问题好排查。等系统跑通了，对RAG的理解也到位了，再回头看LlamaIndex也不迟。另外有一个很关键的建议：框架版本一定要锁定，不要装“最新版”，因为LangChain的小版本之间API差异很大，照着教程写代码经常报错，锁版本是最省心的做法。

2.3 数据量级决定架构复杂度

技术选型还得考虑一个现实问题：你到底有多少数据。这直接决定了你的系统复杂度。

如果你就几千个文档片段，总量在几十万到几百万字符之间，单机本地向量库完全够用，检索速度毫秒级。这时候上分布式架构纯属给自己添麻烦。

如果你到了百万级甚至千万级文档片段的规模，那需要考虑更重的方案。向量数据库建议换成Milvus或者专门的云服务，嵌入计算要用GPU加速，检索后面还要加一层重排序来保证精度。但这不是小白的阶段该操心的事，第一版系统先把单机流程跑通比什么都重要。

3. 实操全过程：从零搭建你的第一个RAG知识库

3.1 环境准备和依赖安装

我直接给你一份可以照着抄的环境清单。操作系统建议用Linux或者macOS，Windows也能跑，但有些包的安装会麻烦一点。

mkdir rag-demo cd rag-demo python -m venv venv source venv/bin/activate pip install langchain langchain-community langchain-openai chromadb pip install unstructured pypdf python-docx openpyxl

这里解释一下几个包的用途。langchain和langchain-community是主框架和各类集成组件，chromadb是向量库，pypdf和python-docx分别用来解析PDF和Word文档，unstructured负责处理一些杂七杂八的格式。嵌入模型和大模型我们等一下通过Ollama来接。

如果你打算用Ollama跑本地大模型，还需要安装Ollama并拉取需要的模型：

ollama pull qwen2.5:7b

这里的qwen2.5就是我们要用的生成模型，中文效果不错，7B参数规模在普通消费级显卡上也能跑得动。

3.2 官方文档的加载和清洗

所有RAG系统的第一步都是“加载文档”。这一步看着简单，实际上坑非常深。我用的是公司里一份产品手册的PDF，大概有四十多页，包含文字、图片和表格，拿来测试非常合适。

from langchain_community.document_loaders import PyPDFLoader loader = PyPDFLoader("product_manual.pdf") documents = loader.load() print(f"加载完成，共 {len(documents)} 页")

这里有个细节值得注意：PyPDFLoader默认是按页加载的，每个页面对应一个Document对象。如果PDF里有扫描件（本质是图片），PyPDFLoader是提取不出文字的，必须先用OCR工具把图片转成文字再加载。这个坑我实际踩过——第一次跑完发现索引了一大堆空内容，检索结果自然全是垃圾。所以处理扫描件之前，先用OCR转一遍是最稳妥的做法。

加载进来之后要做什么？清洗。PDF、Word文档里经常会混入页眉页脚、页码、奇怪的换行符，这些都需要做初步清理。LangChain提供了很多现成的文本清洗工具，但我觉得对小白来说，最简单高效的方式是自己写一个简单的过滤函数，处理掉明显的噪音数据：

def clean_text(doc): lines = doc.page_content.split("\n") cleaned = [] for line in lines: if line.strip().isdigit(): # 去掉只有页码的行 continue if "版权所有" in line or "www." in line: # 去掉固定页脚 continue cleaned.append(line.strip()) doc.page_content = "\n".join(cleaned) return doc documents = [clean_text(doc) for doc in documents]

别看这段代码简单，它对检索质量的提升是肉眼可见的。你想想，如果每次检索都把页眉页脚匹配进去，最相关的文档片段可能反而排不上号，答案自然就偏了。

3.3 文本切分：chunk_size不是随便填的

文档清洗完之后，就该切分了。这一步是RAG系统里最容易出错、也最影响效果的地方。切分逻辑的核心是两个参数：chunk_size（块大小）和chunk_overlap（块之间的重叠长度）。

from langchain.text_splitter import RecursiveCharacterTextSplitter text_splitter = RecursiveCharacterTextSplitter( chunk_size=500, chunk_overlap=80, separators=["\n\n", "\n", "。", "；", "，", " ", ""], length_function=len, ) chunks = text_splitter.split_documents(documents) print(f"切分完成，共 {len(chunks)} 个块")

为什么需要chunk_size和chunk_overlap这两个参数？我给你解释清楚。chunk_size决定了每一段送进向量库的文本长度，太短了语义不完整，太长了一遍又装不下；chunk_overlap则是为了保证切分边界处不会被“拦腰截断”，比如一句话被切成两半，那前后两段就会各自丢失一半的语义，而重叠可以让这种损失更小。

具体参数怎么定？我的经验是有一套快速判断逻辑：

• 如果文档是问答类内容，一问一答一通到底，chunk_size可以大胆设到1000，因为语义单元本身就是大段的。
• 如果文档是条款式的合同、制度，chunk_size设在300到500之间比较合适，条款本身短，切太大会把两三个不相关内容揉在一起。
• 如果文档是技术手册，叙述逻辑连贯，500到800是安全区间。
• chunk_overlap一般设为chunk_size的10%到20%，太小没效果，太大浪费存储。

切分完成后一定要抽样检查几个块，看看切出来的内容有没有把句子断得七零八落。这一步千万不要省，我至少见过五个新人栽在“切分完直接建索引”上，检索出来的内容前言不搭后语，根本没法看。

3.4 嵌入与入库：构建向量索引

切分完成之后，就是RAG的“灵魂”环节：把文本转化为向量，存入向量数据库。

嵌入模型的作用，是把一段文字映射成一个高维空间里的坐标点。在这个空间里，语义相近的文字坐标也相近。检索的本质，就是拿用户问题的坐标去这个空间里找最近的邻居。

本地部署首选的方式是调用Ollama提供的嵌入接口。以BGE系列模型为例（它在中文上的表现非常稳），流程如下：

from langchain_community.embeddings import OllamaEmbeddings embeddings = OllamaEmbeddings(model="bge-m3")

然后初始化Chroma向量库，把切好的文本块全部灌进去：

from langchain_community.vectorstores import Chroma vectorstore = Chroma.from_documents( documents=chunks, embedding=embeddings, persist_directory="./chroma_db", ) vectorstore.persist()

如果第一次接触向量库，你可能会好奇“向量化到底存了什么”。简单说，每一条文本块会被嵌入模型变成一个长度为1024维之类的数字数组，Chroma把数组和原始文本、以及一些元数据一起存起来。当你查询的时候，Chroma把问题向量化，然后做一次余弦相似度计算，把最接近的几段文本取出来。

这一步完成后，你的“知识库”就算建好了。整个过程可能只要几分钟，之后每次问答都会在这个库里做检索。

3.5 构建检索问答链：把一切串起来

知识库建好了，现在要做的是把“用户提问 -> 检索 -> 组装Prompt -> 大模型生成”这条链路打通。LangChain里最常规的做法是使用检索式问答链，但对于理解原理来说，我建议第一版就别怕麻烦，手写一个简单的流程，这样你才知道背后发生了什么。

from langchain_community.llms import Ollama llm = Ollama(model="qwen2.5:7b", temperature=0.1) def rag_answer(question, k=4): # 第一步：检索 docs = vectorstore.similarity_search_with_score(question, k=k) # 第二步：组装上下文 context = "\n\n".join([doc.page_content for doc, score in docs]) # 第三步：构造提示词 prompt = f"""你是一位知识库问答助手。请仅根据以下参考资料回答问题。 如果参考资料中没有相关信息，请直接回答“文档中未找到相关内容”，不要自行编造。 参考资料： {context} 用户问题：{question} """ # 第四步：调用大模型 response = llm.invoke(prompt) return response

这个函数虽然短，但它就是RAG应用的最小骨架。你仔细看第四步的提示词，里面有一句很关键的话“如果参考资料中没有相关信息，请直接回答文档中未找到相关内容，不要自行编造”。这句话是压制幻觉的第一道防线，很多人做出来的问答系统老是胡言乱语，就是没有把这条约束写清楚。

运行一次看一下效果：

answer = rag_answer("我们产品支持哪些文件格式的导入？") print(answer)

如果前面的流程都正常，你会在回答里看到文档里出现过的具体格式列表，而不是模型瞎编的结果。这时候，你的第一个RAG知识库就已经跑通了。

4. 调优进阶：从“能跑”到“好用”的三个关键手段

4.1 重排序：别让最相关的内容排后面

跑通第一版之后，你大概率会遇到一个尴尬场景：明明文档里有正确答案，但回答就是不对。这里面很大的问题出在“排序”上——向量检索按相似度打分召回了最相近的若干片段，但“相似”不等于“相关”。

举个例子。用户问“采购流程需要几个审批节点”，文档里有一段专门讲采购流程共需要四个审批节点，但同时还有另一段在讲项目立项也涉及采购相关审批。向量相似度可能会把后者排到前面，因为它的措辞跟问题重合度更高，但真正的答案却在后面。

解决这个问题的标准做法是加一层重排序，业界俗称rerank。思路是先用向量检索召回比较多的候选结果，比如20条，然后用一个专门的排序模型对候选结果和用户问题的相关性做二次打分，取最相关的4到6条送进最终提示词。这就像先海选再终审，前一轮保证“不漏”，后一轮保证“精准”。

开源的rerank模型，中文场景推荐bge-reranker系列。V2版本有一批比较成熟的实现，考虑到生态衔接，用LangChain内置的RAG重排序方案来接入，改动也很小。

4.2 混合检索：解决专有名词找不到的问题

向量检索有个天然的软肋：它对纯语义的理解很强，但对精确匹配很弱。比如你文档里写的是“CRUD”，用户提问写的是“增删改查”，向量检索能找到；但如果用户问的是某个产品编码“XK-2024-09”，这种纯字面量的信息，向量检索有时候反而不如传统的关键词匹配准。

这就是为什么我强烈建议你上混合检索。混合检索就是把向量检索与传统的关键词检索（比如BM25）的结果做合并，两种手段互补。

• 向量检索负责“语义相关”，能处理同义词、口语化表达。
• BM25负责“字面相关”，能精准匹配专有名词、代号、编码。

LangChain里做混合检索需要做一点配置。大致思路是：一个检索器走向量库，另一个检索器走BM25索引，然后把两个结果用某种融合算法合并起来，再做一次重排序。融合算法推荐用RRF，原理很简单，就是根据各条结果在两个检索器中的排名加分，排名越靠前分越高，最终按总分排序。这个方法实现简单，效果却非常稳。

4.3 动态改写：用户的问题太口语化怎么办

还有一个经常被忽略的问题：用户的问题往往跟文档的表达方式差得很远。比如文档里写“本系统支持多租户隔离”，用户可能上来就问“咱这平台能让多个部门分开用不”？如果直接拿用户这句话去检索，匹配效果就可能不理想。

一种很实用的方案是“查询改写”：先把用户问题发给大模型，让它把问题改写得更规范、更贴近文档的表达方式，再用改写后的文本去做检索。虽然多了一次模型调用，但检索效果常常有质的提升。还有一种方案是HyDE，思路是让模型先根据问题生成一个虚构的答案片段，然后用这个片段去检索。因为在向量空间里，答案与文档的语义距离往往比问题与文档更近。

这些技巧不一定都要上，根据你自己的场景选一两个就能看到明显效果。我的建议是优先加重排序，它的性价比最高，改动最小效果最直接。

5. 高频问题排查：把我踩过的坑一次讲完

5.1 检索出来了内容但回答完全错误

这个是最常见的问题，通常有四个原因，按排查优先级排列：

第一，检查切分质量。把召回的那几条文本块打印出来看看内容是不是完整的、可读的。如果文本块被切得支离破碎，后半段半句话、前半段半句话，那大模型当然没法正确回答。解决办法是调大chunk_overlap或者换用按标题结构切分的splitter。

第二，检查重排是否缺失。如果做了重排序还是不对，看是不是召回池太小，把候选数k从原来较小的值提到更大的范围再试。

第三，检查提示词。你给模型的指令是否足够清晰？一定要写明“仅根据参考资料回答”，并且要求模型在找不到答案时直接承认，而不是自行推理。

第四，检查嵌入模型本身。如果文档是垂直领域的技术文档，通用嵌入模型可能理解不了专业词汇，可以考虑换一个在领域数据上表现更好的嵌入模型。

5.2 幻觉问题：模型还是自己瞎编

幻觉是RAG系统绕不开的话题。即使你写了“不要编造”，模型还是有概率发挥。我的处理手段有三个：

一是提高检索质量，确保上下文里真的有答案。大部分幻觉的根源其实不是模型爱编，而是它搜到的内容里根本没有答案，被逼无奈只能硬编。这个思路看着简单，但很多人第一反应就是去调提示词，方向搞反了。

二是在Prompt里加入“引用来源”的约束。比如要求模型在回答末尾标注“本回答基于第X条参考资料”，这样既能让用户感知到答案来源，也能逼迫模型更谨慎地使用资料。

三是在系统层面做自知之明。如果检索到的内容与问题的相似度分数低于某个阈值，直接告诉用户“知识库中没有相关内容”，而不必强行生成。Chroma的similarity_search_with_score返回的相似度分数可以拿来当这个阈值依据。

5.3 中文加载乱码和格式解析失败

文档解析这一层问题也很多。PDF有时候看起来正常但复制出来全是乱码，这种情况多半是字体编码问题，可以用OCR工具重新识别。Word文档有时候跑在Linux服务器上解析失败，是因为缺少对应转换依赖，可以换用纯Python的实现版本。

我的建议是：生产环境中尽量把文档统一转成纯文本或者Markdown格式再做加载，减少解析链路的不确定性。你自己开发时可以直接用PDF和Word测试，但上线前最好加一道格式标准化流程。

5.4 检索速度慢：数据量上来之后怎么办

本地向量库Chroma在小数据量下毫秒级返回，但当数据量涨到几十万条，性能就会明显下降。这时候有两件可以做的事。

第一，把向量库从Chroma迁移到服务化部署的Milvus等方案，迁移本身不难，LangChain做了统一接口。第二，给检索加一层过滤条件。如果你有几百个文档分类，可以先通过元数据过滤缩小范围，再做向量检索，速度会快很多。比如只会检索用户选定的某个产品线下的文档，而不是全库扫描。

写在最后

我个人把整套流程完整跑下来之后最大的一个体会是：RAG项目80%的精力其实是花在数据准备和检索调优上，真正跟大模型打交道的时间反而很少。很多人的第一版系统“能跑但不好用”，问题几乎都出在文本切分太粗糙、检索质量太差这些细节上，而不是模型不够聪明。

最后再分享一个我的工作习惯：每做一个知识库项目，我都会先拿一个五十页以内的、自己非常熟悉内容的文档做原型验证，先把切分、检索、回答的全链路调到满意，再批量导入生产数据。一次只改一个变量、保留每一次的实验记录，用不了多久，你就能建立起对参数和算法的直觉。希望这篇长文能帮你少走一些弯路，尤其是那些我刚入坑时完全没人提醒过的细节，这篇文章里能交代的基本都交代到了。