企业官网建设流程全解析

说到AI应用开发，这两年绕不开的一个词就是RAG。我最早接触RAG是在做一个企业内部知识库问答系统的时候，当时LLM回答里频繁出现一本正经的胡说八道，客户体验非常糟糕。后来切到检索引擎增强生成的方案，知识库问答的效果才算是真正落地。可以说，RAG（Retrieval-Augmented Generation，检索增强生成）已经成为大模型落地到具体业务场景里最实用的一套技术范式。这篇文章我结合自己实际踩过的坑，从架构原理、实操搭建、性能瓶颈到进阶方向，把RAG这条链路完整拆一遍。

1. 从大模型"幻觉"说起：RAG为何成了AI应用的标配底座

1.1 大模型幻觉问题，正是RAG诞生的直接原因

先聊一个所有做AI应用开发的人都躲不开的问题：幻觉。大模型本质上是一个token预测器，它的训练目标是最大化下一词的概率，而不是确保输出内容符合事实。当它遇到训练数据里没见过或覆盖不足的知识时，就会用"语义上最合理"的方式补全答案，这个补全过程产出的内容就是幻觉。

我见过很多人试图靠调prompt、换更大的模型去解决幻觉，实测下来效果非常有限。因为模型无法区分"它知道什么"和"它以为自己知道什么"，只要知识不在参数量里，再强的推理能力也补不出正确事实。RAG的思路恰恰绕开了这个死结：不指望把知识"记在"模型参数里，而是在用户提问时先从外部知识库检索相关内容，把检索到的文本片段作为上下文拼接到prompt中，让模型基于这些证据来生成答案。

这种"先检索、后生成"的架构让大模型输出有了外部事实兜底，问答的准确性提升会非常明显。对比LLM直接生成，带RAG的问答系统在事实类问题上的准确率普遍能提升20%到40%，更关键的是回答可以追溯到知识来源，用户对结果的信赖感完全不同。

1.2 RAG与微调的取舍：什么时候真的需要RAG

很多刚接触大模型应用的人会纠结一个问题：知识库更新到底是应该做RAG还是做微调（Fine-tuning）。我的判断标准很简单——看你的诉求是"会做事"还是"会答题"。

微调改变的是模型的行为模式和技能，比如你想让模型学会某种固定的输出格式、模仿某种文风、或者具备某个垂直领域的基础分析框架，这时候微调是合适的。但如果你只是给模型补充一些不断更新的业务文档、产品说明、FAQ资料，那就属于"会答题"，更适合用RAG。原因有三个：

• RAG不需要GPU训练资源，只需要普通的推理机器和一个向量数据库，成本低一个数量级。
• RAG的知识更新是即时的，替换索引文件就行，微调动辄需要重新训练和验证。
• RAG带引用了，回答错了能回溯问题出在哪，微调模型一旦错了很难解释原因。

实际生产中我经常用的是组合方案：用RAG解决动态知识的检索与回答，用微调解决固定风格的输出表达，两者并不冲突。建议初学RAG的朋友先把检索链路做透，再考虑和微调做叠加。

2. RAG核心链路拆解：离线索引与在线检索的前世今生

2.1 离线索引：从文档加载到向量入库

RAG的完整链路可以清晰地分为离线和在线两个阶段。离线阶段的核心目标只有一个：把原始文档变成计算机可以快速召回的结构化索引。这里的索引不单指向量索引，还包括内容分块、元数据标注和索引结构设计。

第一步是文档加载。不同格式的文档有不同的解析方案，PDF类复杂版式文档建议使用PyMuPDF、PDFPlumber这类工具按页面提取文本；Word、Markdown这类带层级结构的文档建议保留标题层级信息；网页类的则用Trafilatura或BeautifulSoup清洗噪声。这个环节最容易被忽视，但也最影响效果——垃圾进垃圾出，文本提取得稀烂，后面切块、向量化全都跟着白费。

第二步是文档切分。LLM的上下文窗口是有限的，即使现在百万字上下文的模型已经出现，把整篇文档全塞进prompt无论在成本还是检索复杂度上都不可接受。切分的目标是把长文档切成语义完整但长度适中、便于检索的chunk。切分策略直接决定了召回粒度的粗细。

这里我分享一个踩过不少坑后的经验总结：

一个值得反复调整的切分参数是chunk_size（块长度）和overlap（重叠长度）。chunk_size越大，每个块包含的上下文信息越完整，但向量表示的语义就被稀释了；chunk_size越小，检索粒度越细，但容易丢失上下文。中文场景下，我常用的经验值是400到800个字符左右，overlap在50到200之间，这个数值和嵌入模型、文档类型都有关，需要小规模测试才能找到最佳点。

2.2 在线检索：从查询改写到底座生成

在线阶段是面对用户请求时的运行链路，一般分为查询改写、向量召回、重排序、上下文组装和LLM生成这几个步骤。

查询改写是我最开始做RAG时忽略掉、后来却发现提效极强的一环。用户实际问的问题往往是口语化的、指代模糊的，比如用户在知识库场景里输入"这个功能怎么不支持了"，系统如果直接用这句话去做向量检索，召回结果大概率不理想。我的做法是用一个小的LLM把用户问句改写成"更适合检索的表达"，比如提取核心实体、补全上下文指代、去口语化等等。这个改写后的查询再去和文档块做相似度匹配，效果会好很多。尤其是在多轮对话场景中，查询改写基本是必需品，否则对话历史里的指代关系无法被正确利用。

向量召回后的重排序（rerank）同样是决定RAG效果的关键一环。向量检索擅长捕捉语义相近的内容，但在精排上往往不够灵敏。很多RAG项目初版直接拿向量检索Top-K的结果拼进prompt，经常发现答案不如预期。我一般会先在向量召回阶段取得100个候选块，再用rerank模型（比如bge-reranker、Cohere Rerank这类模型）在这100个候选里找出最相关的3到5个块作为上下文。这么做虽然多了一步推理耗时，但对回答质量的提升非常显著，几乎立竿见影。

到了LLM生成阶段，需要做的是把检索到的文本片段组织成结构化的prompt，明确告诉模型知识来源有哪些、哪些信息是知识库原文、哪些是模型自身推理。我在这个环节还会额外加一层"禁止编造"约束——当知识库内容不足以回答问题的时候，模型必须如实承认"知识库里没有相关内容"，而不是硬凑答案。

2.3 向量数据库选型：Chroma、Qdrant还是Milvus

向量数据库是RAG业务中承担稠密向量存储和检索的组件。目前市面上的选项不少，我做过的几个项目里用过的包括Milvus、Qdrant和Chroma，简要对比一下：

对零基础或小规模项目来说，我建议先从Chroma或FAISS入手，把RAG链路本身的调通和调优做好，等数据量上来之后再迁移到Qdrant或Milvus上。向量数据库迁移本身成本不高，但链路和效果调优的成本才是大头，别在选型阶段过度工程化。

3. 零基础搭建本地RAG项目的完整实操

3.1 环境准备与模型选型

接下来这部分我们来做一个零基础可复制的本地RAG项目。这一类项目在网上有个很典型的组合：Ollama加一个本地嵌入模型和一个本地LLM，再加上一个向量数据库和几十行Python代码，就能跑通一个能用的知识库问答系统。

先说说为什么推荐Ollama。Ollama的本质是一个本地大模型运行工具，它把模型下载、量化、加载、推理接口封装成了一个命令行工具，极大地降低了本地跑模型的门槛。在写这篇文章的当下，Ollama已经支持了大量主流开源模型，包括Qwen系列、Llama系列、DeepSeek等等，而且提供兼容OpenAI的API接口，上层代码可以无缝切换。

本地RAG项目的模型选择要分成两个维度来看。嵌入模型负责把文本转成向量，我推荐bge-m3或者bge-large-zh，在中文语义上效果稳定，Ollama也直接支持；生成模型负责最终回答，我建议按你的显存规模来选，8GB显存跑Qwen2.5-7B的量化版本比较稳妥，16GB以上可以尝试更大的模型。别一味追求大模型，RAG场景下生成模型的主要任务是"依据给出的材料进行总结"，对参数量的要求并不像长文写作那样高。

3.2 文档切分：那些我踩过的chunk_size坑

说一个我早期亲历的典型案例。当时我在做一个法律条文的知识库问答，用的是固定长度切分，chunk_size设为500，overlap设为0。测试时发现，凡是涉及"上述条款""自本规定施行之日起"这类表述的问答，系统回答的正确率低得可怜。追查根源，原来是切块把多个条款切成碎片，每个chunk只能表达局部的、不完整的信息，下游检索召回时，真正能支撑答案的证据块反而排到了很后面。

后来我把切分策略改成了按条文编号分段，并在切分前把法律条文里的指代关系做了初步合并，效果立刻上了一个台阶。这个案例给到我的教训是：先理解你的文档结构，再决定切分策略。对于有明确章节结构的文档（法律条文、技术文档、规章制度），优先按结构切；只有对无结构的长文本才使用固定长度切分。

另一个我经常看到新手踩的坑是overlap设得太小甚至为0。overlap的存在是为了防止两个相邻chunk在切点处切断语义连续的句子。比如一个句子被硬生生切成了前后两半，前半截在chunk A的结尾，后半截在chunk B的开头，检索时这两个chunk都无法完整表达该句的意思，信息就丢了。我建议在固定长度切分方式下至少设置50到200字的overlap，具体数值根据你的chunk_size按比例来，大约10%到20%之间，既不会显著增加存储量，又能保住边界语义。

3.3 一个极简RAG的核心代码骨架

完整的本地RAG项目涉及到的代码并不复杂，我们可以用一个核心代码骨架来覆盖主要流程。整个流程分三步：先把文档加载并切分为chunk并向量化入库，然后接受用户查询并检索出Top-K相关块，最后将检索结果组装成prompt调用LLM完成生成。

第一步的文档处理与入库，核心代码大致是这样的逻辑：

from langchain_community.document_loaders import PyPDFLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.embeddings import OllamaEmbeddings from langchain_community.vectorstores import Chroma loader = PyPDFLoader("./knowledge_base/sample.pdf") docs = loader.load() splitter = RecursiveCharacterTextSplitter( chunk_size=600, chunk_overlap=100, separators=["\n\n", "\n", "。", "；", "，", " ", ""] ) chunks = splitter.split_documents(docs)

第二步是向量化与存储。这一步选择合适的嵌入模型之后，将chunk转换成向量并写入Chroma。这里建议给每个chunk附带一个doc_id、source等元数据，后续追踪答案来源会很方便。

embeddings = OllamaEmbeddings(model="bge-m3") vectorstore = Chroma.from_documents( documents=chunks, embedding=embeddings, persist_directory="./chroma_db" )

第三步是检索并在prompt中组装上下文。这里我用一个简化版本的查询，实际生产中还需要做查询改写和rerank，但核心骨架就是这三个环节。

定义一个检索函数，将用户问题转成向量后在Chroma中进行相似度检索，取回TopK个块作为上下文材料。

def retrieve_context(query, top_k=5): results = vectorstore.similarity_search_with_score(query, k=top_k) context = "\n\n".join([doc.page_content for doc, _score in results]) sources = [doc.metadata.get("source", "") for doc, _score in results] return context, sources

定义生成函数，将上下文通过prompt模板拼接之后，调用Ollama的生成接口得到最终答案。

from ollama import chat def generate_answer(query, context): prompt = f"""请基于以下知识库内容回答用户问题。 知识库内容： {context} 用户问题：{query} 要求： 1. 优先引用知识库原文作答； 2. 如果知识库内容不足以回答问题，请如实说明； 3. 不要编造知识库中不存在的信息。""" response = chat(model="qwen2.5:7b", messages=[{"role": "user", "content": prompt}]) return response["message"]["content"]

这套极简骨架跑通之后，整个RAG链路的主干就已经建立起来了。接下来的优化工作，本质上都是在这几个环节里做深挖，就是我们下一节要聊的重点。

4. 为什么你的RAG总让人不满意：六大瓶颈与实战解法

4.1 召回不全与不准：混合检索 + 重排是急救方案

RAG项目上线之后，绝大多数让人不满意的场景根源出在召回环节。召回不全，意味着知识库里明明有答案，检索却没能把相关文档块找出来；召回不准，意味着相关文档块召回了，但排在很后面，被截断了，没进到最终上下文。

我处理这类问题的第一思路是加关键词检索。纯向量检索对专有名词、精确代码、编号、缩写这类文本的召回能力常常弱于传统的关键词匹配，因为向量表示会丢精确字符信息。在实际项目中，我会用Elasticsearch或者Meilisearch这类搜索引擎做BM25关键词检索，再把关键词检索的结果和向量检索的结果做加权融合，这种方法称为混合检索。权重调整需要根据具体业务实验，一般初始值可以设为BM25权重0.3、向量权重0.7，后续再按测试集表现调优。

混合检索解决的是召回不全面的问题，而召回不准则需要重排序来修正。向量检索和BM25这两类召回方式本身都带有大量噪声，直接拼接进prompt会导致信息冗余，甚至干扰模型的判断。我在召回阶段宁可多召一些（比如Top100），然后交给rerank模型精排到Top3到Top5，效果比直接召回Top5还要好。重排序模型大多数基于cross-encoder，将查询和候选文本拼接后计算相关性得分，虽然推理速度慢，但它能捕捉细粒度的匹配关系，值得出现在生产级RAG中。

4.2 结构化知识怎么办：表格数据与半结构化文档的处理

很多知识库项目在实际推进中才会发现，业务文档里大量内容是以表格形式呈现的。比如产品参数对照表、价格清单、财务报表、技术规格表。这些内容如果直接作为纯文本抽取并切块，表格的结构关系就全部丢失了。模型很可能把"型号A的价格"和"型号B的价格"两列内容混在一起，因为切块之后它们同时出现在一段文本中且没有任何结构约束。

针对表格数据的处理，我常用的策略有两种。一种是把表格转成自然语言描述，例如把"型号|价格|库存"的三列数据转成"型号X的价格为Y元，库存状态为Z"，这样将表格结构化信息转化为语义清晰的句子，再进行切块和向量化。另一种方案是走专门的表格解析链路，让模型按行理解表格内容，给每行生成一段自然语言摘要，再对摘要做检索。实测下来，这两种方案在问答准确率上各有优势，其中方案二对复杂表格的理解能力更强，但需要额外消耗模型推理成本。

4.3 图片能进知识库吗？聊一聊多模态RAG的边界

这是我在做知识库时被问得很频繁的一个问题。先说结论：RAG知识库能不能存图片，取决于你用的是哪种方案。

如果只是把图片作为文档的附件存在知识库里、不参与向量检索，那当然可以，但这没有实际意义，因为模型无法"看图"回答问题。真正的多模态RAG要让图片参与问答推理，至少需要具备图像理解能力。目前主流方案有两类：一类是在离线阶段使用视觉语言模型（比如Qwen-VL这类模型）对图片进行解析，生成文字描述后入库索引，查询时用文本检索召回描述文本，最终让LLM根据描述作答；另一类是走视觉编码器方案，将图片直接编码为视觉向量参与向量检索，再由多模模型生成回答。

从工程落地的角度，我建议优先选择第一类"图片转文字描述"的方案。它的实现成本低、便于调试，也能兼容已有的文本RAG链路。第二类看起来更"原生态"，但检索阶段的视觉向量和文本向量如何对齐、生成阶段如何组织视觉上下文，这些问题在实践中都有更多坑要填。另外还要考虑图片描述的质量问题——如果描述本身不够准确，那后面的问答必然受影响。所以我的建议是把图片转文字这个环节作为AI离线批处理任务来做，加上人工抽检质量控制，比在链路中实时推理更稳。

4.4 多轮对话中的上下文纠缠问题

在问答型AI应用中，多轮对话几乎是必然需求。但多轮场景下RAG有一个很特殊的坑：用户的当前提问通常依赖上文语境，如果不做特殊处理，直接把当前句子拿去检索，效果会很差。比如用户在前面问"这个模块支持并发吗"，接着追问"那它支持多少并发"，只拿"那它支持多少并发"去做向量检索，很难召回正确的文档。

解决的思路不外乎两种。第一种是我在上面提到的查询改写，在每轮检索之前让LLM结合对话历史把当前问题改写成一个完整独立的查询语句。第二种是上下文压缩，把对话历史做摘要，只保留与当前问题相关的关键信息，降低噪声。实测中，查询改写方案效果更直接。需要留意的是，每轮都调用一次LLM做改写会引入额外延迟，在并发较高的场景下需要考虑性能开销，可以采用一些轻量模型做改写并将结果缓存。

5. RAG的下一步：从单纯检索到GraphRAG与Agent融合

5.1 当RAG遇上知识图谱：ontology RAG能解决什么

传统RAG的检索单位是文本片段，对于需要多跳推理的问题，它往往力不从心。举个例子，用户问"A公司的供应商中有哪些通过了B认证"，这个问题需要同时关联两个知识实体，跨越多个文档块才能得出答案。传统RAG要么把每个块都拉进来导致上下文爆炸，要么漏掉关键信息导致回答错误。

这时就轮到GraphRAG和ontology RAG登场了。GraphRAG的核心思路是：将知识库中的实体、关系、属性抽取出来，构造成知识图谱，检索时在知识图谱上进行图遍历或多跳查询，获取相关的子图结构，再将子图结构转化为文本提供给LLM。ontology RAG在此基础上更进一步，预先定义领域的概念体系、属性和关系类型，让抽取过程更规范、更可控。

我在自己项目中实验过这类方案的体会是：对于强实体关系的领域（如组织架构、供应链、产业链分析），GraphRAG的效果提升是肉眼可见的；但对于普通的散文型文档，构建知识图谱的成本收益比就不划算了。所以我不建议所有RAG项目都盲目上GraphRAG，可以先评估你的业务问题中有多少属于多跳关系型问答，有实际需求再引入图谱技术。

5.2 RAG智能体化：把检索变成Agent的工具能力

另一个方向是将RAG和Agent进行融合。在这种架构里，RAG不再是被动地"每次用户提问都强制检索"，而是作为Agent的一个工具来按需调用。

这个转变带来的好处很明显。复杂任务往往需要规划——Agent决定第一步先查什么、第二步再访什么，中间可能需要多次检索，每次检索的结果都会被纳入接下来的推理过程中。RAG智能体化之后，检索的时机、次数、目标都由Agent根据任务动态决定，比如用户问"对比一下我们产品和其他两款产品的差异"，Agent可以先检索自家产品文档，再检索另外两款产品的公开资料，分别组织信息，最后综合输出。

从工程实现的角度，目前主流的实现框架包括LangChain的create_react_agent、LlamaIndex的AgentRunner、以及扣子（Coze）这类平台上的智能体方案。如果你是想快速验证效果，可以在扣子上配置入参出参；如果你希望深度控制逻辑，直接用LangChain/LlamaIndex写自定义Agent更灵活。RAG智能体化是目前我个人比较看好的演进方向，因为它让系统从"检索-回答"的单向漏斗变成"规划-检索-思考-再规划"的闭环。

5.3 效果度量与迭代：RAG评估的落地指标

最后聊一个很多团队到了中后期才会重视的话题：怎么衡量RAG系统的效果？没有度量就没有优化，这是我做AI应用开发的一个铁律。

RAG评估可以拆分到三个单独的环节。检索评估主要看召回率和命中率——正确的答案是否出现在被召回的候选集合中；生成评估则关注回答的忠实度、相关性和完整性，其中忠实度是最关键的，即模型的回答是否严格基于检索到的证据而没有幻觉；此外还需要在端到端层面评估最终答案的质量。

我在实践中发现，做RAG评估最有效的手段是建设一个领域评测集。从你的业务文档中挑出50到200个真实问题，标注标准答案和对应的文档片段来源，然后把这个评测集作为回归测试集。每次改动切分策略、嵌入模型、检索参数或prompt之后，都在这套评测集上跑一遍，比较分数变化。这套做法虽然初期需要投入人力，但对后续优化效率的提升是决定性的。没有评测集的情况下做RAG调优，就像没有仪表盘开车，只能凭感觉，效率低且容易走偏。

这里分享一个评估Prompt编写的个人经验：如果你公司有测试资源，可以把评测的prompt交给大模型自动打分，再人工抽检30%的评分，能大幅降低人工标注成本。我亲测有效的常见维度就三个——相关性（是否答非所问）、忠实度（是否忠于知识库原文）、完整性（是否覆盖了问题所有要点）。评价标准设计得越具体，自动评分的质量越稳定。

做RAG不是跑通Demo就算完事，真正的挑战在于把检索质量、切分策略、模型选型、评估机制这四个轮子都装好，然后持续迭代。希望这篇内容能帮你少走一些我走过的弯路，想清楚你自己的业务场景要解决的问题再动手。