企业官网建设流程全解析

1. 为什么我要把整套 RAG 智能体技术体系归档成一份永久查阅文档

过去一年多，我陆陆续续做了七八个 RAG 智能体项目，从最早用 LangChain 拼一个“能问答的 Demo”，到后来给销售团队做线索跟进智能体、给内部制度做条例学习助手、给 ERP 做产品语义检索，中间踩的坑多到能写一本小册子。最让我头疼的不是某个技术点难，而是知识散：今天在某个项目里调通了一个检索策略，过两个月换个项目又得从头翻聊天记录、翻旧代码、翻当时写的临时笔记。于是从去年下半年开始，我强迫自己把 RAG 智能体全栈开发涉及的所有环节——从文档解析、切分、向量化、检索、重排、编排、评估到部署——整理成一份可以永久查阅的归档文档。这份文档不是教程，更像是我自己的“作战手册”，今天把它整理出来，希望能帮到同样在做 RAG 智能体全栈开发的朋友。

先说清楚这份归档文档适合谁看。如果你是完全没接触过 RAG 和智能体的小白，它能帮你建立一套完整的认知地图，知道一个能上线的 RAG 智能体到底由哪些部分组成；如果你已经能跑通简单的 RAG 问答，但总觉得效果不稳定、不知道从哪优化，它能给你一套排查和调优的框架；如果你是团队里负责智能体项目落地的工程师，这份文档里的选型对比、参数计算、评估方法可以直接拿去用。核心关键词 RAG、智能体、全栈开发、技术体系、归档文档，会贯穿整篇内容，我不会只讲概念，而是把每个环节的“为什么这么选”和“具体怎么做”都摊开说。

我见过太多人一上来就纠结用哪个向量数据库、用哪个框架，结果连文档切分都没做对，检索出来的内容驴唇不对马嘴，然后回头怪模型不行。这份归档文档的第一个价值，就是帮你把顺序理清楚：先搞清楚数据长什么样，再决定怎么切、怎么存、怎么检、怎么编排、怎么评。顺序错了，后面全是返工。下面我按我自己归档时的结构，从整体设计思路开始，一层一层拆开讲。

2. RAG 智能体全栈体系的整体设计与思路拆解

2.1 先想清楚：RAG 智能体到底解决什么问题

很多人把 RAG 和智能体混在一起说，其实两者解决的是不同层次的问题。RAG 解决的是“大模型不知道你私有数据”的问题，它通过检索外部知识来给模型补充上下文；智能体解决的是“大模型只会说不会做”的问题，它通过工具调用、任务规划、多步执行来完成一个目标。把两者合在一起，就是RAG 智能体：它既能查你的知识库，又能根据查到的内容决定下一步做什么，比如查完制度条例后自动生成一份学习提纲，或者查完产品参数后自动填进报价单。

我在归档文档里把 RAG 智能体的能力拆成四层：感知层负责接收用户输入和文档输入；知识层负责存储和检索私有知识；编排层负责决定什么时候检索、检索几次、检索完怎么用；执行层负责调用工具、生成最终输出。这四层缺一层，智能体就不完整。很多 Demo 只做了感知层和知识层，所以只能问答，不能干活；有些智能体只做了编排层和执行层，没有知识层，所以一问专业问题就胡编。全栈开发的意思，就是这四层你都得管。

2.2 方案选型背后的核心考量

归档文档里我专门用了一节记录选型逻辑，因为选型错了后面很难改。先说框架选型。LangChain 生态最全，但抽象层多，调试起来经常要翻源码；LangChain4j 对 Java 团队友好，Spring AI RAG 适合已经在用 Spring 体系的项目；AgentScope 2.0 这类偏多智能体编排的框架，适合需要多个智能体协作的场景。我的经验是：如果只是单智能体加知识库，别上太重的框架，直接用原生 SDK 加一个向量库客户端，代码量可能更少、更好控。框架的价值在多智能体协作、复杂工作流、统一评估这些场景才真正体现。

再说向量库选型。本地知识库场景，Chroma 和 FAISS 足够，部署简单、零依赖；要上生产、要支持多租户和元数据过滤，Milvus 或 Qdrant 更合适；如果已经在用 PostgreSQL，pgvector 是最省事的选择，不用额外维护一套存储。归档文档里我列了一张选型对照表，把部署成本、过滤能力、扩展性、社区活跃度都标出来，方便下次直接查。

最后说模型选型。Embedding 模型决定了检索的上限，生成模型决定了回答的下限。我的做法是：Embedding 用专门的中文检索模型，生成模型用通用大模型，不要指望一个模型既做检索又做生成。DeepSeek 公开的智能体训练新方法里也提到，检索和生成解耦后，各自优化空间更大。这个思路我在多个项目里验证过，检索召回率能提升十几个百分点。

2.3 为什么我要做“归档”而不是“教程”

教程是线性的，归档是网状的。实际做项目时，你不会按教程顺序遇到问题，而是检索效果不好时回头查切分，切分没问题时回头查 Embedding，Embedding 没问题时回头查重排。归档文档的价值在于每个环节都能独立查阅，又能通过交叉引用快速跳转。我在文档里给每个模块都标了“上游依赖”和“下游影响”，比如“切分策略”的上游是“文档解析”，下游是“向量化和检索”，这样排查问题时能顺着链路走，不会漏掉环节。

另外，归档文档必须记录失败案例。我专门留了一节写“那些年我踩过的坑”，比如用固定长度切分把一张表格切成两半，导致检索时永远只能召回半张表；比如重排模型和 Embedding 模型不匹配，重排后反而把正确结果排到后面。这些失败案例比成功经验更有参考价值，因为成功往往有运气成分，失败的原因却高度重复。

3. 核心细节解析与实操要点：从文档到检索的完整链路

3.1 文档解析：别让脏数据毁掉整个知识库

文档解析是 RAG 全栈开发里最容易被低估的环节。我见过太多项目直接拿 PDF 丢给解析库，出来一堆乱码和断行，然后怪检索不准。归档文档里我把文档解析拆成三步：格式识别、内容提取、结构还原。

格式识别决定用什么解析器。纯文本和 Markdown 最好办，直接读；PDF 要区分是文本型还是扫描型，文本型用 pdfplumber 或 PyMuPDF，扫描型必须走 OCR；Word 和 HTML 要保留标题层级和表格结构；Excel 和 CSV 要按行或按 sheet 处理。我的经验是：不要用一个解析器打天下，按格式路由到不同解析器，虽然代码多一点，但数据质量高很多。

内容提取阶段要处理页眉页脚、水印、乱码、断行。页眉页脚通常有固定模式，可以用正则批量去掉；水印如果影响文字识别，要在 OCR 前做图像预处理；断行问题最麻烦，中文 PDF 经常把一句话拆成多行，我的做法是用标点符号和语义连贯性做合并，比如上一行结尾没有句号、下一行开头不是标题，就合并成一段。

结构还原是很多人忽略的一步。文档里的标题、列表、表格、代码块，都是重要的结构信息。标题能帮我们做层级切分，表格能帮我们做结构化检索，代码块能帮我们做精确匹配。归档文档里我要求每个解析后的文档块都带上结构标签，比如heading_level、is_table、is_code，这样后续切分和检索时能按结构做差异化处理。

注意：文档解析阶段一定要保留原文的元数据，比如来源文件名、页码、章节号。这些元数据在检索时能做过滤，在回答时能做引用，没有它们，智能体就是个“黑盒”。

3.2 切分策略：固定长度是起点，语义切分才是终点

切分策略直接决定检索粒度。切得太碎，上下文不完整，模型回答缺信息；切得太粗，检索精度下降，召回一堆无关内容。归档文档里我记录了四种切分策略的适用场景：

我的实操建议是：先用递归切分跑通链路，再针对问题文档做结构切分。比如制度条例学习助手这个项目，制度文档有明确的章节和条款，我就按“章-节-条”做结构切分，每个条款作为一个块，检索时直接命中条款，回答时也能精确引用条款号。而产品检索场景，产品参数是表格，我就按行切分，每行带上产品名和参数名，检索时用“产品名+参数名”做组合查询。

切分块的大小也有讲究。归档文档里我记了一个经验公式：块大小 = 平均段落长度 × 1.5，重叠 = 块大小 × 0.15。比如平均段落 200 字，块大小设 300 字，重叠 45 字。这个公式不是绝对的，但能帮你快速定一个起点，再根据检索效果微调。重叠的作用是防止关键信息刚好被切在边界上，但重叠太大又会造成冗余，0.1 到 0.2 之间比较平衡。

3.3 向量化与索引：Embedding 模型不是越贵越好

向量化是把文本块转成向量，存进向量库。归档文档里我重点记了两件事：Embedding 模型怎么选，索引怎么建。

Embedding 模型选型要看三个指标：检索召回率、向量维度、推理速度。召回率是核心，但不要只看榜单，要用你自己的数据做小规模测试。我的做法是：准备 50 到 100 个“问题-正确块”对，用不同 Embedding 模型跑一遍，看正确块在 Top5 里的命中率。维度方面，768 维和 1024 维在实际检索中差距不大，但 1024 维的存储和计算成本更高，如果数据量不大，768 维够用。推理速度方面，本地部署的模型要考虑 GPU 显存，API 调用的模型要考虑并发限制。

索引方面，向量库通常支持多种索引类型，比如 HNSW、IVF、Flat。Flat 是暴力检索，精度最高但速度最慢，适合小数据量；HNSW 是图索引，速度快、精度高，适合中等数据量；IVF 是倒排索引，适合大数据量但需要调参。我的经验是：数据量在 10 万块以内，直接用 HNSW，别折腾 IVF。HNSW 的参数M和efConstruction影响精度和速度，M越大精度越高但内存占用越大，一般设 16 到 32；efConstruction越大建索引越慢但精度越高，一般设 100 到 200。

提示：向量库的元数据字段要提前设计好。来源、页码、章节、结构标签、时间戳，这些字段在检索过滤和结果引用时都会用到。元数据设计得好，后面做权限控制、时效过滤、多知识库隔离都轻松。

3.4 检索与重排：两阶段检索是标配

检索阶段的目标是“尽量召回”，重排阶段的目标是“尽量精准”。归档文档里我把检索拆成粗排和精排两阶段。粗排用向量检索，从知识库里召回 Top20 到 Top50 个候选块；精排用重排模型，对候选块重新打分，选出 Top3 到 Top5 给生成模型。

粗排阶段可以加混合检索，也就是向量检索加关键词检索。向量检索擅长语义匹配，关键词检索擅长精确匹配，两者结合能覆盖更多场景。比如用户问“RAG 是什么”，向量检索能召回语义相关的解释，关键词检索能召回包含“RAG”这个词的块，两者合并后去重，召回率明显提升。混合检索的权重可以调，我的经验是向量检索占 0.7，关键词检索占 0.3，具体看数据特点。

精排阶段用重排模型，比如 BGE Reranker 或 Cohere Rerank。重排模型比 Embedding 模型更重，但精度更高，因为它能同时看问题和候选块，做交叉编码。重排的 TopK 不要设太大，3 到 5 个足够，太多会引入噪声，也会增加生成模型的上下文长度。归档文档里我记了一个坑：重排模型和 Embedding 模型最好来自同一家族，比如都用 BGE 系列，否则打分尺度不一致，重排效果可能反而变差。

3.5 智能体编排：什么时候检索，检索几次

智能体编排是 RAG 智能体区别于普通 RAG 的关键。普通 RAG 是“一问一检索一回答”，智能体是“根据问题决定要不要检索、检索几次、检索完要不要调工具”。归档文档里我总结了三种编排模式：

单轮检索模式适合事实型问题，比如“制度第 12 条是什么”，检索一次就能回答。多轮检索模式适合复杂问题，比如“对比制度 A 和制度 B 的差异”，需要分别检索两个制度，再对比。工具调用模式适合需要外部数据的场景，比如“查一下这个产品的最新库存”，检索知识库后还要调库存接口。

编排的实现方式有两种：基于规则和基于模型。基于规则是用 if-else 判断问题类型，简单可控但不够灵活；基于模型是让大模型自己决定下一步，灵活但可能不稳定。我的做法是：核心流程用规则兜底，边缘情况用模型决策。比如先判断问题里有没有“对比”“分别”这类词，有就走多轮检索，没有就走单轮检索；如果模型在单轮检索后觉得信息不够，再触发补充检索。

AgentScope 2.0 这类框架在多智能体编排上提供了现成的通信和协调机制，适合需要多个智能体分工的场景。比如销售智能体项目里，我拆了“线索分析智能体”“产品推荐智能体”“话术生成智能体”三个角色，每个角色有自己的知识库和工具，通过消息传递协作。这种场景下，框架的价值就体现出来了，自己手写通信协议会很累。

4. 实操过程与核心环节实现：从零搭一个可用的 RAG 智能体

4.1 环境准备与依赖安装

归档文档里我要求每个项目都从干净的环境开始，避免依赖冲突。Python 项目用 conda 或 venv 建虚拟环境，Java 项目用 Maven 或 Gradle 管理依赖。核心依赖包括：文档解析库（pdfplumber、python-docx、beautifulsoup4）、向量库客户端（chromadb、qdrant-client、pymilvus）、Embedding 和重排模型（sentence-transformers、FlagEmbedding）、编排框架（langchain、langchain4j、agentscope）。如果要用本地模型，还要装 PyTorch 和 CUDA 对应版本。

我的习惯是：把依赖版本锁死，写进 requirements.txt 或 pom.xml。RAG 项目涉及的库多，版本不兼容是常见问题，锁版本能省很多排查时间。另外，Embedding 模型和重排模型如果本地部署，要提前下载好模型文件，放到固定目录，避免每次启动都重新下载。

4.2 知识库构建的完整流程

知识库构建分五步：收集、解析、切分、向量化、入库。收集阶段要把所有文档集中到一个目录，按类型分文件夹；解析阶段按格式路由到不同解析器，输出统一的结构化文本；切分阶段按文档类型选择切分策略，输出带元数据的块；向量化阶段用 Embedding 模型把块转成向量；入库阶段把向量和元数据一起写进向量库。

我以制度条例学习助手为例，走一遍完整流程。制度文档是 Word 格式，有章节和条款。解析时用 python-docx 读取，保留标题层级和条款编号。切分时按“章-节-条”做结构切分，每个条款作为一个块，元数据包括章节号、条款号、来源文件名。向量化用 BGE 中文模型，维度 768。入库用 Chroma，元数据字段包括chapter、section、article、source。检索时如果用户问“第 12 条”，可以直接用元数据过滤article=12，再结合向量检索，精度很高。

产品检索场景不一样。产品数据是 Excel，每行是一个产品，列是参数。解析时用 pandas 读取，每行转成一个文本块，格式是“产品名：XXX，参数名：YYY，参数值：ZZZ”。切分时按行切分，每行一个块。向量化时把“产品名+参数名+参数值”拼成一句话再转向量。入库时元数据包括product_name、param_name。检索时用户问“XXX 产品的功率是多少”，先用元数据过滤product_name=XXX，再向量检索param_name相关的块，命中率很高。

4.3 检索链路的参数计算与调优

检索链路的参数不是拍脑袋定的，要有计算依据。归档文档里我记了一个调优流程：先定召回数量，再定重排数量，最后定生成上下文长度。

召回数量取决于知识库大小和问题复杂度。知识库有 1 万块，问题简单，召回 Top20 够用；知识库有 100 万块，问题复杂，召回 Top50 甚至 Top100。我的经验公式是：召回数量 = log(知识库块数) × 10。1 万块约 40，10 万块约 50，100 万块约 60。这个公式给的是起点，实际要根据召回率调整。

重排数量取决于生成模型的上下文窗口。生成模型上下文 8K token，每个块平均 300 token，重排 Top5 就是 1500 token，加上问题和系统提示，总共 2K 左右，留足余量。如果上下文 32K，重排 Top10 也没问题。但重排数量不是越多越好，太多会引入噪声，我的经验是Top3 到 Top5 最平衡。

生成上下文长度要留出余量给模型输出。如果模型上下文 8K，输入最多 6K，输出留 2K。输入里包括系统提示、检索块、用户问题、历史对话。历史对话如果太长，要做摘要或截断。归档文档里我要求每次检索后都记录 token 消耗，方便后续优化。

4.4 智能体工作流的搭建与调试

智能体工作流用 LangGraph 或 AgentScope 搭建。LangGraph 用图结构定义节点和边，适合有明确流程的场景；AgentScope 用消息传递，适合多智能体协作。我以销售智能体为例，走一遍搭建过程。

销售智能体的目标是：用户输入一个客户需求，智能体检索产品知识库，推荐合适产品，生成跟进话术。工作流分四个节点：需求解析节点用大模型提取客户需求关键词；产品检索节点用关键词检索产品知识库；产品推荐节点用大模型对检索结果排序并推荐；话术生成节点用大模型生成跟进话术。节点之间用条件边连接，如果检索结果为空，回到需求解析节点重新提取关键词。

调试时我重点看三个地方：节点输入输出是否符合预期、条件边是否走对分支、大模型调用是否稳定。LangGraph 提供了可视化工具，能把工作流画出来，方便排查。AgentScope 提供了消息日志，能看到智能体之间的通信内容。我的经验是：先在本地用少量数据跑通工作流，再上真实数据，否则问题太多，不知道从哪查起。

4.5 评估体系的建立与落地

评估是 RAG 智能体全栈开发里最容易被跳过的一环，但它是持续优化的基础。归档文档里我把评估拆成检索评估和生成评估。

检索评估看召回率和精确率。召回率是正确块被召回的比例，精确率是召回块中正确块的比例。准备 100 个测试问题，每个问题标注正确块，跑一遍检索，算召回率和精确率。召回率低，说明切分或 Embedding 有问题；精确率高但召回率低，说明检索太保守，可以增加召回数量。

生成评估看忠实度和相关性。忠实度是回答是否基于检索内容，相关性是回答是否解决了问题。忠实度可以用大模型打分，也可以用人工抽检。相关性可以用 BLEU 或 ROUGE，但这些指标对中文不太友好，我的做法是用大模型打分加人工抽检。归档文档里我要求每次迭代都跑一遍评估，记录指标变化，避免“感觉变好了”但实际变差。

注意：评估集要覆盖不同类型的问题，事实型、对比型、推理型、多轮型都要有。只测事实型问题，评估结果会虚高，上线后遇到复杂问题就露馅。

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

5.1 检索不准的排查思路

检索不准是最常见的问题，排查要按链路走。先看切分：把检索到的块和正确块打印出来，看切分是否把关键信息切散了。再看 Embedding：用相同问题跑不同 Embedding 模型，看召回结果是否变化。再看检索参数：召回数量是否太小，相似度阈值是否太高。最后看重排：重排后正确块是否被排到后面，如果是，检查重排模型和 Embedding 模型是否匹配。

我遇到过一个典型案例：用户问“年假怎么算”，检索总是召回“病假”相关块。排查发现，切分时把“年假”和“病假”放在同一个块里，Embedding 后两个词的向量很接近，检索时区分不开。解决办法是把年假和病假拆成两个块，元数据里加leave_type字段，检索时用元数据过滤。这个问题让我意识到：切分粒度要和业务粒度对齐，业务上分开的概念，切分时也要分开。

5.2 回答胡编的排查思路

回答胡编通常是生成模型没有正确使用检索内容。排查要看检索内容是否传给了生成模型、系统提示是否要求基于检索内容回答、生成模型是否忽略了检索内容。我的做法是在系统提示里明确写“只基于以下检索内容回答，如果检索内容没有相关信息，回答‘知识库中没有找到相关信息’”。另外，检索内容要放在用户问题前面，并且用分隔符标出来，让模型清楚哪些是检索内容、哪些是用户问题。

还有一个坑是检索内容太长，生成模型注意力被分散，反而忽略了关键信息。解决办法是控制重排数量，或者对检索内容做摘要后再传给生成模型。归档文档里我记了一个技巧：在检索内容里把最相关的块放在最前面，生成模型对开头的内容注意力更高。

5.3 性能瓶颈的排查思路

性能瓶颈通常在向量检索和大模型调用两处。向量检索慢，看索引类型和数据量，HNSW 在 10 万块以内通常毫秒级，如果慢，检查是否用了 Flat 索引或数据量过大。大模型调用慢，看是本地部署还是 API 调用，本地部署看 GPU 利用率和批处理大小，API 调用看网络延迟和并发限制。

我的优化经验是：向量检索加缓存，相同问题直接返回缓存结果；大模型调用加流式输出，用户感知更快；批处理 Embedding，一次转多个块，比逐个转快很多。归档文档里我记了一个数据：批处理大小从 1 调到 32，Embedding 速度提升约 8 倍。

5.4 常见问题速查表

5.5 独家避坑技巧

第一个技巧：元数据比向量更重要。很多人只关注向量检索，忽略元数据过滤。实际上，业务场景里很多问题可以用元数据直接过滤，比如“查某个产品的参数”“查某个制度的条款”，元数据过滤比向量检索更准更快。归档文档里我要求每个块至少带三个元数据字段：来源、类型、业务标识。

第二个技巧：评估集要持续更新。上线后用户会问出你没想到的问题，把这些问法加进评估集，下次迭代就能覆盖。我的做法是每周抽 10 个真实问题，标注正确块和正确答案，加进评估集。半年下来，评估集从 100 条涨到 300 多条，覆盖了各种边界情况。

第三个技巧：别追求一次完美。RAG 智能体是迭代出来的，第一版能跑通就行，然后按评估指标逐步优化。我见过太多人想一次把切分、Embedding、重排、编排都调到最优，结果卡在某个环节迟迟上不了线。先上线，再优化，用真实反馈驱动迭代，比闭门造车快得多。

第四个技巧：日志要记全。每次检索记录问题、召回块、重排分数、生成回答、token 消耗、耗时。这些日志是排查问题的依据，也是优化的数据基础。归档文档里我要求日志至少保留 30 天，方便回溯。

6. 技术体系归档的维护与扩展

6.1 归档文档的结构设计

归档文档要能长期维护，结构设计很关键。我的归档文档分四层：索引层是目录和关键词索引，方便快速定位；模块层按功能模块组织，每个模块独立成篇；案例层记录具体项目的实现和踩坑；附录层放工具对比、参数速查、评估集。每层之间用交叉引用连接，比如模块层的“切分策略”引用案例层的“制度助手切分实践”，案例层的“产品检索”引用附录层的“向量库选型对比”。

索引层我用了关键词标签，每个模块打上多个标签，比如“切分”标签下有“固定长度”“递归切分”“语义切分”“结构切分”。搜索标签就能找到所有相关模块。这个设计参考了本体 RAG 的思路，把知识组织成网状结构，而不是线性文档。

6.2 技术更新的跟进方法

RAG 和智能体领域更新很快，归档文档要定期更新。我的做法是：每月花半天时间扫一遍新框架、新模型、新方法，有值得记录的加进归档文档，标注更新日期和适用场景。比如 AgentScope 2.0 发布后，我专门加了一节“多智能体编排框架对比”，把 AgentScope 2.0 和 LangGraph 的适用场景、上手难度、社区活跃度做了对比。

跟进技术更新不要盲目追新，要看是否解决实际问题。我的判断标准是：新方法是否在我的评估集上带来可量化的提升。如果只是论文指标好看，实际项目没提升，就不急着换。归档文档里我专门留了一节“待验证技术”，把看到的新方法先记下来，等有项目场景时再验证。

6.3 团队协作中的归档使用

归档文档在团队协作里价值更大。新成员入职，先读归档文档的索引层和模块层，能快速建立全局认知；做项目时，按模块层查具体实现，按案例层查踩坑经验；做技术选型时，按附录层查对比数据。我的团队里，归档文档是共享的，每个人都可以补充案例和踩坑，但模块层和附录层的修改要经过评审，保证质量。

协作时要注意版本管理。归档文档用 Git 管理，每次修改提交 commit，写清楚改了什么、为什么改。这样能追溯每个决策的背景，避免后人不知道为什么这么选。归档文档的 README 里我写了使用说明和贡献指南，新成员一看就知道怎么用、怎么改。

6.4 从归档到复用的实践

归档的最终目的是复用。我在新项目启动时，先翻归档文档，看有没有类似场景的案例，有就直接参考，没有就按模块层的框架从头搭。比如最近做一个“旅游推荐智能体”，我翻了归档文档，发现“产品检索”案例里的元数据过滤思路可以直接用，就把产品名换成景点名，参数名换成景点属性，很快搭出了原型。

复用不是照搬，要根据新场景调整。归档文档里每个案例都标了“适用场景”和“不适用场景”，避免误用。比如“制度助手”的结构切分适合有明确章节的文档，不适合散文类内容；“产品检索”的按行切分适合表格数据，不适合长文本描述。复用前先确认场景匹配，再调整参数。

7. 我在多个 RAG 智能体项目里沉淀下来的个人体会

做 RAG 智能体全栈开发这一年多，我最大的体会是：技术选型不是最重要的，数据质量才是。我见过用最便宜的 Embedding 模型、最简单的向量库，但数据清洗做得好、切分策略对，效果比用最贵模型、最复杂框架但数据一团糟的项目好得多。归档文档里我把“数据质量检查”放在最前面，每个项目启动时先花时间检查数据，比后面调参省事得多。

第二个体会是：评估要趁早。很多人等项目做完才做评估，结果发现效果不行，回头改成本很高。我的做法是项目启动时就建评估集，哪怕只有 20 条，也能在开发过程中随时验证。评估集不用一开始就很全，随着项目推进逐步补充，但一定要有。

第三个体会是：智能体的价值在“做”，不在“说”。普通 RAG 只能回答问题，智能体能调用工具、执行任务、多步协作，这才是智能体区别于 RAG 的地方。做智能体项目时，多想想“这个场景能不能让智能体做点什么”，而不是只让它回答。比如制度助手，除了回答条款，还能自动生成学习提纲、自动出测试题、自动对比新旧制度差异，这些“做”的能力才是智能体的核心竞争力。

最后分享一个小技巧：归档文档要写“为什么”，不只写“怎么做”。怎么做网上教程很多，为什么这么做才是你的经验价值。比如“为什么用 HNSW 不用 IVF”，网上可能只说 HNSW 快，但你要写清楚在你的数据量、你的硬件条件下，HNSW 的精度和速度平衡点在哪里，IVF 调参成本有多高。这些“为什么”才是归档文档的灵魂，也是下次复用时的决策依据。