企业官网建设流程全解析

1. 为什么知识获取管道是 AI Agent 落地的第一道坎

做 AI Agent 的人迟早会撞上一堵墙：模型本身很聪明，但你问它公司内部的报销标准、上周刚更新的产品参数、某个客户的特殊约定，它要么一本正经地胡说，要么干脆告诉你“我不知道”。这不是模型不行，而是它的知识被冻结在训练那一刻，而你的业务知识每天都在变。知识获取管道要解决的，就是让 Agent 在回答问题之前，先去“查资料”，把外部知识动态喂给模型。这套机制里最主流、最成熟的一条路线，就是 RAG，也就是检索增强生成。

我先把话说在前面：RAG 不是把文档丢进向量库就完事了。我见过太多项目，demo 阶段效果惊艳，一上真实数据就翻车——检索命中率低、答非所问、引用来源对不上。问题几乎都出在管道设计上，而不是模型选型上。这篇内容我会把 RAG 这条知识获取管道从头拆到尾，讲清楚每个环节为什么这么设计、参数怎么定、坑在哪里。适合正在搭 AI Agent、准备做企业知识库、或者已经踩过 RAG 坑想回头补基础的开发者。读完你应该能自己从零搭一条能用的管道，而不是只会调一个现成框架。

RAG 的核心价值可以用一句话概括：把“记忆”从模型参数里剥离出来，交给一个可随时更新、可追溯、可审计的外部知识源。这对企业场景尤其关键，因为业务知识是资产，不能锁在黑盒模型里。理解了这一点，后面所有的设计取舍都会顺理成章。

2. RAG 整体架构与核心思路拆解

2.1 一条完整的知识获取管道长什么样

很多人对 RAG 的理解停留在“向量检索 + 拼 prompt”，这只是一半。一条真正能上生产的管道，至少包含五个阶段：文档接入、切分与清洗、向量化与索引、检索与重排、生成与引用。每个阶段都有独立的失败模式，任何一个环节拉胯，最终答案都会崩。

我用一个生活化的类比帮你建立整体印象。把 RAG 想象成一个图书馆的参考咨询服务。文档接入是采购新书，切分是给书编页码和章节，向量化是给每段内容贴主题标签，检索是读者提问后管理员去书架上找相关段落，重排是把找到的一堆段落按相关度排序，生成是管理员读完这些段落后用自己的话回答你。如果采购的书是盗版乱码，或者章节切得七零八落，或者标签贴错了，后面再厉害的管理员也答不好。

提示：RAG 的效果上限由检索质量决定，而不是由生成模型决定。检索没找到正确内容，再强的模型也只能编。

2.2 为什么是 RAG，而不是微调或长上下文

这里必须解释清楚方案选型。面对“让模型掌握私有知识”这个需求，常见有三条路：微调、长上下文塞入、RAG。微调是把知识写进模型权重，成本高、更新慢，而且知识一变就得重训，还容易灾难性遗忘；长上下文是把所有资料一股脑塞进 prompt，token 成本爆炸，且模型在超长上下文里对中间部分的注意力会衰减，俗称“lost in the middle”；RAG 则是按需检索，只把最相关的片段喂给模型，成本可控、更新即时、来源可追溯。

我实测下来的结论是：知识频繁变动、需要引用出处、数据量大的场景，RAG 是唯一务实的选择。微调更适合固定风格和格式的迁移，长上下文适合一次性分析一份长文档。三者不是互斥的，成熟系统往往是 RAG 打底，微调调风格，长上下文处理单文档深读。

2.3 稠密嵌入与稀疏检索的分工

热词里反复出现“稠密嵌入”，这是 RAG 检索的基石。稠密嵌入是把一段文本映射成一个高维向量，语义相近的文本在向量空间里距离近。它的优势是能理解同义表达——你问“怎么报销”，文档里写“费用核销流程”，它也能匹配上。但稠密检索有个短板：对精确的关键词、编号、专有名词不敏感。你搜“型号 XR-200”，它可能给你返回一堆语义相近但型号不对的内容。

所以生产级管道通常是混合检索：稠密向量负责语义召回，稀疏检索（如 BM25）负责关键词精确匹配，两路结果融合后再重排。这个组合能显著提升命中率，尤其是面对产品型号、法规条款、人名这类需要精确匹配的场景。别小看这一步，很多 RAG 项目命中率上不去，就是因为只用了稠密检索。

3. 核心环节的细节解析与实操要点

3.1 文档切分：最容易被低估的环节

切分策略直接决定检索质量，但它是被最多人敷衍的一步。常见错误是按固定字符数硬切，比如每 500 字一刀。这样切出来的片段经常在句子中间断开，语义不完整，向量化后标签就是模糊的。

我的做法是分层切分：先按文档结构（标题、章节、段落）切，再对超长段落按语义边界切。具体参数上，片段长度控制在 300 到 800 个 token 之间，重叠区留 10% 到 15%。为什么要有重叠？因为答案可能正好跨在两个片段的边界上，重叠能保证至少有一个片段包含完整信息。为什么不能太长？片段越长，向量里混入的无关信息越多，语义就越“糊”，检索精度下降。

# 基于标题层级和语义边界的切分示意 def split_document(doc, max_tokens=600, overlap_ratio=0.12): sections = split_by_heading(doc) # 先按标题切 chunks = [] for sec in sections: if count_tokens(sec) <= max_tokens: chunks.append(sec) else: # 超长段落按句子边界聚合，保留重叠 chunks.extend(split_by_sentence(sec, max_tokens, overlap_ratio)) return chunks

注意：切分时一定要保留元数据，比如来源文件名、章节标题、页码。这些元数据在检索过滤和答案引用时是刚需，丢了后面补不回来。

3.2 向量化与索引：模型选择和参数取舍

嵌入模型的选择直接决定语义匹配能力。中文场景我一般优先考虑在中文语料上表现好的模型，而不是盲目用英文榜单第一的。选型时看三个指标：检索命中率、向量维度、推理速度。维度不是越高越好，高维向量存储和检索成本都更高，768 到 1024 维在多数场景已经够用。

索引方面，数据量小的时候用扁平索引暴力检索就行，简单可靠。数据量上到十万级以上，就得上近似最近邻索引，比如 HNSW。HNSW 有个关键参数 ef_search，控制检索时的搜索范围，值越大召回率越高但越慢。我通常从 64 起步，根据命中率实测往上调。

3.3 检索与重排：把正确内容捞上来

检索阶段我强烈建议上混合检索。稠密检索召回语义相关片段，稀疏检索召回关键词精确匹配片段，两路各取前 20 到 50 条，用 RRF（倒数排名融合）合并。RRF 的好处是不需要调权重，对两路结果的排名做倒数求和，稳健且好实现。

合并之后是重排。重排模型（reranker）会对候选片段和 query 做精细的相关度打分，把真正相关的顶到前面。这一步是提升命中率性价比最高的操作，通常能把 top-3 命中率拉高十几个百分点。重排后只保留 top 3 到 5 条喂给生成模型，既控制 token 成本，又减少噪声干扰。

# 混合检索 + RRF 融合 + 重排的流程示意 dense_hits = dense_search(query, top_k=30) sparse_hits = bm25_search(query, top_k=30) fused = rrf_merge(dense_hits, sparse_hits) # 倒数排名融合 reranked = reranker.rerank(query, fused[:20]) # 精细重排 final_context = reranked[:4] # 取前4条进生成

3.4 生成与引用：让答案可信可追溯

生成阶段的 prompt 设计有讲究。我通常要求模型严格基于给定上下文回答，上下文里没有的信息就明确说“资料中未提及”，禁止自行发挥。同时要求它标注引用来源，比如“根据《报销制度》第 3 章”。这样用户能核对，也方便排查检索问题。

温度参数建议调低，0 到 0.2 之间，减少随机性。对于需要严谨的场景，可以让模型先输出推理依据再给结论，但要注意这会增加 token 消耗。引用格式最好在 prompt 里给一个明确示例，模型对格式的遵循度会高很多。

4. 从零搭建一条可用的 RAG 管道

4.1 环境准备与依赖选型

搭建之前先明确技术栈。Python 生态里，LangChain 和 LlamaIndex 是两条主流路线，前者灵活、组件多，后者对 RAG 场景封装更贴心。如果你用 Java 技术栈，LangChain4j 和 Spring AI 都能做，Spring AI 对 Spring 生态集成更顺。选哪个不重要，重要的是理解管道每一环在干什么，别被框架的黑盒遮住眼睛。

依赖上，向量库可以选本地轻量的方案先跑通，比如 FAISS 或 Chroma，生产再换分布式向量库。嵌入模型和重排模型可以先用开源方案本地跑，验证流程后再考虑托管服务。我的建议是先用最小依赖把端到端跑通，再逐步替换组件，不要一上来就堆一整套重型架构。

4.2 端到端流程实现

第一步，文档接入。把 PDF、Word、Markdown、网页等格式统一解析成纯文本，保留结构信息。PDF 解析是重灾区，扫描件要 OCR，双栏排版容易串行，表格容易丢结构。这一步的清洗质量直接决定后面所有环节的上限。

第二步，切分与元数据标注。按前面讲的策略切分，每个片段带上来源、章节、页码等元数据。

第三步，向量化入库。批量调用嵌入模型，把片段转成向量写入向量库，同时把原文和元数据存进关系库或文档库，检索时按 ID 关联。

第四步，检索服务。实现混合检索、融合、重排，封装成一个检索接口，输入 query 输出 top 片段列表。

第五步，生成服务。把检索结果拼进 prompt，调用生成模型，返回带引用的答案。

# 端到端主流程示意 def rag_pipeline(query): candidates = hybrid_retrieve(query) # 混合检索 context = rerank_and_truncate(candidates) # 重排截断 prompt = build_prompt(query, context) # 构造带引用的prompt answer = llm.generate(prompt, temperature=0.1) return answer, extract_citations(context)

4.3 参数计算与调优记录

调优要有据可循，不能凭感觉。我一般先准备一个评测集，几十到上百条真实问题，每条标注正确答案所在的文档片段。然后测三个指标：召回率（正确片段有没有被检索到）、命中率（正确片段有没有进 top-k）、答案准确率（最终答案对不对）。

调参顺序上，先调切分粒度，再调检索 top-k，最后调重排截断数量。切分粒度对召回率影响最大，top-k 影响命中率，截断数量影响生成质量和成本。我实测的一个经验值是：切分 500 token、混合检索各取 30、重排后取 4 条，在多数企业知识库场景下能取得不错的平衡。但这个值不是万能药，一定要用自己的数据实测。

提示：评测集是 RAG 调优的命根子。没有评测集，你所有的“感觉变好了”都是幻觉。

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

5.1 检索命中率低的排查路径

命中率低是最常见的问题。排查顺序我总结成一张表，从上往下逐层排除。

我踩过最深的坑是切分。有一次文档按固定长度切，答案正好被切成两半，两半单独看语义都不完整，检索死活召不回。后来改成按语义边界切加重叠，问题立刻消失。所以遇到命中率问题，先怀疑切分，别急着换模型。

5.2 答案胡编与引用错位

答案胡编通常是两个原因：检索没找到正确内容，模型只能编；或者 prompt 没约束好，模型自由发挥。前者回到检索排查，后者要在 prompt 里明确“只依据上下文回答”。引用错位则多半是元数据没传对，或者模型把引用编号搞混了。我的做法是让模型引用片段时直接输出片段 ID，后端再映射回真实来源，避免模型自己编来源名。

5.3 性能与成本优化

RAG 的延迟主要花在嵌入、检索和生成三处。嵌入可以缓存，相同 query 直接命中缓存。检索的瓶颈在向量库，索引选型和参数调优能显著降延迟。生成是最大头，控制上下文长度和输出长度最有效。成本上，重排模型和生成模型是主要开销，重排候选数量别设太大，生成上下文别塞太多片段，够用就行。

注意：不要为了省钱把 top-k 压到 1 或 2，召回不足导致的错误答案，代价远高于多检索几条的成本。

5.4 知识更新与增量索引

业务知识天天变，管道必须支持增量更新。我的做法是给每个片段一个内容哈希，文档更新时只重新处理变化的片段，没变的复用已有向量。删除文档时同步删除对应向量和元数据，避免“幽灵知识”污染检索结果。定期做一次全量重建，清理碎片和过期内容。

6. 进阶方向与个人实践体会

RAG 基础管道跑通之后，还有不少可以深挖的方向。比如 GraphRAG，把知识图谱和向量检索结合，处理需要多跳推理的问题；比如 Agentic RAG，让 Agent 自己决定检索几次、检索什么、要不要改写 query，适合复杂查询场景；再比如把 RAG 和技能系统结合，让 Agent 在调用工具前先检索相关操作说明。这些方向都建立在基础管道扎实的前提上，基础不牢，上层越花哨越容易崩。

我在多个项目里反复验证的一点是：RAG 的成败八成在数据工程，两成在模型。文档解析、切分、元数据、评测集，这些“脏活累活”才是决定效果的关键。很多人把精力全花在换模型、调框架上，结果数据一塌糊涂，怎么调都上不去。反过来，数据管道做扎实了，哪怕用中等模型，效果也能打得过数据稀烂的顶配方案。

最后分享一个我常用的小技巧：在检索结果里保留片段的上下文邻居。也就是命中某个片段时，把它前后相邻的片段也一起带上，但标记为“扩展上下文”。这样能缓解切分导致的语义断裂问题，让生成模型看到更完整的语境，实测对答案连贯性有明显帮助。这个技巧成本很低，但收益很实在，值得一试。