1. 为什么要把目标与边界放在RAG项目的第一步我先说一个自己踩过的坑。去年我第一次做RAG问答系统的时候一上来就急着切chunk、调embedding模型、对比各种向量库忙活了两个星期效果看起来好像也能回答几个问题。结果到了评测阶段才发现——我根本没法说清楚什么叫做好。召回率多少算达标生成答案出现幻觉算谁的锅知识库里没有的内容到底应不应该回答这些问题全都没有答案最后只能反反复复调参项目差点烂尾。后来我养成了一个习惯也是这篇博文的标题里写的做RAG增强的单轮对话第一步不是写代码而是把目标和边界彻底梳理清楚。为什么目标与边界这么重要因为RAG系统涉及的技术环节太多了文档解析、分块策略、向量化、召回、重排、Prompt编排、生成策略……每一个环节都有大量可以调优的空间。如果你的目标定义模糊你就会陷入一种这里也能调调、那里也能改改的状态永远调不到一个让各方都满意的终点。反过来只要目标和边界清晰了所有技术选型都有了依据所有取舍都有了标尺。这篇博文聚焦的场景是RAG增强的单轮对话适合的人群是正在规划或搭建RAG问答系统的开发者和产品经理尤其是那些从零起步、准备把知识库问答做成一个正式项目的团队。我会把我在实际项目中总结出来的目标拆解方法、边界梳理思路、技术选型逻辑和踩坑经历一一讲清楚内容偏规划和设计不会堆一堆跑不通的代码。1.1 单轮对话与多轮对话两种完全不同的产品逻辑很多人一听到对话两个字就默认要做多轮。但实际上单轮对话的产品逻辑和多轮是完全不一样的技术方案也因此分叉。单轮对话指的是用户每次提问都是独立的一次请求系统不依赖上下文记忆。最典型的场景就是知识库问答用户问离职流程怎么走系统回答完这次交互就结束了。用户可能继续问下一个问题年假怎么算这又是一个独立的新问题。单轮对话的核心挑战在于问题必须是自包含的self-contained。这个政策的适用范围是什么——如果用户前面没有提到这个政策指哪个政策系统就无从回答。这是一个非常现实的产品约束。而多轮对话的核心挑战在于上下文管理和指代消解系统需要在多轮之间维护状态。它的技术复杂度更高但用户可以用更自然的方式提问比如离职流程怎么走……要提前多久申请……如果试用期呢——后面几个问题都隐含依赖前文。在项目规划时这个区分必须先定下来。Step2.0的项目范围就是单轮对话这意味着不接受指代不明的提问除非做问题改写但那是后续迭代要考虑的不在Step2.0范围内不需要维护对话状态每次请求都是独立的一次检索生成链路。明确这一点可以避免项目越做越大。我见过太多团队刚开始想做单轮问答做到一半被业务方要求像ChatGPT一样能连续聊天最后项目从RAG问答变成了一个不伦不类的对话机器人两头都不讨好。1.2 RAG在这个场景里到底扮演什么角色RAGRetrieval-Augmented Generation检索增强生成的核心思想说起来很简单先检索再生成。检索的目的不是给用户看一堆文档列表而是为了给大模型提供生成答案所需的依据材料。生成的目的也不是让模型自由发挥而是基于检索到的材料组织一段准确、完整、有条理的答案。用一句话概括RAG是用外部知识约束大模型生成过程的技术方案目标是减少幻觉、增强时效性、引入私有知识。在单轮对话场景里RAG的约束价值体现得特别明显。没有RAG的大模型就像一位记忆力很好但知识截止在训练日期之前的专家——它什么都敢说但说不准。加了RAG之后相当于给这位专家配了一间资料室要求它每一次发言都必须查过资料再说。资料室里有就照着资料说资料室里没有就老老实实说我不知道。1.3 这个Step2.0到底在整条产品线中处在什么位置从项目演进的角度看我习惯把RAG产品分成几个阶段Step0数据治理确定知识库范围、清理低质量文档、做格式标准化。Step1检索MVP先把查得准这件事跑通用BM25加向量检索搭出基础召回链路。Step2问答增强在检索之上加生成环节建评测集定义质量指标。这就是本篇的Step2.0。Step3体验迭代多轮对话、追问澄清、引用溯源、个性化等。如果你已经在Step1阶段完成了基础检索链路的搭建那么Step2.0的核心任务就是把检索到的内容变成合格的答案并且用一套客观的方法证明这个转换是可靠的。2. RAG增强单轮对话核心链路与各环节职责拆解在规划和设计阶段先把整条RAG链路拆开看清楚比急着调参重要得多。RAG增强的单轮对话从请求进来到答案返回大致会经过六个环节。我按实际顺序列一下每个环节后面标注它的核心目标。环节输入输出核心目标1. 问题理解与改写用户原始提问可用于检索的查询语句让检索拿到最容易被命中的表述2. 检索召回处理后的查询语句TopK候选文档块不遗漏相关知识片段3. 重排精排TopK候选文档块精排后的TopN文档让最相关的内容排在最前面4. 上下文组装精排后的文档块 Prompt模板组装好的模型输入让模型明确依据什么来回答5. 生成回答组装好的输入原始回答文本生成忠实于资料的答案6. 后处理与输出原始回答文本最终答案含引用、格式规整提升可用性支持溯源这六个环节在不同团队里会有取舍。比如有一些轻量实现会跳过第3步重排直接拿TopK去生成第6步后处理在很多MVP项目里也不做。但在Step2.0的规划阶段我建议至少把这六层都列出来然后在实现时按需裁剪——先看见全貌再做减法而不是一开始就不知道自己少了什么。2.1 检索层召回质量决定了整个系统的天花板检索层是整个RAG系统里最关键的一层没有之一。原因很简单如果这一层没有召回正确答案后面无论大模型多聪明、Prompt写得多好都不可能凭空变出正确答案。常见的检索策略有几种它们各有优缺点稀疏检索BM25基于关键词匹配对于专有名词、编号、精确短语非常友好而且不用训练开箱即用。缺点是遇到同义改写就抓瞎。密集向量检索Dense Vector Search用Embedding模型把文本映射成向量在语义层面做相似度检索能解决换一种说法但意思一样的问题。缺点是embedding模型是通用的领域术语如果不在模型的知识范围内效果可能很差。混合检索Hybrid Search取BM25和向量检索两条路径的召回结果做合并。这是我在实际项目里最推荐的做法两种策略互补之后召回的稳定性会明显提升。在Step2.0里我建议检索层至少要做到混合检索。你可以先让BM25返回一批结果向量召回返回一批结果通过简单的加权融合或RFFReciprocal Rank Fusion合并排序拿TopK进下一层。这个策略成本低、见效快后续再优化Rerank模型的收益。2.2 重排层用更精确的模型修正召回顺序混合检索的TopK里大概率会有语义相关但和问题关系不大的干扰项。比如用户问的是哺乳假每天多长时间向量检索可能召回了一段同时提到哺乳假和产假的文档这段内容确实在语义上相关但它并没有正面回答用户的问题。这时候就需要一个Rerank重排/精排模型上场。Rerank模型不是把问题映射成向量再做相似度计算而是直接把问题候选文档拼接成一个序列通过交叉编码器Cross-Encoder逐条判断相关性输出一个相关性得分然后根据得分重新排序。用不用Rerank效果差异在真实项目里非常大。我的经验是加了Rerank之后的Top3内容给到模型生成答案回答的准确性会有肉眼可见的提升。Rerank模型的选型可以从bge-reranker系列入手部署成本不高收益却很明显。2.3 生成层大模型的角色是基于材料的答题者生成层的核心问题是Prompt设计。在RAG的单轮对话场景里Prompt需要做到三件事第一明确告诉模型它的角色是基于给定材料回答问题第二规定如果材料中没有答案应该坦白承认而不是编造第三规定输出格式比如是否需要提供引用编号、是否分条目回答等。这里有一个很容易被忽视的细节Prompt不是写得越长越好而是要写清楚边界。你不需要花大篇幅去描述你是多么优秀的AI助手但你必须花足够篇幅说清楚哪些话不能说。我常用的Prompt框架大致是这样的你是一个基于知识库内容回答问题的助手。 请严格依据以下资料回答用户的问题。如果资料中没有提及相关内容 请明确回答根据现有资料无法回答该问题不要编造信息。 资料内容 [检索结果原文] 用户问题{question} 回答要求 1. 优先按资料内容组织答案可适当总结但不得添加资料中没有的信息。 2. 如果资料中包含与问题相关的多个方面请分点说明。 3. 在答案末尾列出参考的资料编号。这个框架看起来简单但每一个条款都有对应的问题场景第1条对抗幻觉第2条对抗只答一半第3条方便做溯源。2.4 RAG增强LLM的真实效果一个实际case的对比为了让上面的链路拆解更直观我拿一个我实际做过的场景举例。假设知识库里有一份《员工考勤管理制度》里面写了员工每天正常工作时间为8小时工作时间从上午9:00至下午18:00其中12:00至13:00为午餐休息时间。用户提问午餐休息算不算工作时间没有RAG的直接生成大模型基于自己的常识回答可能会说午餐休息时间是否计入工作时间需要根据公司的具体规定和相关法律法规来确定。——这等于什么都没说。有RAG的生成链路检索层召回《员工考勤管理制度》相关片段Rerank确认这条内容与问题高度相关生成层基于资料回答根据公司《员工考勤管理制度》员工每天正常工作时间为8小时午餐休息时间12:00至13:00不计入工作时间因此午餐休息时间不在8小时正常工作时间内。——这才是知识库问答该有的效果。同样是这个case如果知识库里其实没有关于午餐休息的任何规定检索层就会召回一堆无关内容或者召回不到内容。这时候生成层就必须按照Prompt里的边界要求老老实实回答根据现有资料无法回答该问题。这个敢于说不知道的能力正是RAG增强单轮对话与裸用大模型之间最本质的区别。3. 目标定义用可评测的指标框定做得好目标和边界梳理的核心工作之一就是把做得不错这种主观判断转化为一套可量化、可复现、可追踪的指标。没有指标的项目最后一定变成拍脑袋改参数。RAG增强单轮对话的质量可以从检索层和生成层两个维度来衡量。下面是我在实际项目中使用的指标体系。3.1 检索层评测指标召回率和排序质量检索层评测的前提是建一套标准评测集。评测集的形式为每个问题配一个标准相关文档ID列表即人类专家判断这个问题应该命中知识库里的哪几个文档块。有了评测集就能计算检索层的关键指标RecallK召回率在TopK结果中命中了多少个标准答案文档。比如测试集有100道题每道题标注了3个标准文档如果Top5平均能命中2.4个那Recall5就是80%。这个指标反映的是该找到的东西找到了没有。MRR平均倒数排名衡量第一个正确答案出现在第几位。如果正确答案排第一记1分排第二记0.5排第三记0.33以此类推。MRR越高说明正确答案越靠前。命中率Hit RateTopK结果中只要包含任意一个标准文档就算命中。这个指标比RecallK更宽松适合在项目初期使用。我给自己定的Step2.0目标是业务核心问题的Recall5不低于0.85MRR不低于0.7。如果达不到这个水平我不会进入生成层的优化因为基础不牢上面盖楼也白搭。3.2 生成层评测指标忠实度与完整性生成层的指标不像检索层那么客观但依然可以有比较规范的评测方案。忠实度Faithfulness回答是否完全基于检索材料有没有编造内容。评测方法是拿模型生成的每句话去和检索材料对一遍凡是材料里没有的事实性陈述都记为一次不忠实。完整性Completeness标准答案中覆盖的知识点模型是否都覆盖到了。比如标准答案包含申请条件、所需材料、办理时限三个点模型只回答了前两个完整性就是三分之二。格式合规率回答是否符合预定的格式规范比如是否包含引用标注、是否有明确的拒绝回答句式。在实际操作中我的评测流程分两步自动评测用一个大模型作为裁判LLM-as-a-Judge按固定评分规则给生成结果打分。用它可以快速跑完上百道题发现明显问题。人工抽检对自动评测中得分偏低和偏高的case进行人工复核。人只抽检边界情况效率高且不漏大问题。3.3 一套可落地的评测集怎么搭评测集建设是RAG项目里投入产出比最高的一项工作但也是最容易被拖延的。很多团队会想先把系统做出来再补评测结果系统做出来了也没法判断好坏等于没做。我建议评测集按三个来源来搭来源一真实用户问题录。如果系统已经有一个粗糙版本在线运行把用户的真实提问采集下来人工去重、筛选、改写形成问题集。真实问题的分布很重要你的评测集要能反映真实场景的提问习惯。来源二业务专家拟题。请业务侧的同学针对知识库内容编写他们平时最常被问到的问题。这类问题的特点是实际、接地气而且业务专家能比较准确地判断正确答案应该覆盖哪些点。来源三大模型辅助生成。用大模型基于知识库文档块自动生成若干问题和参考答案然后人工审校。这个来源的优势是覆盖面大但一定要人工审校因为大模型生成的答案也可能有幻觉。三个来源合起来最终目标是形成100~200条问题的评测集每条问题包含问题文本、标准答案要点、相关文档ID列表、难度标注。3.4 目标分层不能只盯一个指标要分维度达标在实际项目中RAG系统的质量不会因为一个指标提高而全面提升所以我习惯把目标拆成分层的层级核心指标最低达标线力争线基础层问题不因流程链路原因报错100%100%召回层Recall5 / MRR0.80 / 0.600.85 / 0.70生成层忠实度 / 完整性0.90 / 0.750.95 / 0.85体验层平均响应时长 P95 5s / 8s 3s / 5s分层的意义在于每个环节有每个环节的及格线逐层把关出问题时能快速精确定位是检索的锅还是生成的锅不至于所有人对着同一个效果不好争论半天。4. 边界梳理明确不做什么项目才不会失控目标定义了要做什么、做到什么程度边界则定义了不做什么、在什么范围内做。项目失控的常见原因往往不是目标不清而是边界模糊——不知不觉就被业务方带进了这个能不能也做一下的泥潭。我根据自己的经验把RAG增强单轮对话的边界拆成四层场景边界、知识边界、能力边界、技术边界。4.1 场景边界哪些输入不该接Step2.0的系统是单轮对话那就必须把单轮对话想清楚到底支持什么、拒绝什么。不支持的输入包括多轮指代类提问例如那如果试用期呢——它依赖前文系统当前版本无法正确处理。闲聊类内容例如你好呀你是谁——这类问题不需要RAG也能答且不属于知识问答的范畴。流程操作类请求例如帮我提交离职申请——这是动作执行不是知识问答需要集成工单系统不属于Step2.0范围。支持的输入则是业务领域相关的、表述相对完整的事实性问题。例如请假单最多可以提前多久提交公积金提取需要什么材料。你可能会问那些不支持的输入系统应该怎么响应这需要在Prompt和后处理里设计兜底回复比如当前版本暂不支持多轮对话请将您的完整问题重新描述后再提问。——明确不支持也是一种产品能力而不是缺陷。4.2 知识边界知识库里没有的就别硬答这是RAG项目中最容易让工程师纠结的边界。我见过无数团队为了让系统看起来更智能在检索不到内容的时候让大模型自由发挥。这样做短期看好像回答率提升了但长期看用户的信任会被消耗殆尽——他自己去翻一遍文档发现答案根本不是这个下次就不会再用你的系统了。知识边界的核心原则是知识库是答案的唯一边界。具体落地时我会设置一个无答案判定的机制如果检索引擎返回的最高相关度分低于某阈值比如0.4判定为知识库中可能没有相关内容;此时Prompt要求模型明确回答根据现有资料无法回答该问题;同时后处理层把这条记录标记为未覆盖问题进入待补充清单。这套机制还有一个额外收益它能自动帮你积累知识库的盲区告诉你哪些问题是用户想问但知识库里没有的反过来指导运营人员补充文档。4.3 能力边界RAG增强的是知识不是推理RAG能帮助大模型说出知识库里有的内容但它不能帮助大模型完成复杂的多步推理。比如用户问根据考勤管理规定员工A入职3个月实际工作天数不足30天请判断是否可以享受年假——这样的问题需要系统先抽取规则、再结合具体场景做推算不是简单的检索生成能解决的。对于这类复杂推理问题Step2.0的正确策略是明确告知仅支持基于知识库内容的查询和归纳不支持条件化推算。等后续需要支持这类场景时再考虑引入Agentic RAG或函数调用方案。4.4 技术边界什么时候用RAG什么时候用Agentic RAG什么时候不用RAG技术边界这个问题我在做技术选型评审时被反复问到这里统一梳理一下场景特征推荐方案原因知识相对固定、问题模式清晰经典RAG检索生成结构简单链路可控延迟低需要根据用户问题动态决定检索什么、检索几次Agentic RAG需要让模型自主规划检索步骤多个知识源需要交叉汇总Agentic RAG 多路召回单轮检索难以覆盖分散的信息源问题基本不涉及私有知识纯LLM直接回答引入RAG反而增加延迟和复杂度需要精确计算/结构化推理RAG代码解释器/函数调用纯文本检索生成无法保证计算准确性对于Step2.0我的判断是以经典RAG为主但架构上保留多路召回和Rerank的扩展能力。Agentic RAG目前仍在快速演进期推理开销大、稳定性不足除非业务确实需要否则不建议在第一步就上。4.5 场景延伸政务RAG项目中的边界取舍这里想多说一个我观察到的典型场景——政务知识库RAG。政务问答和一般企业知识问答最大的区别在于用户问题的表述不规范而且涉及大量办事流程细节。有人会问我要办退休怎么弄有人会问我爸退休了要办什么手续还有人会问社保交满15年了是不是就可以不交了。如果边界不清晰这类项目极其容易跑偏。我曾经接手过一个政务RAG项目业务方一开始希望系统能回答所有社保、公积金、医保相关问题结果上线后发现大量问题属于需要结合个人具体情况计算的类型RAG根本处理不了。后来我们把边界收窄为只回答政策规定类问题不回答个性化计算类问题回答准确率立刻有了质的提升。政务场景还特别强调引用溯源——答案必须标注依据了哪份文件、哪个条款。这就要求在RAG链路的输出层必须把命中的知识块编号映射到原始文档、章节、条款这是当初设计链路时就要预留好的能力等上线再补代价很大。5. 从目标到任务的拆解Step2.0要交付什么目标和边界都梳理清楚了接下来需要把它们翻译成具体的交付物和实施计划。这个翻译环节如果做得好项目执行会非常顺做得不好就会出现目标很丰满落地很骨感的情况。5.1 交付物清单根据前面的目标和边界定义Step2.0的完整交付物包括数据侧交付物评测集100~200条含标准答案、关键文档ID、难度标注知识库切分与索引更新脚本支持增量更新检索侧交付物混合检索服务BM25 向量召回 RRF融合Rerank服务可选但建议做检索结果分数归一化逻辑用于无答案判定生成侧交付物Prompt模板管理模块支持版本切换、A/B测试生成结果后处理模块引用标注、格式化、无答案文案校验请求日志与效果追踪中间件记录检索内容、生成内容、用户反馈评测交付物评测脚本自动跑分 报告输出评测结果可视化看板可选但用于向领导汇报很有效5.2 任务优先级排序不是什么都要排在第一优先级。我在实际操作中会把任务分成P0、P1、P2三个层级P0必须完成否则系统不可用评测集第一版建立至少50条核心问题混合检索链路打通基本Prompt模板 无答案兜底基础日志采集P1强烈建议完成大幅提升质量Rerank服务的接入评测集扩充到150条以上生成结果后处理 引用标注基于评测集做第一轮系统调优P2条件允许时再考虑Prompt版本管理平台用户反馈收集与自动标注多路召回策略扩展5.3 里程碑节奏怎么安排我以一个三人小团队1个开发、1个测试数据标注、1个产品/项目经理为例给出一个参考节奏第1~2周评测集建设 知识库数据清洗与切分第2~3周混合检索链路开发跑通离线检索评测第3~4周生成链路开发Prompt编写端到端联调第4~5周评测跑分 第一轮调优查漏补缺第5~6周上线部署 线上日志监控 效果基线确认这个节奏的核心思想是评测集先行链路随后调优闭环。如果评测集迟迟建不起来后面的一切都是在盲人摸象。5.4 和上下游系统的衔接RAG系统从来不是孤立的。在Step2.0的交付阶段至少要考虑两个系统边界的衔接上游知识库更新机制。知识库不会一成不变需要有一个明确的文档入库、更新、废弃流程。实际操作上最简单的做法是做一个文档变更监测脚本当文档目录下的文件发生变更时自动触发解析、切分、向量化、更新索引。不要依赖手工重新导入。下游用户反馈回路。用户点有帮助/没帮助的反馈数据最终要回流到一个可以分析的地方。我通常的做法是在日志里打点把问题、检索到的内容、生成的答案、用户反馈绑定存储然后定期统计不同知识分类的回答满意率。这样后续做迭代优化时资源投入最集中。6. 实测复盘边界没划清会踩的坑最后这部分我把自己在真实项目里踩过的、以及同行交流中反复出现的几个坑总结一下希望能帮你少走弯路。6.1 坑一知识库没有答案时模型开始自由发挥这是我见过最普遍、也最致命的问题。很多团队的Prompt里明明写了如果资料中没有答案请回答不知道但模型还是会言之凿凿地编一个答案出来。为什么因为大模型的训练目标就是给出合理回答它天然倾向于不承认自己不知道。有时候是Prompt的表达不够强模型把资料中没有理解成了资料可能不完整但我可以根据常识补充有时候是检索系统返回了低相关的材料模型把那些材料当作依据顺着编了下去。我的解决方案是做一道硬闸门在路由层和后处理层同时做控制。路由层判断检索结果的相关度分是否达标不达标就不进入生成后处理层检查生成结果中是否出现了明显的超出材料的内容。两层控制虽然不完美但至少能堵住大部分自由发挥的case。6.2 坑二把多轮场景硬塞进单轮架构这个坑和产品相关。业务方经常会说用户说那如果试用期呢你系统应该能接住啊这不就是一个很简单的指代理解吗——听起来简单但做起来是另一套体系指代消解、上下文管理、对话状态跟踪这些都需要额外的模型和架构设计。Step2.0的边界就是单轮。如果业务方确实有强烈的多轮需求正确的做法是在Step2.0的需求里定义一个问题改写接口多轮对话的问题在进入主链路之前先由一个模型结合上下文把指代补全。但这是独立的一个组件复杂度和风险都不低不建议在当前阶段做进去。我的建议是明确告知业务方这个能力排期在Step3.0当前版本系统遇到指代不清的问题时会如实告知用户重新描述。6.3 坑三全链路调完之后才发现评测集没建有个项目团队花了三周时间把链路全部打通效果看起来好像还行。然后产品负责人问了一句你能证明它行吗——全场沉默。这就是评测集没有先行的后果。等你想起来要建评测集的时候链路已经跑起来了你拿什么数据去建真实日志里全是坏case专家标注又要重新协调。最后只能再花两周补课项目延期。我现在做任何RAG项目第一件事永远是先拉20条种子问题把评测集框架立起来哪怕是手工标注、格式不完善都好。有了这20条就能开始验证链路验证完链路再逐步扩到100条、200条形成一个评测集随项目演进的滚动态势。6.4 坑四只关注答案对错忽略了响应体验单轮对话也讲究体验。用户从输入问题到看到答案如果超过5秒就会明显产生焦虑感。而RAG链路涉及检索、重排、大模型生成多个环节任何一环慢一点整体延迟就会失控。我的经验是要提前做延迟预算比如检索重排控制在1秒以内大模型流式输出首字时间控制在2秒以内总体响应时间P95不超过5秒如果首字时间过长优先检查是不是Prompt里塞了太多无关内容如果检索阶段变慢优先检查向量索引有没有Build合理。RAG项目的延迟问题九成出在链路上不是出在某一个环节的模型推理速度上。6.5 再分享一个有用的经验把边界判定规则写进日志这个技巧是我做第二个RAG项目时才悟出来的。系统上线之后线上会因为各种各样的边界情况产生大量非预期输出——比如用户问TODO工具怎么用知识库里没这内容模型可能回答未找到相关信息也可能顺带说一句您可以尝试在帮助中心搜索。如果你只记录用户问题和最终答案事后分析时根本不知道系统当时是走了哪条路径。所以我在日志里加了一组边界判定标志是否命中检索检索分是多少是否通过了相关性阈值是否走了无答案兜底这样每次线上case回放时可以快速判断系统为什么给出这个回答、边界逻辑有没有被绕过。这组日志相当于给系统装了行记录仪——平时用不上但出问题排查时它就是唯一能还原事发过程的证据。做RAG增强的单轮对话说到底不是调通一条链路那么浅也不是接一个大模型API那么简单。真正决定项目成败的往往不是技术栈选得多新、模型参数多大而是你有没有在动手之前把目标和边界想透、写清并且让全团队达成一致。我这几年做下来的体会是边界清晰的项目进度和质量都可控边界模糊的项目再强的团队也会被各种需求拉扯到失焦。希望这份目标与边界梳理的思路能让你在Step2.0这个阶段少踩几个坑。如果你正在做RAG相关项目欢迎在评论区聊聊你遇到的最棘手的边界问题也许我能帮你拆一拆。