企业官网建设流程全解析

1. 项目概述：先弄明白 RAG 到底解决了什么问题

最近两年大模型应用爆发式增长，有一个词高频出现在各种技术讨论里，那就是 RAG。很多朋友看到这三个字母一头雾水，搜了一圈技术文档，结果被"Hugging Face""embedding""向量数据库"一堆名词劝退。其实 RAG 全称是 Retrieval-Augmented Generation，翻译过来就是检索增强生成。说白了，就是先让模型去一个外部知识库里查资料，再结合查到的内容来回答问题。

为什么需要这个东西？最直接的原因是：大模型有知识盲区，而且会一本正经地胡说八道。

我举个具体的例子。你问某个通用大模型："帮我介绍一下某个小公司刚发布的产品。"如果训练数据里根本没有这个产品的信息，模型有两种反应方式：要么直接告诉你不知道，要么按照它见过的类似产品"脑补"一个答案。后者就是所谓的幻觉问题。

RAG 的思路很简单：我不强迫模型自己记住所有知识，而是把知识放在外部存储里。用户提问时，先从外部知识库里找出最相关的若干段落，把这些段落连同问题一起塞给大模型，让模型基于这些材料来组织回答。这样模型就不用凭空发挥，回答的内容有依据、可追溯，还特别灵活。

打个比方，这就像开卷考试。传统大模型是闭卷考试，所有知识都在训练时背进脑子里，考完知识就固定了；RAG 是开卷考试，允许你翻课本，翻到哪一页就用那一页的内容作答。微调则像是在考前的题海训练里精炼思路，目标是让你掌握特定类型的答题套路。

适合谁看这篇文章？如果你正在做知识库问答、私有数据交互、企业文档智能助手，或者你在调研给大模型引入外部知识时选什么方案，这篇内容应该能帮你把 RAG 的原理、流程和选型决策看清楚。如果你是刚接触大模型应用开发的小白，这篇文章也会尽量用直白的语言把复杂概念讲透。

2. 整体设计拆解：为什么选 RAG 而不是让模型硬记知识

2.1 大模型知识机制的局限

要理解 RAG 的合理性，先要明白大模型的语言机制。预训练语言模型在训练时做的一件事，是把海量文本反复学习，把语料里的知识以参数形式存储下来。这些参数少则几十亿，多则数千亿。问题在于：你没办法轻易改写了。训练一次动辄几十万美元，时间以周或月计算，所以知识截止在训练数据那一瞬间，之后发生的事情它一概不知。

还有一个隐蔽的问题：模型并不区分"事实"和"常见搭配"。它对语言的统计规律敏感，对事实逻辑是弱监督学习。所以当用户问得很具体、涉及领域很冷门时，模型会"顺着语感说下去"，结果就是编造出一个看着合理、其实不存在的答案。

2.2 RAG 的设计哲学：把知识外挂

RAG 的聪明之处在于，它不在模型本体上做文章，而是把知识的存储与管理完全外部化。"外部知识库 + 检索模块 + 生成模型" 三段式结构，让系统具备三个突出优势：

第一，知识即时可更新。你只需要往知识库里新增、修改或者删除文档，下一次问答立刻生效，根本不需要重新训练模型。这点对知识时效性要求高的业务场景非常宝贵。

第二，答案有据可查。RAG 系统可以把检索到的原始段落附在答案后面，用户能看到答案依据来自哪份文档，这种可解释性对企业合规、医疗、法务等场景特别重要。

第三，权限隔离清晰。企业内部不同部门的文档可以分别存储在独立的索引空间，检索时按权限过滤，外部模型接触不到原始内容。这也是很多企业愿意引入 RAG 的原因——既要大模型的生成能力，又不想把核心数据交给模型去训练。

2.3 RAG 和微调的本质分叉

微调是在模型参数层面动手术。你基于一个通用模型，用特定领域的标注数据进一步训练它，让模型的权重向量往目标领域偏移。这种做法改变了模型内在的知识结构，适合"改变语言风格""学会某种任务格式"这类需求。

但 RAG 和微调面对的是不同层次的问题。微调难以解决的问题恰好是 RAG 擅长的：知识频繁更新、知识深度定制、答案需要溯源。反过来，RAG 处理不了"模型回答格式混乱""逻辑能力不足"这类问题，那需要微调来纠正模型的输出习惯。

通常一个成熟的系统不会只选其一。真实项目中常见的实践是：用微调调教模型的表达方式和遵循指令的能力，用 RAG 注入实时、私有、精确的知识。两者配合，而不是二选一。这个思路我会在第 4 部分详细展开。

3. 核心细节解析：RAG 流水线的每个环节怎么搭

3.1 文档加载与清洗

RAG 的第一环是准备知识文档。很多初学者忽略了这个环节，直接把 PDF、Word 往系统里丢，结果发现检索效果极差。文档清洗的工作量非常大，而且直接决定下游检索质量，我在这上面吃过不少苦头。

首先，格式解析要到位。PDF 文件要把表格、页眉页脚、多栏排版处理好。同一个表格被切碎成几段文本，检索时语义就断裂了。页眉页脚如果不剔除，检索的时候会把"第 3 页共 20 页"这种噪音当知识段召回，既浪费 token 又干扰答案。

其次，文档去重很重要。企业内部常见的情况是同一份制度文档有多个版本，有的在 OA 系统里，有的在共享网盘里，还有一份在邮件附件里。如果不去重，检索时会召回多个相似段落，大模型把不同版本的表述混在一起，生成结果可能自相矛盾。

最后，文档的冗余信息要清理。常见的问题是原文包含大量无效内容，比如产品规格书里的介绍性章节占了一半篇幅，真正有技术参数的内容只有几行。检索引擎按相似度匹配，如果冗余文字多，关键词容易被稀释。我的经验是：知识库文档最好按"一条知识一个主题"来组织，粒度越清晰，检索命中率越高。

3.2 文本切分策略：chunk 大小怎么定

文本切分是 RAG 里门道最多的环节之一。切分太粗，一段文本可能包含多个主题，检索时风吹草动都命中这个大块头，答案里会混入大量无关内容。切分太细，又可能导致语义单元不完整，比如一个判断条件被切开，上半句在 chunk A 里、下半句在 chunk B 里，检索召回一半。

切分策略里有两个关键参数：chunk_size 和 chunk_overlap。

chunk_size 是每个块的最大字符数。通常建议区间在 300 到 800 个字符之间，具体取决于你的文档类型和模型上下文窗口。技术文档、规章制度这类逻辑完整的长段落，可以适当调大一点，例如 500 到 800。短平快的 FAQ 条目，建议 200 到 300，因为一条问答本身就是一个完整语义单元，不需要人为拼凑。

chunk_overlap 是相邻块的重复区间。为什么要重叠？因为一个完整句子很可能跨越切分边界，如果完全没有重叠，这个句子的后半段会变成下一段的开头，单独检索时缺失前半部分的语境，语义会偏差。我常用 50 到 150 字符作为重叠区间，确保句子不会从中间断掉。

还有一个很多人忽视的细节：尽量在自然语义边界处切分，而不是生硬按字符数截断。比如按段落回车符、按 Markdown 标题层级、按句号来切分，会显著提升块内的语义内聚性。很多工具框架默认支持按结构切分，别偷懒，用起来。

3.3 向量化：embedding 模型的选择和维度考量

文本切好之后，要把它转成向量才能比较相似度。embedding 模型做的事情就是把一段文本映射到一个高维向量空间，语义相近的文本在空间里的位置也相近。

选择 embedding 模型时，我关注三个点：语言支持、句向量质量、向量维度。

如果知识库以中文为主，优先选择在中文语料上表现良好的模型。通用模型在中文上偶尔会出现同义词匹配不准确的问题，比如"笔记本电脑"和"便携式电脑"在很多模型里向量距离并不近，这时候检索效果就有点辣眼睛。

向量维度影响存储成本和检索速度。384 维的模型比 1536 维的模型存储开销少很多，但表达细腻语义的能力通常也弱一些。如果企业知识库在千万级文档规模，维度上去之后存储成本会变得可观，需要权衡。

在实际项目中，我习惯用 embedding 模型把文本向量化之后，先用若干典型问题做个自测。比如在知识库里放几个语义相近但不完全相同的句子，看看模型能不能把它们区分开、又能不能把同义的表述都召回。这种小规模验证比盲目调参有效得多，几十个测试用例基本就能判断一个 embedding 模型是否合用。

3.4 向量数据库选型：存储和检索的容器

向量数据库负责两个事情：存向量、按相似度检索。市面上选择不少，选型本质上是在功能、性能、运维复杂度之间做权衡。

对于中小规模项目（百万级向量以内），可直接采用轻量方案，避免引入过重基础设施。例如，可以使用支持向量索引的开源数据库，跑在单机上也够用，部署维护成本低。上亿级别的向量场景，或者需要毫秒级响应、高并发访问的场景，则建议上分布式方案。这种方案通常提供分片、副本、高可用等能力，但相应地也需要专门的集群运维资源。

还有一个决策点是：是否需要混合检索。纯向量检索有统计意义上不错的相似度效果，但对精确的关键词匹配不够敏感。比如问"合同编号 X-2024-001 的审批流程"，纯向量检索可能把"编号""审批""流程"这些语义向量都召回了，却不保证精确命中那个编号字符串。混合检索的思路是把关键词（稀疏检索）和语义（稠密检索）结合，用 BM25 之类的算法做关键字召回，再用 RRF 分数融合两类结果。

如果项目预算和技术栈允许，我强烈建议把混合检索作为 RAG 系统的内生能力，而不是上线后再补。因为实际业务文档里精确标识符出现的频率实在太高，只靠语义检索很容易出岔子。

3.5 检索阶段：召回数量重排序和相似度调优

检索阶段面临的核心矛盾是"精度"和"召回"的权衡。召回太少可能漏掉关键答案，太多则噪音干扰生成。

先说说 top_k 如何设置。这个参数决定每次检索返回多少个片段。k 值太小，答案不完整；k 值太大，塞进模型上下文的内容太多，既烧钱又降低响应速度。我常用的策略是先设一个保守值，比如 4 到 6，跑一轮测试看效果，再逐步调整。上下文窗口够大的模型可以适当放宽到 8，但不宜超过 10——再往后召回的边际收益非常低。

如果对检索质量有更高要求，一定要加一个重排序（rerank）环节。第一轮向量检索用高效但精度略粗的方法拉出候选，然后用一个轻量级的交叉编码器模型对候选逐条打分排序，把真正相关的排到最前面。这能有效解决"向量相似度高，但实际上下文不太相关"的问题。代价是重排序会增加几十到几百毫秒的延迟，需要根据实际场景权衡。

检索效果差的常见症状是：答非所问。碰到这种问题别急着调模型，先看检索引擎召回的文档是否相关。这是排查的首要方向。

3.6 生成阶段：提示词模板的设计技巧

检索到的文本最终要和大模型对话，提示词模板的设计直接影响回答质量。

一个合格的 RAG 提示词应包含三个要素：检索片段、原始问题、输出约束。

检索片段部分，我会在模板里明确说明"以下内容是从知识库中检索到的参考资料"。如果检索结果为空或与问题相关性较低，应明确提示模型不要强行引用。这个问题经常被忽略，实际中当知识库没有相关内容时，模型往往会强行从片段的字缝里编造答案，导致幻觉。

输出约束部分，常见做法是要求"只依据资料内容回答，不要加入自己的知识""如果资料中找不到答案，直接说明未找到"。这样的约束能大幅降低模型"自由发挥"的概率。

我分享一个实践过的模板结构：

你是一个智能问答助手，请根据以下资料回答用户的问题。 资料： {context} 问题： {question} 要求： 1. 回答时只依据上述资料，不添加资料中没有的内容。 2. 如果资料与问题无关或信息不足，直接回复"未在知识库中找到相关信息"。 3. 引用资料内容时，保持原文的关键信息不变。

别小看这几行字。同样的检索引擎、同样的文档库，配上清晰的提示词约束，回答质量差异非常明显。

4. RAG与微调的选型对照：什么时候该用谁

4.1 微调的本质：在大模型身上动刀

微调是在预训练模型的基础上，用一批高质量标注数据继续训练，让模型的权重发生改变。这个过程的产出物是一个新的模型文件，部署时把旧的替换掉。

微调擅长解决的是模型的"行为问题"。比如你希望模型回答问题时语气从百科式改成聊天式；你希望模型看到代码时按照公司规范输出格式；你希望模型在特定任务上遵循固定的输出 schema。这些都属于模型内在行为模式的调整，微调是正解。

但微调对"事实知识"的引入效率很低。模型的参数量巨大，想让它在回答甲问题时记住"某产品支持的功能清单"，在回答乙问题时记住"某制度的关键条款"，你需要在训练数据里提供大量此类样本。被记住的知识是隐式的，你无法控制模型在具体提问时调取哪段记忆，也无法快速修正某个错误知识点。

4.2 两者对比：一个表格说清核心差异

从表格能看出，RAG 和微调覆盖的能力面几乎正交。RAG 负责"知道什么"，微调负责"怎么回答"。

4.3 组合实践：RAG + 微调的典型架构

在真实项目中，我见过不少团队纠结"到底选 RAG 还是微调"，其实这种二选一的问法本身就有问题。成熟的架构通常是一套组合拳。

一个典型的企业内部知识助手架构是这样的：先对通用底座模型做一次轻量微调，让模型学会规范的指令遵循能力、格式输出能力以及对特定领域术语的敏感性。然后在这个微调模型之上，部署完整的 RAG 流水线。知识库里的文档负责提供事实依据，微调模型负责把事实素材组织成高质量、格式规范的答案。

举例说明：某企业的客服机器人，期望的回答风格是简洁、温和、避免专业术语轰炸。只靠 RAG 的话，模型可能把检索到的技术文档原封不动地转述，回答又长又专业，不符合客服风格。如果先做一轮小规模的风格微调，再叠加 RAG 检索，就能做到"语气合适、依据真实"。

但如果预算紧张，只做 RAG、不微调也能跑起来。我的建议是：第一阶段先上纯 RAG 系统，跑通业务流程，观测质量瓶颈在哪里。如果发现模型经常答非所问、格式混乱、指令跟随差，再来考虑针对性微调。不要一开始就双管齐下，否则出了问题很难定位是哪一环贡献了劣质结果。

5. 实操过程与核心环节实现：从零搭一个最小可用 RAG 系统

5.1 环境准备与开发库选择

我以最常用的技术栈来演示：Python + 开源 embedding 模型 + 支持向量索引的数据库 + 语言模型接口。

开发库建议：

• 文档处理与切分：可选通用文档解析库配合文本切分器，常见的有 Unstructured、LangChain 里的文本切分器
• embedding 生成：选择一个开源的中文 embedding 模型，通过 Hugging Face 的库加载，或者使用各云厂商的 embedding 接口
• 向量存储：中小项目可以直接用支持向量功能的开源数据库，也可以通过专门的向量数据库提供方接入，具体看你的部署环境
• 语言模型调用：接入任意大模型接口，本地部署或云端调用均可

虚拟环境建议用 Anaconda 或 venv 创建独立 Python 3.10 环境，避免开发时版本冲突。我个人的习惯是把所有依赖锁定版本，方便复现。

5.2 文档加载和切分代码示例

from typing import List import re def load_documents(file_path: str) -> List[str]: """加载文本文件，按段落粗分""" with open(file_path, "r", encoding="utf-8") as f: content = f.read() # 按空行分割段落 raw_paragraphs = re.split(r"\n\s*\n", content) return [p.strip() for p in raw_paragraphs if p.strip()] def smart_chunk(paragraphs: List[str], chunk_size: int = 500, overlap: int = 100) -> List[str]: """按语义边界切块，避免中间断句""" chunks = [] buffer = "" for para in paragraphs: # 如果当前缓冲加上新段落超过 chunk_size，先截断缓冲 while len(buffer) + len(para) > chunk_size: cut_pos = chunk_size - len(buffer) if cut_pos <= 0: # 缓冲已满，先切出 chunks.append(buffer) buffer = "" cut_pos = chunk_size # 找最近的句号或换行作为切点 split_at = para[:cut_pos].rfind("。") if split_at == -1: split_at = para[:cut_pos].rfind(". ") if split_at == -1: split_at = cut_pos else: split_at += 1 buffer += para[:split_at] chunks.append(buffer) para = para[split_at:] buffer = "" buffer += para + "\n" if len(buffer) >= chunk_size - overlap: chunks.append(buffer) buffer = "" if buffer: chunks.append(buffer) return chunks doc_paragraphs = load_documents("knowledge_base.txt") chunks = smart_chunk(doc_paragraphs) print(f"原始段落数: {len(doc_paragraphs)}, 切分后块数: {len(chunks)}")

上面的代码展示了一个典型的按语义边界切分策略。切分时优先找句号作为断点，避免把句子切成一半。实际项目中建议再用工具库里的递归字符切分器做一次微调，配合标题层级分割，效果更可控。

sharpen提醒一句：切分策略没有绝对的最优，不同知识库的最佳参数不同。切分后跑几轮检索测试，观察命中的块是否语义完整，再回头调参数。

5.3 批量生成向量并写入数据库

from sentence_transformers import SentenceTransformer # 加载 embedding 模型 embed_model = SentenceTransformer("你的模型名称") # 为每个 chunk 生成向量 chunk_vectors = embed_model.encode(chunks, normalize_embeddings=True) # 写入向量数据库（伪代码，具体取决于选型） for idx, (chunk, vector) in enumerate(zip(chunks, chunk_vectors)): vector_db.insert({ "id": idx, "text": chunk, "vector": vector, "metadata": {"source": "knowledge_base.txt", "chunk_id": idx} })

向量入库时保留原始文本和元数据是关键点。生成答案时，我们需要把检索到的 chunk 原文喂给语言模型，而不是只喂向量。元数据里存文件来源、章节信息，方便追溯和做权限过滤。

5.4 检索与生成完整流程

def retrieve(query: str, top_k: int = 5) -> List[str]: """检索相关片段""" query_vector = embed_model.encode(query, normalize_embeddings=True) # 相似度检索，返回最相关的 top_k 条 results = vector_db.search(query_vector, top_k=top_k) return [r["text"] for r in results] def generate_answer(query: str, context_chunks: List[str]) -> str: """基于检索片段生成回答""" context = "\n\n".join(context_chunks) prompt = f"""你是一个基于知识库的问答助手。请根据下面的资料回答问题。 资料： {context} 问题： {query} 请只依据资料回答，不要编造。 """ response = llm_call(prompt) # 替换为你的模型调用函数 return response def rag_pipeline(query: str) -> str: chunks = retrieve(query) if not chunks: return "未在知识库中找到相关信息。" answer = generate_answer(query, chunks) return answer

这个流程看似简单，却是整个 RAG 系统的骨架。从实际运行角度，还有几个细节值得注意：检索函数返回的 chunks 应按照相关度排序后填入提示词；如果 top_k 结果中包含高度重复的内容，可以做一次简单去重再拼接；引用原始文档编号可以加在 prompt 的约束里，方便后续做溯源展示。

5.5 检索质量评估：不要只靠肉眼看

很多团队把 RAG 系统搭起来后只做手工验证，随机问几个问题看回答是否合理，这很可能掩盖大量问题。对检索环节做系统性的离线评估很有必要。

一个简单的评估方法是准备一组问答对（如 30-50 条），每条问题标注出知识库中应当被召回的正确文档片段。然后跑检索，计算命中率（Recall@k）。如果正确片段没有出现在前 k 个候选里，说明检索环节有问题。生成结果的质量评估更复杂一些，可以用 LLM 辅助评分，或者人工抽检。

有团队用独立开发的小工具去pipeline生成过程加观测点：每轮问答记录检索了哪些块、模型见了哪些块、最终生成了什么。这样评测试图定位问题环节压力大减。如果你刚开始做 RAG 应用，我建议把观测日志当作基础设施来搭，越早越好。

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

6.1 检索结果为空

症状：不论问什么，系统都回答"未找到相关信息"。

排查步骤：

1. 检查查询向量是否成功生成。embedding 模型接口偶尔会静默抛异常，先看日志里向量维度是否正确。
2. 检查向量库里是否有数据。开发中常见的问题是入库时数据量太大，写入失败被忽略。
3. 检查相似度阈值。很多向量数据库默认有最小相似度过滤，如果阈值设得太高，普通查询很难达到，结果全被过滤掉。
4. 确认不是查询本身太模糊。比如问题只有一两个字，向量搜索引擎本来就难命中，建议引导用户提供更完整的问句。

6.2 检索结果相关但答案不对

症状：召回的片段肉眼看起来和问题相关，但模型生成的答案离题。

这里要区分两种情况。第一种是提示词约束不够，模型把相关资料里可有可无的信息拿出来自由发挥了。解法是把提示词约束写得更强硬："只能使用资料中直接出现的陈述，不得推断、总结、联想。"

第二种是片段本身包含答案但混合了大量噪音信息。比如片段是一整章产品介绍，涉及几百字，正确答案只在其中一句。这种情况与其调提示词，不如从切分粒度着手。打开检索日志看召回片段的内容长度和结构，如果普遍偏长，请缩小 chunk_size，重跑向量化。

6.3 答案对但引用来源不对

这个问题的深层原因通常是相似度检索召回"相似但不精确"的文本。例如用户问"请假流程是什么"，知识库里同时有"请假流程""出差审批流程""休假管理制度"三个文档片段，向量相似度都高。正确答案来自第一份，模型却综合了三份内容生成了一段万能答案，引用时无法定位到唯一来源。

解法是引入重排序模型，它对语义匹配的判断比纯向量相似度精确得多，能把精确相关的文档排在前面。同时，在提示词里要求"回答必须围绕检索片段中最相关的条条款展开，不要跨文档合并信息"。

6.4 幻觉还是压不下去

即使用了 RAG，仍然可能出现幻觉。最常见的原因是检索召回的片段里本身就不包含答案，但模型基于已有的知识平滑地接了一句。这个问题本质上是模型在"资料不足"时不会主动承认不知道。

我试过比较有效的做法：一是在提示词里显著提示"如果资料中没有答案，请明确回答知识库中未记录"，二是设置一个相关性判断前置环节。检索之后，先用一个分类器或指令模型判断召回的片段是否真正能回答问题，如果判断为否，直接终止生成流程，返回"知识库中未找到答案"。这一步能拦截大量低质量生成。

6.5 性能太差响应慢

RAG 系统的延迟通常比纯模型调用多一些。排查重点：

• embedding 阶段：中文长文本 embedding 计算较慢，可以先对查询做归一化和截断，控制输入长度。
• 检索阶段：向量数据库的索引类型和参数对延迟影响大。如果数据量增长很快，需要定期重建索引。
• 重排序阶段：交叉编码器重排序是延迟大头，但能显著提升质量，建议保留但选择轻量级模型，或只在 top-k 扩大的时候启用。
• 生成阶段：调低模型的 max_tokens，或者换更快的推理引擎。

6.6 常见问题速查表

7. 实操心得与扩展方向

试过几轮 RAG 项目之后，我个人最深的体会是：把 RAG 当成"检索 + 生成"两层结构是不够的，它本质上是一个信息系统的改造工程。文档治理、切分策略、评估闭环、模型选型，每一环都值得认真对待。

有一个我反复强调的经验：先做领域调研，再选 embedding 模型，别盲目追求新模型榜单的 SOTA。真实场景中的领域术语、文档格式、语言习惯千差万别，泛化能力强的模型未必在特定领域的数据上效果最优。我在一个法律文档项目里实测过，某个通用榜单排名靠前的模型对法条术语的向量表达并不理想，换成法律预训练模型后检索准确率显著提升。

另外，RAG 系统的知识库维护是一个持续工作，不是上线就结束了。文档更新后向量索引要同步重建或增量更新，定期评估沉淀问答数据，把高频问题的标准答案维护到一个独立的知识区。很多企业把 RAG 项目做成"一次性交付"，结果上线三个月后端到端的检索质量明显下滑，根源就在知识库没有日常运营机制。

RAG 这个方向还在快速演进，比如把重排序、混合检索、引用溯源进一步工程化，或者对知识库做更细粒度的权限管理。但万变不离其宗，核心始终是：让模型在回答每个问题时，都能方便、准确地读到它该读的那段知识。把这个理念落实到位，无论工具怎么升级，你的系统都能保持稳定可靠。