企业官网建设流程全解析

RAG这个词这两年几乎被写烂了，但真正能把一套RAG问答从“能跑通demo”做到“能在业务里稳定用”的团队，比例真不高。这个项目八的定位是“实战进阶”，目标很明确：不教你怎么跑通第一个文档问答，而是围绕检索增强生成的全链路，把影响最终问答质量的细节拆开，逐个击破。它解决的核心问题是知识库问答里的三大顽疾——召不回、答不准、找不到出处；适合已经接触过大模型应用、想系统提升RAG问答可靠性和可维护性的开发者、算法工程师和AI产品负责人拿去做实战参考。

1. 为什么“进阶”意味着先从整体链路想清楚

1.1 RAG的本质：把外部知识变成模型可检索的“外挂记忆”

先回顾一个最简单的认知模型。大模型的知识来自训练阶段学会的统计规律，并且截止于训练数据的时间范围，它并不天然知道你的内部文档、产品手册、私有FAQ。RAG（检索增强生成）就是把这个短板补上的方案：一边是预训练模型，一边是外部知识库，问答时先检索相关片段，再让模型基于这些片段生成答案。

听起来很简单，但把“检索-增强-生成”三个词拆开，每个环节都有坑：检索要召回“对的”内容，增强要把“够用的”上下文送给模型，生成要遵守“只用资料、不许编造”的纪律。进阶实战的核心，就是把这几个词从概念变成可验收的工程。

1.2 从“跑通”到“可靠”，四个维度缺一不可

我见过不少团队的第一版RAG Demo效果不错，一到真实数据就崩。原因几乎一样：对数据端和检索端太随意。要进阶，必须从四个维度同时调整：

选这个方向不是拍脑袋，而是由问题类型决定的。在一个RAG链路里，答案质量的上限由检索到的上下文决定，生成模型只是在做“限题作文”。你不把前面的检索和数据做好，模型再怎么强也救不回来。这也是进阶实战先讲数据治理和检索优化的原因。

1.3 选型前先想清楚：你的场景更适合哪种RAG路线

有不少团队一上来就纠结向量库选哪个、模型选哪个，其实一开始就应该分清自己的场景：

• 如果你的知识库是结构化数据（销售记录、工单表），优先考虑查询改写加执行查询的方案，而不是纯文本RAG。
• 如果知识库是半结构化表格（产品规格、参数对照），应该把表格块也作为上下文来源，配合专门的格式解析，否则模型看到一串平铺文本根本对不上字段。
• 如果知识库是大量非结构化长文档（政策文件、技术手册），这才是典型RAG的用武之地，但也最考验分块和检索策略。

进阶项目的技术方案，应当围绕“你能拿到什么数据、用户会问什么问题”来定，先做场景判断再做功能选型，而不是看到一个热门框架就直接套上去。

2. 四个核心环节的实操细节，决定最终答案质量

2.1 数据准备与清洗：RAG最容易出效果也最容易被低估的环节

我做过不少RAG项目，发现最常见的错误是拿PDF直接切块，切完就入库。实际效果差的原因是文档里混着页眉页脚、目录、表格折行、多栏排版，切出来的块大量是噪音。

实操时建议按这个顺序处理：

1. 先做文档解析，把PDF、Word、Markdown、网页正文统一转成带结构标记的文本，表格单独转成Markdown表格或JSON格式，不要混在正文里。
2. 再做清洗，去掉导航、重复页眉、页码、无意义字符，对英文单词换行连字符做还原，对中文标点统一全半角。
3. 最后做分块。固定长度分块简单但容易切断语义；递归字符分块在多数文本上表现稳定；语义分块（按段落、标题、列表结构切）长文档效果更好，但要小心计算成本。

分块参数有一个可以默认起步的经验值：中文场景建议块大小控制在256到512个token，重叠窗口设在30到80个token。为什么要有重叠？因为一个语义完整的句子可能正好被分块边界切断，重叠部分就是给检索留的“缓冲带”。块太大，嵌入向量会被无关内容稀释，检索精度下降；块太小，上下文不完整，模型推理缺少前提。

提示：分块这事没有绝对的“最优”，它和你的知识库文本特征强相关。产品文档适合按章节语义切，新闻资讯适合按时间段落切，所以不要照搬某个项目的参数，先在你的抽样数据上跑一遍检索命中率测试。

2.2 向量化与索引构建：Embedding质量和索引参数比想象中更关键

Embedding模型负责把文本转成向量，这一步的语义映射质量直接决定“问什么能否召回到什么”。选型时优先考虑三点：

• 是否适合你的语言域：中文业务文档优先选中文效果好的Embedding模型或支持中英双语的服务。
• 维度与规模：维度太高、数据量太大时，存储和检索成本都会上升，需要做量化或压缩索引。
• 是否可微调：垂直领域可以通过少量数据继续训练Embedding，让领域词汇的语义更贴近实际。

索引构建方面，懂一点原理很有用。Flat索引就是全量暴力计算，数据量小的时候精度最高，但量大了之后延迟不可接受。HNSW是一种图结构近似索引，精度和速度的平衡最好，是大多数进阶项目的默认选择，但要注意它的内存占用。IVF属于聚类倒排，速度快、内存可控，但参数调不好时召回率会掉。实操上，数据量在百万级以内时，用HNSW搭配余弦距离或点积距离，基本够用。

向量库选型不用被品牌带偏，核心看三点：是否支持你要的检索语法、是否方便管理元数据和过滤条件、是否有清晰的备份和数据迁移方案。数据量小可以直接用本地开源方案；数据量大、并发高的时候再考虑独立向量数据库服务。

2.3 混合召回与重排：从Top-k里选出真正有用的一段

单纯走向量召回，在遇到专有名词、编号、精确数字时经常翻车。因为向量检索擅长语义相似，但不擅长词面完全匹配。进阶方案一般会做“混合召回”：一路是向量召回，另一路是关键词召回（经典BM25或更现代的稀疏检索），然后把两路结果融合。

融合我建议先用最直观的RRF方法。给两路结果按排名位置打分，合并相同的片段再按总分排序。这个做法的好处是简单、稳定、不需要额外调权。融合之后通常还要做重排：用一个轻量的精排模型逐个计算“问题-片段”相关度分数，把最相关的那几个片段排到最前面。

参数上可以记录一组我常用的起步值：召回阶段取得多一些，比如向量和关键词各取50个，融合去重后取前20个，再让重排模型从这20个里精排，最后取前5到8个片段送入大模型。为什么要这么“浪费算力”？因为向量检索的Top-5通常包含大量近义但无关的片段，重排的作用就是用精度换准度，宁可多算一点，也要保证送进模型的上下文是真正相关的。

2.4 生成阶段控制：Prompt不是随便拼一段话

很多人最后一步只简单拼接问题与片段，效果自然不稳定。生成阶段有几个容易被忽略的细节：

一是Prompt要明确“资料边界”。不能只写“根据提供的资料回答”，要写得再具体：只允许使用片段中的信息来回答；如果片段中没有相关信息，直接说明该问题不在资料覆盖范围内，不要自行补全。

二是引用溯源。要求模型在答案对应的句子末尾标注来源片段编号，这样用户能看到“答案来自哪里”，一旦出错也方便排查是哪段资料误导了模型。这项能力看似简单，实际上很多模型没有严格遵循，需要不断调整Prompt并观察输出。

三是生成参数。问答场景一般把temperature设在0.1到0.3之间，减少随机性；max_tokens要按答案长度控制，避免生成过于冗长；如果业务是客服类场景，还要额外加拒答模板和语气约束。

四是多轮对话的query改写。用户追问“那价格呢”时，直接把这句话丢去检索肯定召回不到内容。先在对话历史基础上做一次问句补全，把“那价格呢”改写成“产品X的当前价格是多少”，再去检索，命中率会明显提升。

3. 实操过程：搭一套可复现的RAG问答链路

3.1 环境准备与数据Demo选择

为了演示，我用一个虚构的产品手册当知识库。这个手册包含三章内容：安装说明、配置参数、常见故障处理，格式是Markdown，符合大多数业务文档的形态。

环境准备主要做三件事：建一个Python虚拟环境，安装向量库驱动、文本解析库和HTTP请求库；准备一个Embedding接口和一个LLM接口，开发调试阶段用模拟接口也可以先跑通链路；准备一份评估测试集，至少包含20个覆盖不同章节的问题，标记对应的标准答案和来源章节，这一步后面评估要用。

3.2 离线索引构建：文档怎么变成向量库里的记录

离线流程的伪代码如下，核心是“解析-清洗-分块-向量化-入库”五步：

def build_knowledge_index(): docs = parse_docs(["manual_install.md", "manual_config.md", "manual_faq.md"]) cleaned = [clean_text(doc) for doc in docs] chunks = split_into_chunks(cleaned, chunk_size=384, overlap=64) embeddings = embed_batch([c["content"] for c in chunks]) records = [] for idx, (chunk, emb) in enumerate(zip(chunks, embeddings)): records.append({ "id": idx, "content": chunk["content"], "source": chunk["source"], "chapter": chunk["chapter"], "embedding": emb, }) vector_store.add(records) return len(records)

这段逻辑里，最容易被忽略的是记录元数据。我建议至少保留source、chapter、chunk_id这三个字段。为什么呢？第一，只有拿到了source，生成阶段才能做引用溯源；第二，后续要按章节过滤或聚焦某一类问题时，元数据是过滤条件；第三，定位问题的时候，没有来源信息你只能面对一堆向量，根本没法人工复核。

入库之后要做一次“冒烟测试”：从测试问题里挑几个，手动跑一遍检索，看看相似度最高的前5条是不是真的和问题相关。如果这一步就不相关，后面调Prompt完全没有意义。先保证“检索能中靶”，再谈生成质量。

3.3 在线问答链路：检索、融合、重排、生成一气呵成

在线链路的伪代码如下：

def answer_question(user_question, history=None): rewritten = rewrite_query(user_question, history) if history else user_question vector_hits = vector_store.search(embed_query(rewritten), top_k=50) keyword_hits = keyword_store.search(rewritten, top_k=50) fused = reciprocal_rank_fusion(vector_hits, keyword_hits) truncated = fused[:20] reranked = rerank(rewritten, truncated)[:6] context = build_prompt_context(reranked) answer = ask_llm(rewritten, context, with_citation=True, temperature=0.2) return answer

有几个细节在写代码时要特别注意。第一，检索时拿到的相似度分数在融合过程中尽量不要直接相加，因为向量分数和关键词分数的量纲不同，前面说的RRF用排名做积分，就是为了规避量纲问题。第二，构建Prompt上下文时，每段前面加一个编号和来源标记，例如“[1]（来源：配置手册第四章）”，这样模型在做引用时才有“锚点”可循。第三，多轮对话时建议先更新历史，再改写问题，顺序反了容易把追问改写成自问自答。

3.4 效果评估：用可量化的指标取代“感觉不错”

进阶和原型的最大差别就是有没有评估。我建议至少记录四组指标：

• 检索命中率：标准答案对应的片段是否出现在召回的Top-10中。
• 答案相关性：模型给出的回答和真实问题的匹配程度，可以用人工打分或大模型裁判来粗筛。
• 引用准确率：回答中的引用编号是否真的指向包含答案的片段，尤其警惕“引了但没答到点子”的情况。
• 幻觉率：回答中出现了知识库中没有的信息的比例，这是最需要收敛的指标。

开发阶段可以先构造20到30条人工测试集，每次调整后跑一遍，看指标变化。等基础跑通了，再引入自动化评估框架，比如基于“忠实度、上下文相关度、答案相关度”这类指标体系的评测工具，但要先把人工测试集当基线管住。没有基线的优化都是盲人摸象，跑了三个月可能还不知道是哪个改动让效果变好或变坏的。

4. 真实踩坑记录：常见问题与排查技巧

4.1 知识库明明有答案，检索却召不回原片段

这是最常见也最让人头疼的问题。原因通常有三个：

1. 文档解析阶段丢字严重，片段被切碎或串行。排查方式很直接：到知识库后台或数据库里直接搜索标准答案中几个关键短语，看物理文件到底存进去没有。
2. 提问用词和文档用词差异太大，向量相似度上不去。这时要靠混合检索中的关键词路来兜底，或者对专有名词做同义词扩展。
3. 分块切断了关键信息。常见的解决方法是缩小块大小或加大重叠，让包含答案的整段话完整出现在某一个块里。

排查看起来像在查案，实际上只要把链路拆开定位：先在向量库里查，再在原始文档里查，最后比对是解析期、分块期还是检索期的责任，很快就能定位。

4.2 幻觉依旧存在：模型手里有资料却偏不按资料答

很多团队遇到这种问题，第一反应是换更大的模型，但效果往往有限。模型“不听话”，更多是生成阶段的约束没有做透。我通常会按顺序尝试：

• 把Prompt中的“资料边界”强调得更死：明确写成“如果资料中不存在，直接回答不知道，不要猜测”。
• 在答案里强制要求标注来源，将“必须有信息来自[]编号”写进输出格式，让模型必须依赖上下文。
• 把temperature降到更低，或对固定格式的答案使用结构化输出，发现输出里没有引用就请求重答一次。
• 检查送进模型的上下文是否真的包含了正确答案。如果重排后把正确的片段排掉了，模型当然答不出来。

另外要从产品层面设计“拒答”能力。资料未覆盖的问题，让模型坦白说不知道，比编造一个错误答案更符合业务需要。这在客服类场景里尤其重要。

4.3 上下文太长：六个片段拼起来直接顶爆模型窗口

把Top-5片段全拼进Prompt，片段一长就会触发超长截断，结果反而是中间最相关的部分被截掉了。这个问题有两个解决思路：

一是控制片段数量和长度。重排后只保留5到8个片段，并且每个片段截断到一定长度。做引用时最好别让模型输出完整长文，引导它先答要点再展开。

二是做“上下文压缩”：先让一个轻量模型把多个长片段压缩成一段关键信息摘要，再把摘要送给主模型。压缩有损，所以更推荐第一种方案先控制输入规模。

4.4 检索量变大后响应变慢：延迟优化三板斧

数据量大了之后，检索从几十毫秒涨到几百毫秒甚至更久，用户体感会非常明显。优化顺序是：

• 第一板斧是索引参数优化。近似索引的查询参数调大之后耗时可以下降不少，但要保留足够的召回数供重排使用。
• 第二板斧是增加检索缓存。高频问题把检索结果或完整答案缓存下来，同一问题短时间内重复命中直接返回结果。
• 第三板斧是批量化和异步化。在线请求中把向量检索、关键词检索并行发出，不要串行等待；离线文档更新时，增量索引比全量重建便宜一个数量级。

整理成速查表：

4.5 多轮对话中丢失上下文，一问一答就“失忆”

除了单轮问答，进阶实战往往会遇到多轮场景。直接拿上一轮回答拼进Prompt，不但容易超长，还会在检索时产生干扰。我的做法是维护一个轻量对话记忆：把每轮改写后的Query、检索到的片段ID、模型答案压缩成一段摘要，下一轮使用时只把摘要和当前问题一起处理，这样既保留了上下文，又不至于让整段历史干扰检索结果。

这个项目做下来，我最大的体会是：RAG进阶的瓶颈从来不是模型能力，而是工程细节的把控能力。每个看似微小的分块参数、召回数量、Prompt措辞，都可能让最终效果产生很大的波动。所以我建议把调试过程日志化，每一版改动都跑同一套测试集，记录指标变化；不然很容易陷入“调了一下午，结果第二天下班又倒退”的循环。最后再说一个小技巧：调试时不要只看最后生成的答案，把每一步的输入输出都留痕，尤其是检索命中的片段、重排后的顺序，这两处的日志价值比答案本身高得多。希望这篇实战记录能帮你在自己的RAG项目里少踩几个坑。