RAG（检索增强生成）这两年从学术圈火到工业界，几乎成了大模型应用落地的标配方案。但我在社区里观察到一个很普遍的现象：很多人一上来就急着搭向量库、调API、拼Prompt，结果系统跑起来要么答非所问，要么检索回来的内容跟问题八竿子打不着。问题的根源往往不在模型本身，而在于对RAG整个链路的理解是断裂的——知道有"检索"和"生成"两步，但说不清楚每一步内部到底发生了什么，更不知道哪个环节出了偏差该怎么调。
这篇内容我想把RAG从工作原理到构建流程再到检索评估这条线完整串一遍。不管你是刚接触大模型应用的新手，还是已经搭过Demo但效果不理想的开发者，都能从中找到可以直接用的思路和参数。我会尽量把每个技术选择背后的"为什么"讲清楚，而不是只丢一堆步骤让你照抄。
1. 先搞清楚RAG到底在解决什么问题
1.1 大模型的两个硬伤：知识过时和幻觉
大语言模型有个根本性的限制：它的知识全部来自训练数据，而训练数据是有截止时间的。你问它昨天发生的新闻，它要么说不知道，要么一本正经地编一个答案给你。这就是所谓的幻觉问题——模型在缺乏依据时，会用"看起来合理"的方式生成内容，而不是承认自己不知道。
另一个问题是私有知识缺失。每家企业、每个团队都有大量内部文档、产品手册、历史工单，这些内容不可能出现在公开训练数据里。你直接问模型"我们公司产品的退款流程是什么"，它只能瞎猜。
传统的解法是微调（Fine-tuning），拿自己的数据继续训练模型。但微调有几个现实问题：成本高、周期长、每次知识更新都要重新训练，而且微调后的模型仍然可能产生幻觉。RAG的思路完全不同——它不改模型本身，而是在模型回答问题之前，先从外部知识库里检索出相关内容，把这些内容作为上下文一起喂给模型，让模型"看着材料答题"。
打个比方：微调像是让学生把整本教材背下来再考试，RAG像是开卷考试，学生可以翻书找答案。开卷考试的好处是，书可以随时换新版，学生不需要重新背。
1.2 RAG的核心工作链路拆解
RAG的完整链路可以拆成三个大阶段：
索引阶段（离线）：把外部知识库的文档进行处理，切分成合适大小的片段，通过嵌入模型转成向量，存入向量数据库。这一步是一次性的或者定期执行的，不涉及用户查询。
检索阶段（在线）：用户提出问题时，系统把问题也转成向量，在向量数据库中查找最相似的文档片段，可能还会结合关键词检索做多路召回，最后对结果做重排序。
生成阶段（在线）：把检索到的文档片段和用户问题一起组装成Prompt，发给大模型，让模型基于这些材料生成回答。
这三个阶段里，索引阶段决定了知识库的质量上限，检索阶段决定了能不能找到对的内容，生成阶段决定了最终输出的可读性和准确性。任何一环出问题，整个系统的效果都会打折扣。
1.3 什么场景适合上RAG，什么场景不适合
RAG不是万能的。它最适合的场景是：有明确的知识库、问题需要基于事实回答、知识会更新。比如智能客服、企业内部知识助手、文档问答系统、法律条文查询等。
不太适合的场景包括：需要创造性写作的任务（RAG反而会限制发挥）、纯逻辑推理任务（检索不到有用内容）、实时性要求极高的场景（检索本身有延迟）。还有一种常见误区是拿RAG去做模型本身就能答好的通用问题，这属于杀鸡用牛刀，白白增加系统复杂度和响应时间。
2. 文档处理与索引构建：决定系统上限的隐形环节
2.1 文档解析：别让垃圾进垃圾出
很多人搭RAG时最忽略的就是文档解析这一步。他们默认所有文档都是干净的纯文本，直接读进来就切分。实际情况是，你的知识库可能是PDF、Word、HTML、扫描件、Excel表格，每种格式的解析难度完全不同。
PDF是最麻烦的。有些PDF是文本型的，可以直接提取文字；有些是扫描型的，必须先做OCR；还有些PDF的排版极其复杂，双栏、表格、图片混排，直接提取出来的文字顺序全是乱的。我见过一个案例，某团队把产品手册PDF直接丢进解析器，结果表格里的参数全部错位，检索出来的内容驴唇不对马嘴。
实操建议是：解析完之后一定要做一轮人工抽检，随机抽10到20个文档片段，看看文字是否连贯、表格是否完整、标题层级是否保留。如果解析质量差，后面所有环节都是在垃圾上做优化。
对于表格类内容，建议单独处理，把表格转成结构化的描述文本，比如"产品A的尺寸是10cm×20cm，重量是500g"，而不是保留原始的表格格式。这样嵌入模型更容易理解语义。
2.2 文本切分：粒度选择背后的权衡
文本切分（Chunking）是RAG里最需要经验判断的环节之一。切得太粗，一个片段里混了好几个主题，检索时精度下降；切得太细，一个完整的语义被拆散，模型拿到手的信息不完整。
常见的切分策略有几种：
固定长度切分：按字符数或token数切，比如每500个token一段，段与段之间留50个token的重叠。这是最简单的做法，适合文本结构不明显的场景。重叠的作用是防止关键信息刚好被切在边界上。
按语义切分：根据段落、标题、句子边界来切，尽量保证每个片段是一个完整的语义单元。比如按Markdown的标题层级切，每个二级标题下的内容作为一个片段。
递归切分：先按大结构切，如果某段还是太长，再按小结构切，逐层降级。这是目前比较推荐的做法，LangChain的RecursiveCharacterTextSplitter就是这种思路。
具体选多大的粒度？我的经验是：中文场景下，300到500字是一个比较稳妥的区间。太短了语义不完整，太长了检索精度下降。但这个数字不是绝对的，要看你的文档类型。技术文档可以稍长一些，FAQ类可以短一些，因为每个问答本身就是独立的语义单元。
还有一个容易被忽略的点：在切分时保留元数据。每个片段应该带上它来自哪个文档、哪个章节、第几页。这样检索出来之后，你可以在回答里标注来源，用户能追溯，也方便排查问题。
2.3 嵌入模型选型：不是越贵越好
嵌入模型负责把文本转成向量。选型时主要看几个维度：语言支持（中文场景必须选中文效果好的）、向量维度（影响存储和检索速度）、最大输入长度（要能覆盖你的片段长度）、以及推理成本。
目前主流的选择分两类：一类是API型的嵌入服务，优点是开箱即用、效果稳定，缺点是按量计费、有网络延迟、数据要出本地；另一类是本地部署的开源嵌入模型，优点是一次性部署、数据不出域、可以自由调优，缺点是需要GPU资源、效果可能略逊于顶级API。
中文场景下，我建议优先考虑专门针对中文优化的模型。很多英文嵌入模型在中文上的表现会明显下降，因为它们的训练语料以英文为主。选型时不要只看排行榜上的分数，要拿你自己的数据做实际测试——构造一批"问题-正确片段"的配对，看模型能不能把正确片段排在前面。
还有一个实操细节：嵌入模型和后续的检索、重排序模型最好配套使用。有些嵌入模型是专门为配合某个重排序模型训练的，搭配使用效果更好。如果你混用不同来源的模型，可能会出现向量空间不匹配的问题。
2.4 向量数据库：选型的三个关键考量
向量数据库负责存储向量并支持相似度检索。选型时主要考虑三点：
规模：如果你的知识库只有几千个片段，用FAISS这种内存型库就够了，简单快速。如果到了百万级以上，就需要考虑Milvus、Qdrant这类分布式方案。
检索方式：有些向量库只支持向量检索，有些同时支持向量检索和关键词检索（比如支持BM25），后者对做混合检索更友好。
运维成本：自建向量库需要考虑部署、扩容、备份、监控。如果团队没有专门的运维人力，用云服务或者轻量级方案可能更实际。
我个人的建议是：先用最简单的方案跑通全流程，再根据实际瓶颈做优化。很多人在选型阶段纠结太久，结果连一个能跑的Demo都没搭出来。FAISS加一个本地嵌入模型，半天就能跑通，先验证效果再谈优化。
3. 检索策略：从单路召回走向多路混合
3.1 向量检索的局限性与关键词检索的互补
纯向量检索有个天然缺陷：它对精确匹配不敏感。比如用户问"XX-2000型号的参数"，向量检索可能返回一堆"XX系列产品参数"的片段，但就是漏掉了精确包含"XX-2000"的那一段。因为向量检索看的是语义相似度，而型号这种专有名词的语义信息很弱。
关键词检索（比如BM25）恰好相反：它对精确匹配很擅长，但不懂语义。用户问"怎么退款"，文档里写的是"如何申请退货"，关键词检索就匹配不上。
所以多路召回的核心思路就是：同时用向量检索和关键词检索，各取所长，然后把两路结果合并。这样既能抓住语义相似的内容，又不会漏掉精确匹配的关键信息。
3.2 混合检索的融合策略：RRF与加权求和
两路检索各自返回一个排序列表，怎么合并成一个最终列表？常见的有两种方法：
RRF（Reciprocal Rank Fusion，倒数排名融合）：不看具体分数，只看排名。每个文档的最终得分是它在各路结果中排名的倒数之和。公式是 score = Σ 1/(k + rank)，其中k是一个平滑常数，通常取60。RRF的优点是简单、不需要归一化分数、对不同检索器的分数尺度不敏感。
加权求和：把两路的相似度分数归一化到同一尺度，然后按权重相加。比如向量检索占0.7，关键词检索占0.3。这种方法的优点是灵活，可以调节权重；缺点是需要处理分数归一化，而且不同检索器的分数分布可能差异很大。
我的经验是：先用RRF跑通，因为它几乎不需要调参。如果发现某一路明显更重要，再考虑加权求和。RRF在大多数场景下表现已经很好了。
3.3 重排序：把最相关的结果顶上来
多路召回之后，通常会得到一个比较大的候选集，比如20到50个片段。这些片段的排序可能还不够精准，这时候就需要重排序（Rerank）。
重排序模型和嵌入模型的工作方式不同。嵌入模型是分别把问题和文档转成向量，然后算相似度，速度快但精度有限。重排序模型是把问题和文档一起输入，直接输出一个相关性分数，精度更高但速度慢。所以典型做法是：用嵌入模型做粗筛（从百万级降到几十个），再用重排序模型做精排（从几十个选出最相关的几个）。
重排序模型的选择上，中文场景同样要选中文优化的版本。实测下来，加上重排序这一步，检索的准确率通常能有明显提升，尤其是当候选集里有很多"看起来相关但实际不相关"的片段时。
3.4 查询改写：让用户的问题更容易被检索到
用户提的问题往往和文档里的表述不一致。用户问"你们的退货政策是啥"，文档里写的是"商品退换货规则说明"。虽然语义相近，但直接检索可能效果不好。
查询改写的思路是：在检索之前，先用大模型把用户的问题改写成更适合检索的形式。常见的方法有：
扩展：把问题扩展成多个相关查询，分别检索后合并结果。比如"退货政策"可以扩展成"退货流程""退款条件""退换货规则"。
改写：把口语化的问题改写成更正式的表述，或者补充上下文。比如把"这个咋弄"结合对话历史改写成"如何配置XX功能的参数"。
分解：把复杂问题拆成多个子问题，分别检索。比如"对比A产品和B产品的价格和性能"可以拆成"A产品价格""B产品价格""A产品性能""B产品性能"四个查询。
查询改写会额外增加一次大模型调用，有延迟成本。建议只在检索效果不理想时启用，或者对复杂问题才启用。
4. 生成阶段：把检索结果用好才是关键
4.1 Prompt组装的常见错误
检索到相关片段之后，怎么把它们和问题一起组装成Prompt，直接决定了最终回答的质量。我见过太多人在这步犯低级错误：
错误一：把所有检索结果一股脑塞进去。检索返回10个片段，全部拼进Prompt，结果上下文太长，模型注意力被分散，反而抓不住重点。正确做法是只取最相关的3到5个片段，宁缺毋滥。
错误二：不做去重。多路召回的结果里经常有重复或高度相似的片段，重复内容会浪费上下文窗口，还可能让模型过度关注某个信息点。
错误三：不标注来源。每个片段应该标明来自哪个文档，这样模型在回答时可以引用来源，用户也能验证。格式可以是"[来源：产品手册第3章]"。
错误四：不设边界。Prompt里必须明确告诉模型"如果检索到的内容无法回答问题，就如实说不知道，不要编造"。这句话能大幅降低幻觉率。
4.2 上下文窗口的分配艺术
大模型的上下文窗口是有限的。你需要在这个窗口里放下：系统指令、检索到的文档片段、对话历史、用户当前问题。怎么分配？
我的建议是：检索内容占大头，但不要超过窗口的60%。剩下的留给系统指令、对话历史和模型生成的空间。如果检索内容太多，可以考虑做摘要压缩——用大模型把长片段压缩成关键信息，再放进Prompt。
对话历史也要控制。多轮对话时，不是把所有历史都带上，而是只带最近几轮，或者对历史做摘要。否则历史会挤占检索内容的空间。
4.3 引用溯源：让回答可信可查
RAG相比纯生成模型的一大优势就是可溯源。你可以在Prompt里要求模型在回答时标注每个信息的来源，比如"根据[文档A]的描述..."。这样用户看到回答后，能知道信息来自哪里，可信度更高。
实现溯源的关键是：在组装Prompt时给每个片段一个唯一标识（比如编号），并要求模型在引用时带上这个编号。前端展示时，可以把编号映射回原始文档链接。
这个功能在企业场景里特别重要。员工用知识助手查制度，如果回答没有来源，他们不敢信；有了来源，可以点进去看原文，信任度完全不一样。
5. 检索评估：没有度量就没有优化
5.1 构建评估集的实操方法
很多人搭完RAG系统后，不知道效果到底怎么样，只能凭感觉说"好像还行"。这是不行的。你需要一个评估集来量化效果。
构建评估集的方法：从知识库里挑选一批有代表性的问题，每个问题标注出正确的文档片段（ground truth）。规模不用很大，50到100个问题就能看出趋势。关键是覆盖面要广：简单的事实查询、需要多跳推理的问题、知识库里没有答案的问题（用来测试模型会不会编造），都要有。
标注ground truth是个体力活，但值得做。如果人力有限，可以先用大模型辅助标注，再人工校验。
5.2 检索环节的核心指标
检索环节最常用的指标是召回率（Recall）和精确率（Precision），以及综合两者的F1值。
Recall@K：前K个检索结果里，包含正确片段的样本比例。比如Recall@5表示看前5个结果，有多少比例的问题能找到正确答案。这个指标衡量的是"有没有找全"。
Precision@K：前K个结果里，有多少是真正相关的。这个指标衡量的是"找得准不准"。
MRR（Mean Reciprocal Rank）：正确片段排在第几位，取倒数的平均值。如果正确片段总是排第一，MRR就是1；如果总是排第三，MRR就是1/3。这个指标衡量的是"排得对不对"。
NDCG（Normalized Discounted Cumulative Gain）：考虑了排序位置的指标，排在前面的相关结果权重更高。适合有多个相关片段的场景。
实际优化时，我建议优先关注Recall。因为如果正确内容根本没被检索到，后面生成阶段再强也没用。先把召回率做上去，再优化排序精度。
5.3 生成环节的评估维度
生成环节的评估更主观一些，但也有可量化的维度：
忠实度（Faithfulness）：回答是否完全基于检索到的内容，有没有编造。这个可以用大模型来评判——把回答和检索内容一起给大模型，问它"回答里的每个信息点是否都能在材料中找到依据"。
相关性（Relevance）：回答是否切题，有没有答非所问。
完整性（Completeness）：回答是否覆盖了问题的所有方面。
流畅度（Fluency）：回答是否通顺自然。
这几个维度里，忠实度是最重要的。一个RAG系统如果经常编造信息，那还不如不用。评估时可以专门构造一批"知识库里没有答案"的问题，看模型是老实说不知道，还是硬编一个答案。
5.4 用大模型做自动评估的利与弊
人工评估准确但成本高、速度慢。用大模型做自动评估（LLM-as-a-Judge）是目前的趋势，但也有坑：
利：速度快、成本低、可以大规模跑、一致性比人工好（不会因为疲劳而标准漂移）。
弊：大模型评估有偏见，比如倾向于给更长的回答打高分、倾向于给和自己风格相似的回答打高分。而且评估模型本身也可能出错。
我的建议是：用大模型做初筛，人工做抽检。大模型跑一遍全量评估，找出得分低的样本，人工重点看这些样本。这样既有效率又有质量保证。另外，评估用的Prompt要精心设计，给出明确的评分标准和示例，减少主观性。
6. 实战中那些文档不会告诉你的坑
6.1 检索到了但模型不用：上下文位置的影响
有一个很反直觉的现象：检索明明返回了正确片段，但模型就是不用它，还是按自己的知识回答。这通常和片段在Prompt中的位置有关。
研究发现，大模型对上下文开头和结尾的内容注意力更强，中间部分容易被忽略（这叫"lost in the middle"现象）。所以如果你把最相关的片段放在中间，模型可能反而没注意到。
实操建议：把最相关的片段放在Prompt的开头或结尾。如果检索结果有明确的排序，可以把最重要的放最前面，次重要的放最后面。
6.2 相似度分数高不等于内容相关
向量相似度高，不代表内容真的能回答问题。我见过很多案例：问题和某个片段向量相似度0.9，但那个片段只是用词相似，实际内容完全不相关。
这是因为嵌入模型捕捉的是语义相似，而不是问答匹配。问题和答案在语义上可能并不相似（比如问"怎么退款"，答案"请填写退货申请表"），但它们是匹配的。
解决思路：一是用重排序模型做精排，它专门针对问答匹配训练；二是引入关键词检索做补充；三是在评估时不要只看相似度分数，要看实际回答质量。
6.3 知识库更新后的索引同步问题
知识库不是一成不变的。文档会新增、修改、删除。如果索引不同步，用户就会检索到过时的内容。
常见做法是：定期全量重建索引（比如每天凌晨跑一次），或者增量更新（文档变更时只更新对应的向量）。全量重建简单但耗资源，增量更新高效但实现复杂，需要处理文档版本、删除旧向量等问题。
我的建议是：如果知识库更新不频繁（比如每周几次），全量重建就够了。如果更新频繁，再考虑增量方案。不管哪种方案，都要有版本管理——记录每个片段的来源文档版本，方便排查问题。
6.4 多轮对话中的检索退化
多轮对话时，用户的问题往往依赖上下文。比如第一轮问"XX产品的价格"，第二轮问"那它的保修期呢"。如果直接把第二轮的问题拿去检索，"它"指代不明，检索效果会很差。
解决办法是查询改写时结合对话历史，把"那它的保修期呢"改写成"XX产品的保修期是多久"，再拿去检索。这一步在多轮对话场景里几乎是必须的。
6.5 成本与延迟的平衡
RAG系统涉及多次模型调用：查询改写一次、嵌入一次、重排序一次、生成一次。每次调用都有成本和延迟。如果每步都用最大的模型，成本会很高，响应也会很慢。
优化思路：按需使用。查询改写只在必要时启用；嵌入和重排序用小模型；生成用大模型。另外可以做缓存——相同或相似的问题，直接返回缓存结果，不用重新走全流程。
延迟方面，检索和重排序是串行的，可以考虑并行化。比如向量检索和关键词检索可以同时发起，不用等一个完成再发另一个。
7. 从Demo到生产：还需要补哪些课
7.1 监控与日志：出了问题能查
Demo阶段不用考虑监控，但生产环境必须有。需要记录的关键信息包括：用户问了什么、检索到了哪些片段、每个片段的相似度分数、最终回答是什么、用户有没有反馈。
这些日志能帮你定位问题。比如用户反馈回答不准，你可以查日志看是检索没找到正确内容，还是找到了但模型没用。没有日志，你只能猜。
7.2 用户反馈闭环
在回答旁边加一个"有用/没用"的按钮，收集用户反馈。这些反馈是最宝贵的优化依据。定期分析差评样本，找出共性问题，针对性优化。
更进一步，可以把用户反馈和检索日志结合，自动挖掘出"检索失败"的案例，补充到评估集里，形成持续优化的闭环。
7.3 安全与权限控制
企业场景下，不同员工能访问的文档不同。RAG系统必须做权限过滤——检索时只返回用户有权限查看的片段。这个过滤要在检索阶段就做，不能等生成之后再过滤，否则模型可能已经把敏感信息写进回答了。
实现方式是在向量库里给每个片段打上权限标签，检索时带上用户的权限信息做过滤。这增加了系统复杂度，但在企业场景里是必须的。
7.4 兜底策略：检索不到怎么办
不是所有问题都能在知识库里找到答案。当检索结果的相似度都低于某个阈值时，系统应该走兜底策略：要么直接告诉用户"没有找到相关信息"，要么转人工，要么用通用大模型回答但明确标注"以下内容未经知识库验证"。
最忌讳的是检索不到还硬让模型回答，结果编造一堆看似合理的内容。宁可说不知道，也不要给错误信息。
8. 一些参数调优的实战心得
8.1 相似度阈值怎么定
相似度阈值用来判断检索结果是否可用。定太高，很多能回答的问题被过滤掉；定太低，不相关的内容被放进来。
我的做法是：用评估集跑一遍，画出相似度分布图。看正确片段的相似度集中在什么区间，错误片段的相似度集中在什么区间，取两者之间的值作为阈值。如果没有明显的分界，说明嵌入模型可能不适合你的场景，考虑换模型。
8.2 TopK取多少合适
TopK是检索返回的片段数量。太小可能漏掉正确内容，太大引入噪声还增加延迟。
经验值：粗筛阶段取20到50，精排后取3到5。粗筛阶段宁多勿少，保证召回；精排阶段宁精勿滥，保证精度。具体数字还是要用评估集测，看Recall和Precision的平衡点。
8.3 重排序模型的batch size
重排序模型通常一次处理一个"问题-文档"对，如果候选集有50个片段，就要跑50次。这很慢。优化方法是批处理——把多个对打包成一个batch一起推理。batch size受GPU显存限制，需要实测找到最优值。
8.4 嵌入维度的取舍
嵌入维度越高，表达能力越强，但存储和检索成本也越高。常见的有768维、1024维、1536维。维度降低一半，存储和检索速度能提升不少，但精度可能下降几个百分点。
如果知识库规模不大，用高维度没问题。如果到了千万级片段，维度的影响就很明显了，需要做权衡。有些模型支持维度压缩（比如Matryoshka嵌入），可以在精度损失很小的情况下降低维度。
9. 关于RAG，我踩过的最大的几个坑
第一个坑是过度迷信向量检索。刚开始做的时候，我觉得向量检索是"AI"的，关键词检索是"老古董"，所以只用向量检索。结果遇到大量包含专有名词、型号、编号的查询，向量检索全军覆没。后来加上关键词检索做混合，效果立刻好转。技术没有新旧之分，只有适不适合。
第二个坑是忽略文档解析质量。有次搭一个PDF问答系统，效果怎么调都不好。排查了半天，最后发现是PDF解析出来的文字顺序全乱了，双栏排版被读成了左右交错。重新做了解析，效果直接上了一个台阶。这让我意识到，RAG系统的上限往往不在模型，而在数据质量。
第三个坑是评估集偷懒。早期觉得搭评估集太麻烦，凭感觉调参。结果调来调去，不知道到底有没有变好。后来老老实实标了80个问题，每次改动都跑一遍评估，优化方向立刻清晰了。评估集是RAG优化的指南针，没有它就是在黑暗中摸索。
第四个坑是Prompt里塞太多内容。一开始觉得检索结果越多越好，把Top10全塞进去。结果模型被无关信息干扰，回答质量反而下降。后来改成只取Top3到5，并且把最相关的放开头，效果明显提升。少即是多，这句话在RAG的生成阶段特别适用。
10. 后续可以继续深挖的方向
RAG这个领域还在快速演进。除了上面讲的基础链路，还有几个方向值得关注：
GraphRAG：把知识图谱和RAG结合，处理需要多跳推理的问题。传统RAG只能检索到孤立的片段，GraphRAG能沿着实体关系把相关信息串起来。
Agentic RAG：让模型自己决定什么时候检索、检索什么、检索几次。传统RAG是"检索一次然后生成"，Agentic RAG是"边想边查"，适合复杂任务。
多模态RAG：不只检索文本，还能检索图片、表格、视频。这对文档类型复杂的场景很有用。
自适应检索：不是所有问题都需要检索。简单问题直接让模型回答，复杂问题才走RAG。这样能节省成本、降低延迟。
这些方向目前都还在发展中，落地案例不如基础RAG多。建议先把基础RAG做扎实，再根据实际需求探索进阶方案。基础不牢，上再花哨的架构也是空中楼阁。
我个人在实际项目中的体会是，RAG的效果提升往往不是靠某个"银弹"技术，而是靠每个环节一点点抠出来的。文档解析做好一点、切分粒度调准一点、检索策略丰富一点、Prompt组装精细一点，每个环节提升10%，乘起来就是质的飞跃。反过来，任何一个环节拉胯，整个系统的效果都会被拖累。所以别急着追新概念，先把这条基础链路走通、走扎实。
