企业官网建设流程全解析

做大模型应用开发以来，我被问得最多的一个问题不是"模型怎么选"，而是"怎么让模型知道我们公司内部的知识"。你问它"报销流程是什么""某型号设备怎么维护"，它要么一本正经地开始编，要么直接说不会。一开始有人提议微调，结果数据准备了一周，效果依然不稳定，更新一次还要重训，成本高得吓人。后来我转向了检索增强生成（RAG），也就是把大模型和外部知识库结合起来的应用框架。这篇文章把我踩过的坑、验证过的做法、能直接跑起来的代码，以及为什么某些方案会翻车的原因都整理出来，希望能成为你入门 RAG 的一份"可抄作业"参考。

1. 先从"模型不会的题"说起：RAG 解决的真实痛点

1.1 微调不是万能药

很多做知识问答的人第一反应是微调，这可以理解：模型不会，那就教它。但实际操作下来，微调在知识型问答场景里有几个绕不开的问题。

一是知识覆盖不可控。你准备 1000 条问答对，模型看起来会答了，但换一种问法，可能又不会了。微调是在调整模型对参数空间的记忆，它不像数据库查询那样可以做到精确命中。二是更新成本高。业务文档每个月都在变，每次更新都要重新准备数据、重新训练、重新测试，一个知识问答系统如果周五发现文档改了，下周一就要上线新答案，微调节奏完全跟不上。三是遗忘问题。微调过的模型可能在新增知识上表现不错，但原有的通用能力会下降——这种现象行业内叫灾难性遗忘，越是小模型越明显。

把微调理解成"让一个人去上大学课程"可能更容易分清楚：它改变的是这个人的长期能力；而 RAG 是"考试时允许翻参考书"，它不改变模型本身，只是临时给模型提供参考资料。对于"知识实时更新、答案需要溯源"的场景，翻参考书显然比给整个模型"补课"划算得多。

1.2 长上下文窗口来了，RAG 还有必要吗

现在不少大模型支持很长的上下文窗口，动辄几十万字。于是有人质疑：既然能把整本手册直接塞进提示词，何必还要检索？

这种想法在"单文档、短文档"的场景勉强成立，但在真实知识库场景会撞墙。首先，企业知识库通常是几百上千篇文档，不是一篇长文，上下文窗口再大也塞不下全部内容。其次，token 成本不是线性的，塞得越多，单次调用越贵，响应越慢。更微妙的问题是，模型对长上下文的注意力并不均匀，大量无关文字混进来时，模型反而容易忽略真正关键的段落——这就是所谓的"大海捞针"困境。长上下文适合读一篇长报告，RAG 适合在整个知识库里找答案，两者是互补关系，不是替代关系。

1.3 一张表格看懂三种技术路线的取舍

我把微调、RAG、长上下文三者的差异整理成了表格，方便决策时快速对照。

2. 拆开 RAG 的骨架：索引、检索、生成三段式架构

2.1 离线索引阶段：知识入库前的三道工序

RAG 的第一阶段发生在用户提问之前，是把原始文档变成"机器可查找"格式的过程。这个阶段有三个环节，任何一个做得粗糙，都会在后续检索阶段暴露问题。

第一是文档解析。PDF、Word、Markdown、HTML、扫描件，每种的解析难度都不一样。很多 PDF 看着排版正常，转出来之后文字是错乱的，表格更是重灾区。我个人的经验是：如果文档本身就是 Markdown 或结构化 HTML，直接用；如果是 Word，尽量转成 Markdown 再处理；如果是复杂排版的 PDF，解析后一定要人工抽查几页，不要盲目相信解析工具的输出。

第二是文本切分。切分是 RAG 项目里最容易影响最终效果的一环。切得太粗，一个块里既有背景介绍又有结论，检索时会带进大量无关信息；切得太细，块与块之间语义断裂，模型拿到的上下文不够完整。常见的做法是设置 chunk_size（块大小）和 chunk_overlap（相邻块重叠长度）。比如块大小 512 个 token，重叠 64 个 token，这样既保证语义相对完整，又不会让边界处的句子被硬生生截断。我后面会详细聊切分踩坑，这里先记住一个原则：切分不是给程序看的，是给模型看的，要以"语义完整"为最高目标。

第三是向量化入库。把切好的每个文本块通过嵌入模型转成向量，然后写入向量数据库。这一步要额外考虑的是元数据：每个块要带上文档编号、章节名、来源链接、更新时间、权限标签等信息。不要小看这些附带字段，它们在做知识过滤时至关重要——比如"只搜 2024 年之后的文档""只搜市场部的资料"，没有元数据就只能全库一把梭。向量数据库里真正被检索的不止是向量本身，元数据过滤往往是召回精度的隐藏功臣。

2.2 在线检索阶段：把用户问题变成一次"模糊匹配"

用户提问时，系统把问题文本转成向量，然后在库里做相似度搜索，召回最相关的若干文本块。这一步的核心是近似最近邻检索，常用的索引结构是 HNSW（分层可导航小世界图）。听起来复杂，思路其实很简单：它把向量组织成一个多层图，顶层是稀疏的"高速公路"，底层是密集的"小路"，查找时先从顶层粗定位，再逐层细化，用牺牲少量精度换取远超暴力搜索的速度。

检索阶段最容易被忽略的是top-k 的设置。k 太小时容易漏掉正确内容，k 太大时又把大量低相关片段混进生成提示，干扰模型判断。我在实际项目里的惯用做法是：粗召回 20 到 50 个候选块，经过重排后，只把最相关的 3 到 5 个块留给生成阶段。检索的目的不是把所有相关材料都呈现给模型，而是优中选优，把噪声压到最低。

2.3 生成阶段：上下文注入与约束输出

召回完成后，系统把选出的文本块拼接进 prompt，再让大模型基于这些文本生成答案。这个阶段有两个关键设计。

第一个是指令模板。模板写的松散还是严格，会直接影响回答质量。我常用的基础指令框架是：

你是一位知识库问答助手。以下是从资料库中检索到的参考片段，请依据这些片段回答用户问题。如果片段中没有相关信息，请明确回答"资料中未找到相关信息"，不要编造。

模板里要显式告诉模型"材料不足时如何表现"，这比单纯说"不要编造"效果更好。语言模型在明确的负面指令下，倾向于说"没有相关信息"，而不是强行给一个错误答案。

第二个是引用来源。我通常会在每个参考块前加上编号，然后要求模型在回答时用 [1]、[2] 这样的标记标注信息出处。这个设计在真实业务中非常有用：用户如果对答案存疑，可以直接点开原始文档核实。没有引用机制的 RAG 系统，即便回答正确，可信度也会大打折扣。

3. 检索质量是 RAG 的生死线：向量检索、BM25 与重排配合

3.1 纯向量检索的短板：语义相似不等于相关

向量检索的原理是把语义相近的内容映射到高维空间中位置相近的点。它擅长处理"用含义不同但语义相近的话提问"的场景，比如搜"怎么报销"能找到"差旅费用申请流程"。但向量模型面对精确标识符时经常失灵。

举个例子：用户搜"DQ-502 型传感器如何校准"，向量模型会敏感地抓到"传感器""校准"这类语义词，召回的可能是其他型号传感器的校准文档，而"DQ-502"这个字符串本身在语义空间里几乎没有权重。反观关键词检索，对精确型号、错误代码、人名、缩写等字符串的匹配能力远强于向量检索。

更麻烦的是，向量模型还容易陷入语义表面相似但实质无关的陷阱。比如"项目延期了怎么办"和"项目延期的原因分析报告"，两句话在语义空间距离很近，但前者要的是处理办法，后者是一份事故分析，根本不是同一类信息。如果只用纯向量检索，这种干扰几乎无法避免。

3.2 BM25 与向量检索怎么搭配：从并行召回说到 RRF 融合

既然向量检索长于语义、短于精确匹配，关键词检索长于精确、短于语义泛化，那自然想到把两者结合。

常见的做法是并行召回：同一个 query 同时走向量检索和 BM25 关键词检索，各取 top 若干条，然后把两路结果混合起来。但混合不是简单的去重拼接，因为两类得分的分布区间完全不同，没法直接比较谁更优。业界常用的融合算法叫 RRF（倒数排名融合），公式是：

score = Σ 1 / (k + rank_i)

其中 rank_i 是某篇文档在第 i 路检索中的排名，k 通常取 60。这个公式没有用到具体得分，只看排名，所以天然规避了不同检索器打分尺度不一致的问题。举例来说，一个文本块在向量检索里排第 2，在 BM25 里排第 10，融合分就是 1/62 + 1/70，约等于 0.0294；另一块在两路检索里都排第 30，融合分只有 1/90 + 1/90，约等于 0.0222。融合后明显更优。

实践下来，混合检索比单独任何一种检索都有质的提升，尤其是涉及型号代码、政策编号的场景。这里的前提是你得同时维护两套索引，BM25 可以直接基于原始文本块构建，成本并不高。

3.3 重排序：召回可以糙，精排必须准

召回的候选块仍然可能有噪声，于是需要重排序这一步。先想清楚两个概念：向量检索模型属于双塔结构，query 和文本块各自编码成向量后再算相似度。这种结构虽然没有编码交互，无法在最后一层对齐 query 与文本块的细微关系，但胜在速度快、能应对海量候选。

重排序阶段则可以用交互式编码器，业内常叫 cross-encoder，它把 query 和文本块拼接在一起，作为一个整体输入模型，逐 token 交互后输出一个相关性打分。效果更准，但计算量远大于双塔结构，不可能对全库打分。所以工程上的标准做法是两段式检索：先靠双塔模型快速筛选出几十个候选，再用 cross-encoder 精排，最后只把排名前几的块送入生成模块。

实际项目里，精排打分还有一个用途：设置质量阈值。如果精排后最高分都很低，说明知识库里可能压根没有相关内容，此时就应该触发"资料中未找到相关信息"的分支，而不是强行回答。这一步对压制幻觉非常有效，我在 5.3 小节还会展开讲。

4. 从零搭一个可用的 RAG 问答服务：核心代码与工程选型说明

4.1 环境准备与基础选型

这一节提供的代码足够跑通一个最小可用系统，覆盖文档切分、向量化入库、检索、重排列接口、生成问答完整链路。技术栈选型如下：

• Python 3.10 以上
• sentence-transformers：加载嵌入模型，负责文本转向量
• faiss-cpu：本地向量检索，简单直接
• rank_bm25：关键词检索实现
• 一个用于精排的 cross-encoder 模型
• 模型服务商提供生成式大模型接口，代码里用占位函数表示

先安装依赖：

pip install sentence-transformers faiss-cpu rank_bm25

我自己在原型阶段偏好"自己动手写"而不是直接引入某个全功能框架，原因很简单：RAG 的每个环节都是可以单独调优的，如果你一开始就被框架抽象掩盖了细节，出了问题很难判断是哪一环的锅。先把核心逻辑手写完，理解了每块的作用，再考虑引入框架来减少重复劳动。

需要解释一下向量库的选型。FAISS 更适合本地原型和个人项目；如果做小型团队知识库，想省事，可以用带持久化的轻量向量库；如果是企业级、数据量千万级、要求高并发，则要考虑生产级分布式向量库，支持多副本和滚动更新。选型时先看数据量和查询量，不要一上来就上重武器。

4.2 文档加载与切分

假设我们有一份 Markdown 格式的产品手册，先加载全文，然后做递归字符切分。递归切分的核心逻辑是：按预设的分隔符优先级从粗到细拆文本，尽量保持段落和句子的完整。

# -*- coding: utf-8 -*- from langchain_text_splitters import RecursiveCharacterTextSplitter text = open("product_manual.md", encoding="utf-8").read() splitter = RecursiveCharacterTextSplitter( chunk_size=512, # 块大小，中文场景按字符计比较稳 chunk_overlap=64, # 相邻块重叠，保留边界上下文 separators=["\n\n", "\n", "。", "；", "，", " ", ""] ) chunks = splitter.split_text(text) print(f"共切分为 {len(chunks)} 个文本块")

很多文档切分教程用 token 数来算 chunk_size，但在中文场景我建议直接按字符数，再估 token 数。中文一个字对应 0.6 到 1 个 token 不等，按 token 切容易在不同文本块间产生长度抖动。按字符切分更可控，参数直觉也更直接。切分完成后抽查几个块，确认没有在句子中断开，这一步很笨但很有效。

4.3 向量化与入库

嵌入模型的选择直接影响检索效果。中文场景基本思路是选中文语料上表现好的开源向量模型。加载和编码代码如下：

from sentence_transformers import SentenceTransformer # 换成你选定的向量模型名称 embedder = SentenceTransformer("your-embedding-model-name") dim = embedder.get_sentence_embedding_dimension() print(f"向量维度: {dim}") # normalize_embeddings=True 会把向量归一化，便于用内积计算余弦相似度 vectors = embedder.encode(chunks, normalize_embeddings=True, show_progress_bar=True)

建索引时，我用 FAISS 的 IndexFlatIP，这是暴力精确检索，数据量在几十万以内完全够用。如果想再快一点，可以换成 HNSW 索引，但原型阶段不必着急优化。

import faiss import numpy as np dim = vectors.shape[1] index = faiss.IndexFlatIP(dim) index.add(vectors.astype(np.float32)) # 保存文本块列表和索引，后续检索使用 with open("chunks.txt", "w", encoding="utf-8") as f: for i, c in enumerate(chunks): f.write(f"{i}\t{c}\n") faiss.write_index(index, "demo.index")

要注意，IndexFlatIP 配合归一化向量，计算的就是余弦相似度，分数范围在 -1 到 1 之间，在实际检索时这个分数可以作为置信度的参考。

4.4 关键词检索与混合召回

关键词检索我用 rank_bm25，直接对原始文本块做词频统计。中文需要先分词，这里用了简单的 jieba 分词，生产环境可以换成更规范的词表。

import jieba from rank_bm25 import BM25Okapi tokenized_chunks = [list(jieba.cut_for_search(c)) for c in chunks] bm25 = BM25Okapi(tokenized_chunks) def bm25_search(query, top_k=20): tokens = list(jieba.cut_for_search(query)) scores = bm25.get_scores(tokens) top_indices = np.argsort(scores)[::-1][:top_k] return [(i, scores[i]) for i in top_indices]

混合召回这里做一个便捷实现。向量检索拿到排名，BM25 拿到排名，用 RRF 融合后再取前 N 个候选。

def vector_search(query, top_k=50): qvec = embedder.encode([query], normalize_embeddings=True) scores, indices = index.search(qvec.astype(np.float32), top_k) return [(int(idx), float(score)) for idx, score in zip(indices[0], scores[0]) if idx >= 0] def rrf_fusion(vector_hits, bm25_hits, k=60, top_n=50): merged = {} def _add(hits): for rank, (idx, score) in enumerate(hits): merged[idx] = merged.get(idx, 0.0) + 1.0 / (k + rank + 1) _add(vector_hits) _add(bm25_hits) sorted_hits = sorted(merged.items(), key=lambda x: x[1], reverse=True) return sorted_hits[:top_n]

召回上下文写在一起，生成模块直接调用即可。这套逻辑虽然简单，但已经是很多生产级检索系统的缩减版骨架。

4.5 重排与生成

重排阶段用 cross-encoder 对 query 和候选文本块逐一对打分。这里代码示意如下：

from sentence_transformers import CrossEncoder reranker = CrossEncoder("your-cross-encoder-model-name") def rerank(query, candidates, top_n=3): # candidates 是 [(idx, score)] 列表 pairs = [(query, chunks[idx]) for idx, _ in candidates] scores = reranker.predict(pairs) ranked = sorted(zip(candidates, scores), key=lambda x: x[1], reverse=True) return [(idx, float(score)) for (idx, _), score in ranked[:top_n]]

生成部分，我们预留一个接口函数调用大模型，你把它替换成任何一家模型服务的 SDK 或 HTTP 调用即可。这个位置刻意留白，是为了让你聚焦在 RAG 流程本身。

def ask_llm(prompt: str) -> str: # 在这里接入你的大模型服务商接口 # 例如通过 HTTP 请求或 SDK 调用，把 prompt 发送给模型，返回生成的文本 raise NotImplementedError("替换为实际大模型调用即可")

最终把检索、重排、生成串起来：

def rag_answer(question: str) -> str: # 1. 向量召回 v_hits = vector_search(question, top_k=30) # 2. 关键词召回 b_hits = bm25_search(question, top_k=30) # 3. RRF 混合 fused = rrf_fusion(v_hits, b_hits, top_n=15) # 4. 重排，最终只保留 3 条 final = rerank(question, fused, top_n=3) context_block = "\n\n".join( f"[{i+1}] {chunks[idx]}" for i, (idx, score) in enumerate(final) ) prompt = f"""你是企业知识库问答助手。请依据下面的资料片段回答用户问题。若资料无法支撑答案，请直接回复"资料中未找到相关信息"。 资料片段： {context_block} 用户问题：{question} 请你结合资料片段给出准确回答，并在句末用 [编号] 标注来源。 """ return ask_llm(prompt)

这套代码是一个完整的最小实现。把占位模型名换掉、把 ask_llm 接到你的模型接口上，就可以跑起来。

4.6 离线评测：别凭感觉调参

RAG 系统最忌讳"感觉好就上线"。我在项目里至少会建两套评测数据。

第一套是检索评测集，格式是"问题 -> 应该命中的文本块编号"。跑完检索后计算命中率，看正确块有没有进 final 列表。第二套是回答评测集，每个问题配参考答案，用一个大模型作为裁判打分，或者直接人工审核。评测维度通常包括：准确性、完整性、是否包含无关信息、引用是否对应。

我自己的经验指标配置大概是这样：

没有评测集之前，所有调参都是盲人摸象。建立评测集虽然是脏活累活，但它是整个项目能持续迭代的基础。

5. 踩坑实录：切分粒度、上下文注入与幻觉回归

5.1 切分粒度的两难：太碎掉上下文，太长稀释相关性

我处理过一份某设备的维护手册，按章节切块，每块 3000 多字符，结果用户问"柜内温度传感器异常时先检查什么"，召回的是整个章节，包含大量安装背景，模型生成的回答被无关内容带偏。后来我把块调小到 400 字符，又发现问题：召回片段里出现"该设备"时，因为没有前文，模型根本不知道"该设备"指什么。

这个两难问题的解法不是死磕一个万能 chunk_size，而是要引入结构和父子信息。更合理的做法是：先按章节拆出"父块"，再在父块内部按段落或固定长度拆出"子块"。检索时在子块上做匹配，但如果命中的子块来自某个父块，可以同时把父块或相邻子块一并提供给模型，保持上下文完整。这种"粗块定位、细块召回"的设计，工程上叫父子切分，实战中非常有效。

另外一个容易踩的坑是切分与嵌入模型的 token 上限不匹配。如果嵌入模型最长支持 512 个 token，你却切了 1000 个字符的块，超出部分会被截断，等于向量只编码了前半截信息。设置 chunk_size 前，先查一下你的嵌入模型上限。

5.2 上下文注入模板的隐藏影响

prompt 模板对回答效果的影响，经常被低估。我做过一次对比：第一版模板写"请严格根据资料回答，不要使用你的既有知识"，模型变得极其保守，很多常识性问题也回"资料中未找到相关信息"，拒答率飙升；第二版模板写"请优先依据资料，资料缺失时可用你的知识补充"，准确率上来了，但幻觉也增加了，因为模型会在资料不支持的情况下补出模棱两可的内容。

折中方案是给模型分层授权：资料相关度高时，要求严格引用资料；资料明显不足时，先明确说"资料不足"，再客观说明。更细腻一点的指令是：不要模棱两可。模型最怕的是"尽力回答"这种指令——它会在没有依据的情况下尽力编造。宁可让它直接承认不知道，也不要让它给一个看似合理但不可信的答案。

5.3 幻觉回归：检索到了但生成错了

有一种幻觉非常隐蔽——知识库里明明有正确资料，模型在生成时却答错了。比如资料里写"系统默认超时时间为 30 秒"，用户问"系统超时时间怎么调"，模型却回答"超时时间为 60 秒，可在配置文件中调整"。

这类问题通常出在三个环节：一是上下文拼接时混入了其他相似但错误的内容，比如库里有多个版本的配置说明，新老版本同时被召回，模型选错了；二是 prompt 缺少"严格基于资料"约束；三是精排分数没有设置阈值，低质量上下文也被送进生成器。

排查思路是先把检索和生成拆开测：单独打印召回的三个片段，人工判断资料是否已经覆盖答案。如果召回正确而回答错误，问题在 prompt 或模型；如果召回本身就错误，问题在检索链路。常见做法是记录每次问答的检索片段和生成结果到日志，出现幻觉后回查日志，定位具体环节。

5.4 索引更新、缓存与降级

线上 RAG 系统除了算法问题，还有一堆工程问题。文档更新频繁时，最粗暴的做法是每天凌晨全量重建索引，数据量不大时完全够用。数据量大且更新频繁时，就需要增量入库：给每个文本块算一个内容 hash，入库前对比是否已存在；同时保留"文档 ID -> 块 ID"的映射，方便文档删除时连带删除对应的向量。

用 FAISS 做演示很方便，但要注意 FAISS 的 IndexFlatIP 和部分索引结构不支持删除单条向量。如果业务有频繁删除需求，建议换支持删除的向量库，或者在应用层做"软删除"——检索结果过滤掉已删除文档的块。这个细节看起来小，上线后遇到"删了文档还能搜出来"的投诉时，你会后悔没早处理。

缓存和降级同样不能忘。热点问题走缓存，能省下大量生成调用；向量库崩溃时，至少要能返回"当前知识库服务不可用"，而不是让用户面对一个 500 错误。降级的底线是：可以答不了，但不能瞎答。

5.5 权限过滤：企业落地绕不开的一关

企业内部知识问答如果没有权限控制，会出现灾难性事故。文档级别的权限通常记录在元数据里，检索时除了算相似度，还要加一道过滤条件：用户所属部门可见的文档范围、文档密级标签等。

更细的权限到段落级别时，单纯靠过滤已经不够，需要在入库前就区分密级块。我见过一个教训：某个系统的检索结果把一份内部薪资政策的摘要混进普通员工的上下文里，模型基于它回答了敏感问题，虽然没有直接泄露全文，但已经被安全团队约谈。做企业级 RAG，权限体系在第一天就要设计，而不是上线后再补。

6. 一点个人经验收尾

做了一轮 RAG 项目之后，我自己的体会是：这个技术架构的门槛不在代码，而在于你有没有把每个环节都当做一个可评测、可优化的独立模块。索引阶段偷的懒，会在检索阶段加倍还回来；检索阶段省掉的重排，会在生成阶段变成一本正经的胡话。整套系统里，检索质量决定上限，生成质量决定下限，prompt 模板决定稳定性，权限工程决定能不能上线。

最后再分享一个小技巧：每次调参不要只盯单条测试样本的效果，要固定一套评测集，批量跑分后再看分项指标。我在实际项目中没少因为"单条样例很完美"而误判整体效果，最后都是靠评测集拉回正轨的。RAG 的应用空间还在快速扩展，但核心逻辑没有变——让模型在正确的时间看到正确的资料。先把这一点做扎实，后面的优化才有意义。