企业官网建设流程全解析

很多兄弟私信问我：刚入门大模型开发，到底该先学什么？我的答案一直很明确——先玩透RAG（Retrieval Augmented Generation，检索增强生成）。你自己从头微调一个大模型，没有几块像样的显卡根本跑不动，但RAG不一样，它直接在现有大模型的基础上，把你自己的知识库“喂”给它，让模型回答问题时能“翻书查资料”，而不是凭空瞎编。这篇攻略，我把自己从零搭建RAG系统到逐步升级为高级RAG的全过程、踩过的坑和优化思路都整理出来了，全是实操过的干货，收藏就对了。

1. 内容整体设计与思路拆解

1.1 为什么说RAG是当前大模型落地的最优选

先画个重点：RAG的本质，是在大模型的外部挂一个“外挂知识库”。当用户提问时，系统先从知识库里检索出相关片段，再把这些片段和用户的原始问题一起发送给大模型，由大模型基于这些检索到的内容组织答案。

这个思路之所以能在短时间内横扫整个行业，原因非常现实：

• 成本可控：不用去训练或微调模型，只需要维护一个数据库和检索逻辑，算力开销小得多。
• 实时性好：知识库里的内容随时可以更新，今天获得的内部培训资料，明天就能被检索到并出现在回答里，不存在大模型知识滞后的问题。
• 可信度高：因为回答是“有人在材料支撑”的，可以附上引用来源。用户看到答案时能看到出处，对结果的信任感完全不同。
• 幻觉抑制：虽然不能百分之百消除大模型的“一本正经胡说八道”，但有了检索文档作为上下文，模型胡编的概率会骤降。

早期“初级RAG”的做法非常简单粗暴：把文档直接切成固定大小的小块，全部切完，装上embedding模型向量化，丢进向量数据库，然后每次查询时去库里取最相似的那几个块，扔给大模型让它归纳总结。

这一套流程跑通之后，你会发现效果“能用，但是狼狈”——用户在知识库里问得很散，你切出来的块可能把两句本应在上下文里关联的话硬生生隔开，检索结果总是不那么对味。所以后面我全部精力投入做“高级RAG”，核心思路就是在原有最简流程上，从索引前、检索中、生成后每个环节做深度优化。

1.2 高级RAG的分层优化策略

高级RAG不是某一个单独的技巧，而是一整套围绕“索引构建、检索召回、结果重排、生成增强”四大环节的系统工程。

• 索引层优化：从最初“整篇丢进去切块”，升级为根据文档结构（标题、段落、表格）智能切块，并对文档做数据清洗与增强。
• 检索层优化：从单路向量检索，升级为“向量检索+关键词检索”的混合检索，解决向量检索对专有名词、编号不敏感的问题。
• 重排优化：把TopK从20扩到50，先广召回，再通过Rerank模型精排，把真正有用的片段挤到最前面。
• 生成层优化：不再只丢原文片段，而是做“压缩+改写+提示词约束”，让大模型掌握最核心的采分点。

这个思路其实和我们平时做产品迭代很像——先跑通基线，再做精准优化，千万别一开始就憋大招。下一节我先把高级RAG的各个核心环节拆开，一个一个地讲清楚。

2. 核心细节解析与实操要点

2.1 数据清洗与文档解析：决定RAG上限的地基

很多新手把注意力全放在向量数据库和调大模型接口上，结果最后检索效果稀烂，折腾了很久才发现问题出在最前面的数据上。知识库里的文档如果是PDF，直接拿文本提取工具提出来，你会发现里面充满了页眉页脚、乱码字符、莫名其妙的分页符，还有把表格彻底读歪掉的情况。

有一个特别普遍的坑，就是PDF里明明有表，结果解析出来变成了一堆散开的数字。这种情况如果不特殊处理，后面检索时会把表格内容完全打散，关键数据可能就找不到了。

实操建议：

1. PDF解析优先用专业工具，比如一些具有OCR能力的解析库或在线API，而不是贪图方便直接用最简单的文本抽取。带扫描件的PDF必须开OCR才能保证正确率。
2. 解析完成后做一层“清洗管线”：去掉页眉页脚、自动去除多余空行、替换全角半角字符。
3. 如果文档里有大量表格，提取出来后转换成Markdown格式的表格，保留结构关系。曾经我处理一份设备参数手册时，正是靠表格转Markdown，让设备型号和参数重新能对得上，检索准确率直接提升了一截。

数据清洗这一步求稳不求快，你的RAG天花板就在这里。

2.2 分块策略的选型：定死了检索的下限

分块大小和重叠长度，是整个RAG最容易被忽略但影响最大的两个参数。

早期我喜欢一股脑用固定大小分块，比如每块512个token、重叠128个token，简单省事，但效果全凭运气。不同文档类型对分块的要求差别非常大：

• 技术文档：章节逻辑明确，应该按照Markdown的标题层级去切，保证每一块内主题连贯。
• 问答对手册：只需要按一个问题一个回答来切，甚至可以人为把“问”和“答”拼接在一块里。
• 长文档小说类：需要切得适度大块，保证上下文信息相对完整，避免主角名和指代关系散落好几处。

我给一个新手的参考配置：

• 通用文本：块大小500~800个token，重叠10%~20%。
• 技术文档：优先按标题结构切块，若没有标题结构再落到固定大小，可用一些切分工具的递归字符切分。
• 代码仓库文档：必须按代码块边界和函数定义切，否则代码被切断之后就废了。

一个核心心得：分块时要“带上下文裁剪”。什么意思？假设你要切500个token，不要从这里正好500个截断，而是再多取后文的开头一小段拼接进来，甚至可以带上该章节原始标题。比如原始文本是“第三章 启动步骤”，那你的每一块前面都拼一个“第三章 启动步骤：”这样的标题前缀，这样embedding嵌入的语义就天然带上了块级上下文。

2.3 Embedding模型选型与微调

Embedding是整个RAG系统中的“翻译官”：把文本转成向量，能不能检索得准，一半要看Embedding模型对领域文本的敏感度。

坦白说，通用Embedding模型在新领域里确实会有力不从心的情况。比如你现在做的项目是某个垂直行业（如医疗、法律、金融），通用模型能理解“苹果”是水果还是公司，但一旦遇到“对乙酰氨基酚”、“第三人撤销之诉”这种领域术语，检索效果就很飘。

关于Embedding的实操要点：

1. 基础选择原则：中文任务首选针对中文优化的模型，英文或代码场景选各自领域强项的模型，不要盲目追求大参数，有些轻量模型在特定垂直领域远超通用大模型的效果。
2. 测试集验证：上线前至少准备100对“问题-答案片段”，用来做召回测评，计算命中率。我见过很多团队号称检索准确率90%，其实只测了十条数据，十条里还大部分是简单匹配，这完全不具备参考意义。
3. 微调时机：如果通用Embedding在验证集上的命中率不到80%，就要考虑用领域语料做无监督对比学习预训练，或者做有监督微调。

这些内容展开就是一篇大文章，作为新手阶段，先把通用模型用好，用测试集把效果量化出来，比一上来就微调Embedding模型更实际。

2.4 向量数据库选型对比

市面上向量数据库很多，选型原则同样是分场景：

我给小白的建议很简单：先用轻量方案把流程跑通，理解“建库-编码-检索-入库”的完整链路，不要贪图一步到位。如果项目一开始就确定了最终规模会很大，那就直接从开源分布式方案起步，避免后期迁移数据。

2.5 混合检索与重排序：高级RAG效果的两大发动机

想要“高级”，这一步绕不开。

混合检索为什么重要？因为向量检索擅长找“语义相似”，但不懂精确匹配。比如你要找“CVE-2024-12345”，向量检索很可能把它当成普通字符串打散成好几个向量，结果相关性排序不如人意。而关键词检索（BM25）对这种专有名词、编号、精确术语非常敏感。两者结合之后：

• 向量检索召回“意思相近”的段落；
• 关键词检索召回“词面匹配”的段落；
• RRF（Reciprocal Rank Fusion）融合算法将两路结果合并排序。

实操中我会把向量检索和关键词检索各查50条，融合后重排，输出Top20进入精排。这么做的好处是“虽然第一次排序比较粗，但至少不会漏掉真正有用的段落”。

重排序则是更进一步：用专门的Rerank模型，将融合后的候选段落与原始问题做一次深度交叉编码，输出更精准的相关性分数。Rerank模型和Embedding模型最大的区别在于，Embedding建索引时一次算好所有向量，Rerank是每次查询时动态计算的，精度更高但计算成本也高。所以正确用法是先粗召回一大堆，再用Rerank精排。

我测过的项目里，单路向量检索的命中率大约在70%，加上混合检索可以到82%，再叠加Rerank后能到93%以上。而整体延迟只增加了200毫秒左右，完全在可接受范围。

3. 实操过程与核心环节实现

3.1 搭建一套最小可运行的高级RAG方案

纸上谈兵没意思，我带你们完整过一遍代码级的实现。下面这套基于主流开源库的搭建步骤，我自己在模拟项目X中反复用过。

3.1.1 环境准备与依赖安装

# 建议在虚拟环境中操作并锁定Python 3.10+ pip install langchain langchain-community langchain-openai pip install chromadb pip install bm25s pip install sentence-transformers pip install ranker # 这里用Rerank工具的通用别名代替具体包名，按自己项目对应

这里有个小提醒：安装LangChain相关包时，它依赖的小库很多，经常出现某个包升级后接口不兼容的问题。一个稳妥的做法是官方文档里推荐的组合版本，不要自己从网上零散抄安装命令。我曾经因为顺手升级了某个依赖库，结果全套接口崩了一遍，排查了很久。

3.1.2 文档加载与清洗

from langchain_community.document_loaders import PyPDFLoader from langchain_community.document_loaders import DirectoryLoader # 加载某个目录下的所有PDF loader = DirectoryLoader("./knowledge_base", glob="**/*.pdf", loader_cls=PyPDFLoader) docs = loader.load()

加载完成后，别急着切分，先做清洗：

import re def clean_text(text: str) -> str: # 去除页眉页脚（模拟规则：匹配包含"第X页"的整行） text = re.sub(r".*第\s*\d+\s*页.*", "", text) # 去除多余空白行 text = re.sub(r"\n{3,}", "\n\n", text) return text.strip() cleaned_docs = [] for doc in docs: doc.page_content = clean_text(doc.page_content) cleaned_docs.append(doc)

清洗时的一个经验：不要做过度处理，那些看上去“没用”的版本号、编号可能正是关键词检索时最有用的锚点。

3.1.3 分块（按结构切分优先）

from langchain_text_splitters import RecursiveCharacterTextSplitter, MarkdownHeaderTextSplitter # 方案A：如果文档带有Markdown结构 headers_to_split_on = [ ("#", "H1"), ("##", "H2"), ("###", "H3"), ] markdown_splitter = MarkdownHeaderTextSplitter(headers_to_split_on=headers_to_split_on) # 方案B：无结构文档的递归切分 text_splitter = RecursiveCharacterTextSplitter( chunk_size=600, chunk_overlap=100, separators=["\n\n", "\n", "。", "！", "？", "；", "，", " ", ""], length_function=len, ) chunks = text_splitter.split_documents(cleaned_docs)

为什么separators里要放入中文标点？因为如果按英文字符切分，一个句子内刚好到词边界，语义还算完整，但你用英文习惯切分中文文档，很容易把一句话从中间断开。放进。！？；，这些中文断句符，切出来的碎片在语义上会保全很多。

3.1.4 Embedding与入库

from sentence_transformers import SentenceTransformer from chromadb import PersistentClient embedder = SentenceTransformer("BAAI/bge-large-zh-v1.5") client = PersistentClient(path="./chroma_data") collection = client.get_or_create_collection("my_kb") doc_ids = [] vectors = [] metadatas = [] texts = [] for idx, chunk in enumerate(chunks): vec = embedder.encode(chunk.page_content).tolist() doc_ids.append(str(idx)) vectors.append(vec) metadatas.append({"source": str(chunk.metadata)}) texts.append(chunk.page_content) collection.add( ids=doc_ids, embeddings=vectors, documents=texts, metadatas=metadatas, )

Embedding模型选择上，如果你手头文档以短文本或对话为主，可以选轻量模型；如果是长文本检索，选支持长文本且表现均衡的模型。编码的时候统一走一个模型就好，不要查询时用一个、建库时用另一个，否则相似度对比一开始就失真了。

3.1.5 查询链路：向量召回 + 关键词召回 + 融合 + Rerank

from ranker import Reranker # 示意性写法，实际按具体库调用 query = "公司出差报销标准是多少？" # 1. 向量召回 Top50 query_vec = embedder.encode(query).tolist() vec_results = collection.query(query_embeddings=[query_vec], n_results=50) # 2. 关键词召回 Top50（用bm25的索引处理同一批chunks） bm25_results = bm25_index.search(query, top_k=50) # 3. RRF融合 # 对两路结果按排名赋分，分数=1/(60+rank) fusion_scores = {} for rank, doc_id in enumerate(vec_results["ids"][0]): fusion_scores[doc_id] = fusion_scores.get(doc_id, 0) + 1 / (60 + rank + 1) for rank, item in enumerate(bm25_results): doc_id = item["id"] fusion_scores[doc_id] = fusion_scores.get(doc_id, 0) + 1 / (60 + rank + 1) # 取融合后得分最高的20条，再进Rerank精排 candidates = sorted(fusion_scores.items(), key=lambda x: x[1], reverse=True)[:20] candidate_docs = [id_to_text[doc_id] for doc_id, _ in candidates] reranked = reranker.rerank(query, candidate_docs) # 返回降序排列的精排结果 final_docs = [doc for doc, score in reranked[:5]]

这里我重点说一下为什么RRF的得分函数里用的是60而不是1。这个参数叫常数k，作用是防止排名第一的文档得分过高从而碾压所有其他文档。k越大，排名带来的差异就越小，两个来源的贡献越均衡。实测里60是一个常见的均衡点，效果相对稳定。

3.1.6 生成阶段：用Prompt把检索结果钉死

from langchain_openai import ChatOpenAI llm = ChatOpenAI(model="gpt-4o-mini", temperature=0.2) context = "\n\n".join(final_docs) prompt = f"""请根据以下知识库片段回答问题。 要求： 1. 只能基于给定的知识库内容作答，不要使用你自身的先验知识。 2. 如果知识库中没有相关内容，请直接回答“知识库中未找到相关信息”，不要编造。 3. 每个论点请尽量说明来自哪一段内容，方便溯源。 知识库片段： {context} 用户问题： {query} """ response = llm.invoke(prompt) print(response.content)

这个Prompt是整套配置里最容易被忽视的。很多人镜像搭建了RAG，但生成的答案仍然像是大模型自己硬编出来的，一问原因，Prompt里连“只能基于知识库”都没有，那模型当然放飞自我了。

3.2 几个关键参数的定量分析

不少兄弟会问，这些数字是怎么定出来的？我挑几个重点讲透。

• 块大小（chunk_size）：本质是精度和召回率的权衡。块越小，每块的语义越纯，越容易精确匹配片段；但块越小也越容易丢失上下文，导致被检索出来后看不懂在说什么。块越大则相反，上下文全了但不相关的内容也多了，甚至embedding后的向量会被无关词干扰方向。600个token对中文通用文档是个比较稳的中间值。
• 重叠（chunk_overlap）：为了缓解切在语义断层处的问题。如果不重叠，当一句话刚好被切成两半时，这句话的两个残片就都坏了。重叠10%~20%相当于给这句话一个“落在下一块里完整出现”的机会。
• TopK召回数量：进Rerank之前的召回数量一定要大于最终想要的片段数。如果你最终只需要Top5进Prompt，那至少召回50个候选再筛。只召回20个，再扔到Rerank里筛5个，很容易出现矮子里面拔高个的情况。
• 温度（temperature）：生成阶段我直接设为0.2。RAG场景下要的是严谨和忠于原文，而不是发散创意。如果你发现回答总在“润色”知识库内容，把温度降到0效果会更明显。

另外我强烈建议建一个离线测试集，用真实的业务问题去验证检索命中率。我曾经在模拟项目X里自己整理了100条问答对，每轮改动之后跑一遍评分，才能明确知道方向对不对。

3.3 实操现场记录：从初级到高级的一次完整升级

我当时在做的模拟项目X是一个内部知识助手，初始版本走的是一套非常朴素的流程：直接对整个PDF切块->向量化->Top10召回->无脑拼接->大模型生成。效果特别糟糕，举例来说，同事问“XX设备的故障码E203是什么意思”，答案经常把E203和其他故障码混在一起，而且还一本正经地编了解决方案。

第一轮优化，我把数据清洗加上了，然后把Markdown结构切分逻辑做出来，结果对带有清晰章节目录的标准文档效果立刻好了一些。但对那种排版很乱、没有固定结构的说明文档依然两眼一抹黑。

第二轮优化，我上了混合检索。当时某同事提的一个问题：“财务报表附注里的递延所得税资产怎么确认”，纯向量检索时那一堆表格字符被切得稀碎，检索回来的段落根本读不通；加了关键词检索之后，因为“递延所得税资产”这几个字精确匹配了表格表头，正确段落直接被捞了回来。这个点让我深刻意识到混合检索的必要性。

第三轮优化，我引入了Rerank。用了一个专门的排序模型之后，效果提升非常直观。之前要传给大模型的Top5里总有两三条是硬凑数的，Rerank把真正有信息的段落往前挤，生成答案可读性直接上升一个台阶。

三轮优化做完，那个项目从“内部吐槽不断”变成了“居然还真能当搜索用”，我当时很感叹，高级RAG的价值不是某个单一技术点带来的奇迹，而是把每个环节都做到位的复利效应。

4. 常见问题与排查技巧实录

4.1 检索不到相关内容

症状：用户提问后，返回的片段完全没有覆盖关键知识点。

排查链路：

1. 先看单条召回结果。单独把问题拿去搜索，看一下召回的前10条都是什么内容。如果召回的片段里出现了原文档内容但你看着不像答案，那可能是切块把答案切碎了，或者答案被切断后语义不完整。如果召回的片段压根儿和问题毫无关系，那大概率是embedding模型对你们的领域用语不敏感，或者是双语、多语言数据混杂时模型选择不合适。
2. 检查查询和文档的表示方式。是不是文档里的关键信息是表格、图片、扫描件？如果一开始就没提取入库，后面怎么调都没用。
3. 换关键词试一遍。用BM25式精确关键词去搜，能搜到说明是embedding语义理解的问题；精确关键词也搜不到，说明是文档解析或索引的问题。

4.2 检索出来的内容相关，但答案还是胡说

这是最坑的一类问题：检索看起来命中了大方向，但生成结果依然天马行空。

我的排查经验里，最可能的原因是：

• Prompt约束不严。优化方法：明确“禁止使用知识库以外的事实”，并且在回答中要求标注引用片段序号。
• 多段信息互相矛盾。如果知识库本身存在新旧版本内容冲突，模型会倾向于自己调和，调和的结果可能就是瞎编。这时建议在Prompt里加一条“如果片段之间存在冲突，请指出冲突并分别呈现”。
• 温度太高。有些人喜欢把temperature调到0.7以上追求“回答自然”，但RAG场景真的大可不必。降到0.2左右，事实性会好很多。

4.3 检索结果的相关性分数很高，但内容不准确

这种情况多半是分块太粗。假设一个块是1000个token，里面前500在说A问题，后500在说B问题，查询B问题时向量依然能匹配到这个大块，因为块向量是整体表示的，结果就是你拿到了一个一半内容无关的块。

解决方向：

• 继续收窄分块大小；
• 按结构切分，保证一个块只承载一个主题；
• 引入语义切块方案，让句子之间的语义距离作为切分依据。

4.4 数据库里的内容更新了，但检索结果没变

这通常是缓存或者说向量库索引没刷新导致的。注意向量数据库和普通数据库不同，新增数据后需要重新触发embedding，并对相关索引做更新。我当时就吃过亏，在某次自动更新流程里更新了文档库但忘了重新向量化，害得整个下午都在排查为什么新增内容永远检索不到。

4.5 构建知识检索问题速查表

我们团队内部还习惯准备一个“毒鸡汤”测试集：专门准备一些刁钻、易混淆的问题，每次改完RAG配置都先跑一遍，确保不退化。这个习惯可以推荐给所有人，花不了多少时间，但能守住质量底线。

5. 进阶优化方向与个人经验谈

当你把上面这套基础打扎实之后，继续进阶还有很多可以玩的方向：

• 查询改写：有的用户提问特别口语化，比如“那玩意怎么弄？”，直接拿去检索大概率匹配不好。可以在检索前先让大模型把问题改写为更规范、信息更完整的查询语句，再进入检索链路。
• 多步检索：遇到复杂问题，只靠一次检索往往不够。可以把问题拆成几个子问题，分别检索，汇总后综合回答。这种思路在处理“对比型”“汇总型”问题的时候特别有用。
• 缓存机制：高频重复的问题，与其每次都做完整检索+生成，不如把结果缓存起来。通常能砍掉大量重复请求，在内部系统里价值极大。
• 上下文压缩：召回结果太多，直接把10个片段全塞给大模型，不仅贵、慢，而且大模型会“看不过来”。可以做关键句过滤或摘要压缩，只保留最相关的内容。

再分享一条我做RAG项目得来的铁律：所有优化措施上线前，先跑完测试集再谈效果。有些改动你以为提升了，实际上只是某条具体数据上表现好，换个场景可能直接崩掉。测试集和基准评测，永远是技术优化方向的指南针。

最后说一点个人体会：RAG这套方案，对小白来说最友好的一点在于它可以一步步迭代，不需要推倒重来。先把最简单的链路跑通，然后今天优化切块、明天加混合检索、后天调Rerank，每一步的收益都是肉眼可见的。别指望一口吃成胖子，也别因为初版效果差就放弃，把那100条测试问题跑起来，你会看到自己的系统一点点变得聪明，那感觉跟调教一个刚出生的AI助手似的，特别有成就感。