这一篇我们聊聊 RAG。做 Agent 相关的内容也有一段时间了后台收到最多的问题不是“模型怎么选”而是“我的 Agent 总是答得很敷衍明明系统里就有资料它却视而不见”。这类问题几乎都出在同一个环节——知识获取。LLM 的知识都是训练时固化的你上个月签的客户合同、公司内部的新版流程、昨天刚发布的政策文件它一概不知道。所以要让 Agent 真正干活你必须给它接一条知识获取管道RAG 就是这条管道最基础也最实用的实现方式。这篇内容定位在“基础”适合正在从 0 到 1 搭建 Agent、希望搞懂知识是怎么从资料库流进模型输出的读者。不需要你读过之前几篇只要知道 Agent 是“模型工具记忆”的组合即可。1. 为什么 AI Agent 绕不开 RAG1.1 模型再聪明也有知识天花板大模型本质上是一个“知识固化的概率系统”。训练完成的那一刻它的知识就被冻结在参数里了。你问他一个训练数据截止日之后的问题它只能靠推测和编造来回答你问它某个企业内部的知识它更是完全没见过。很多非技术背景的同学会把大模型想象成一个“无所不知的超级大脑”实际上它更像一个读过海量书籍、但毕业后就不再更新的学生。Agent 一旦被部署到真实业务里面对的一定是动态变化的知识产品手册会更新、法务条款会调整、销售话术每个月都在变。如果 Agent 的知识来源只有模型参数那它每回答一处新问题都是在拿“毕业时的旧知识”硬扛“毕业后的新世界”。参数化知识还有一个更麻烦的问题幻觉。模型在不确定时会“自信地胡说”而且你很难在事后追问它“你这话是哪儿来的”。企业场景里客户问一个理赔条款Agent 编造出一个不存在的规则哪怕只发生一次业务方也会对整个系统失去信任。所以把知识外置、把“依据”做成可追溯的东西不是可选项而是必选项。知识获取管道的核心作用就是让模型不再凭记忆硬答而是先查资料、再说话并且能说出出处。1.2 RAG、微调和长上下文怎么选搞知识注入市面上不止 RAG 一种思路常被拿来比较的是微调和长上下文。很多初学者一上来就纠结“要不要微调一个专属模型”这里直接给出我的选型经验你可以少走弯路。微调的本质是调整模型的行为模式和表达能力比如让模型输出更简洁、更符合某个特定口吻。但如果你只是想让模型知道“某些文档里有答案”微调是典型的杀鸡用牛刀。它要准备训练数据、要算力、要反复试参数而且每次文档更新都要重跑一轮训练这个周期在业务场景里根本等不起。长上下文则是把相关文档整段塞进提示词里让模型“现场阅读”。对大模型来说单次上下文窗口确实已经从几万扩展到了百万级但输入 token 是有成本的而且超过一定长度后模型的有效注意力会衰减也就是“中间迷失”现象——你塞了一大堆资料它偏偏漏掉最关键的那段。长上下文比较适合“一次性读完几份固定文档”的场景不适合高频、动态、大体量的知识问答。把三者放在一起看就很清楚了RAG 的优势在于知识可增量更新、可删除、可追溯、成本可控而且每一次问答都能带上出处。微调负责“性格”RAG 负责“记忆”长上下文负责“临时阅读”。大部分人需要的不是把模型重新训练一遍而是给它接一条能持续供水的知识管道。方案知识更新速度可追溯性成本适合场景RAG快改文档即可生效强每条回答可标注来源较低按检索与生成计费动态知识、企业私有文档、问答、客服微调慢需重新训练弱无法解释来源高需要训练算力风格迁移、特定任务行为约束长上下文中随提示词变化中取决于你塞了什么高输入 token 昂贵单次阅读固定长篇资料1.3 全局认识 RAG 这条管道把 RAG 想象成一套自来水系统思路会非常清晰。文档就是水源里面混合着各种杂质向量数据库是蓄水池把水净化、分类、储存起来检索器是水管用户提问就像打开水龙头大模型则是净水器把水加工成能直接喝的东西。整条管道分三个阶段。离线索引阶段你要把原始文档加载进来做清洗、切分、向量化最后存入向量库在线检索阶段用户来了一个查询你先对查询做理解或改写再去向量库和关键词索引里捞一批候选文档生成合成阶段把捞回来的候选文档重排序、剪裁、连同查询一起组装成提示词交给大模型生成答案。很多人以为 RAG 就是把文档灌进向量库然后搜索这其实是把问题想简单了。真正影响系统效果的不是某一个环节而是整条管道的协同切分粒度影响召回质量向量模型影响语义匹配重排序影响最终上下文提示词组装影响答案忠实度。后面几个章节我会把这条管道一段一段拆开讲。2. 知识入管道离线索引环节2.1 数据接入先搞清楚源头能喝到什么水离线索引的第一步是加载文档。这一步看似简单实际能踩的坑非常多。不同业务的数据来源五花八门有 PDF、Word、Markdown、HTML、数据库里的字段、接口返回的 JSON甚至还有扫描件和音视频转写文本。PDF 是我最想吐槽的格式。有些 PDF 看着排版整齐解析出来的文本却是错乱的段落顺序颠倒、表格完全散架、页眉页脚混进正文。扫描件更麻烦要接 OCR识别质量直接决定后续检索的上限。我刚做企业知识库时吃过一个大亏一份几十页的合同 PDF解析出的文本中金额数字带着“特殊字体”向量化之后完全搜索不到。所以数据接入阶段一定要增加“清洗”环节——去页眉页脚、去空行、修正编码错误、对表格做结构化提取宁可多花时间做预处理也不要让脏数据流进蓄水池。数据库和接口数据则要考虑“怎么转成文本”。一条结构化的客户记录适合序列化成自然语言比如“客户名称某某科技行业制造业上次跟进时间2026 年 2 月需求MES 系统选型”而不是直接把 JSON 原样切块。向量模型对连续自然语言的理解能力远强于对散落字段的理解这个细节很多人会忽略。2.2 切分策略太小漏语义太大混主题文档加载进来之后不能一整篇扔给向量模型因为 embedding 模型有输入长度限制而且一整篇文档的向量只能代表“大概主题”细节全部被平均掉了。所以必须切分也就是 chunking。切分粒度是个经典难题。切得太小比如一刀切 128 个字符语义单位不完整一个条款被劈成两半检索时匹配不到切得太大比如每块 2000 字块内可能混了好几个主题向量被揉成“四不像”相似度上去了但包含真正答案的位置可能淹没在无关内容里。我常用的起点是 512 到 1024 个字符但这不是硬规则要根据文档类型调整。切分方法上固定长度切分是最省事的但极不推荐它会把一句话从中间截断。稍微好一点的是递归字符切分按照“段落 → 句子 → 标点”的优先级层层下探在尽量不破坏语义边界的前提下控制长度。再进阶一点的做法是结构化切分Markdown 文档按标题切、代码按函数切、表格按行切还有一种父块子块策略对每个小段子块做向量化检索到子块后把它的父段落一起交给模型这样既保证召回精度又给模型提供了完整上下文。切分时还要记好元数据。每个块必须带着标题、来源文件、页码、章节路径、更新时间最好再有权限标签。这些元数据后面有两大用途一是检索时做过滤比如“只查技术文档、不查公告”“只返回用户有权限看的内容”二是生成答案时做引用溯源让用户知道这句话出自哪份文档的哪一页。没有元数据的块就像丢了标签的档案存得越多越难用。2.3 Embedding 选型不同语言、不同行业差距很大文本切块之后要转成向量这就轮到 embedding 模型登场。选 embedding 模型首先看语言支持。中文场景如果硬用一个英文主导的向量模型检索效果会明显打折——中文的专有名词、成语、口语化描述往往匹配不准。国产的开源模型里BGE 系列在中文语义匹配上表现不错很多实际项目都在用。其次看领域适配度。通用模型在法律、医疗、制造这种专业术语密集的领域效果会明显下降。我有一次做医疗问答用通用 embedding 模型检索患者描述“头疼、恶心、视力模糊”召回结果里总是混着感冒和偏头痛的内容后来换了在医学语料上微调过的向量模型问题才消失。如果你所在的行业术语极其特殊可以考虑准备一批历史问答对在开源 embedding 模型上做领域微调这通常比堆更多数据更有效。向量存储环节也需要选型。轻量原型阶段用 Chroma、FAISS 就够生产环境数据量上了百万级、并发一高就得考虑 Milvus 这类专用向量数据库如果公司本来就有 PostgreSQL用它的 pgvector 插件最省运维成本如果检索还要支持复杂的全文搜索和过滤Elasticsearch 这种已经内置向量检索能力的老牌搜索引擎也是常见选择。选型核心就看四个维度数据规模、并发量、是否需要复杂过滤、团队熟悉哪套技术栈。方案定位优点适用场景Chroma嵌入式向量库轻量、易上手、适合原型本地验证、小规模开发FAISS向量检索库检索性能强、灵活对库管理要求低的中等规模Milvus专用向量数据库支持分布式、丰富索引类型大规模生产、高并发pgvectorPG 插件与业务数据同库存储、事务一致已有 PostgreSQL 的中型项目Elasticsearch搜索引擎全文检索向量检索一体需要复杂混合检索与过滤3. 水龙头怎么开在线检索与生成3.1 查询改写与意图识别用户不会按照你精心设计的检索格式来提问。真实环境下query 可能是口语、有指代、有错别字甚至一次问了一串问题。把用户原始提问直接丢给检索器效果往往不好。举个例子用户问“它这个保修政策跟上一个版本比怎么样”这个“它”指代什么“上一个版本”又是什么检索器根本无从下手。所以在线检索的第一步是查询理解。让大模型先把用户问题改写成适合检索的形式补充指代、拆解多问题、提取核心关键词。改写 prompt 可以写得很简单“根据对话历史和原始问题生成 2 到 3 个适合向量检索的关键词组合保持与原问题语义一致。”这一层虽然只花一次模型调用但对召回质量的提升非常明显。注意改写时不要过度发挥核心语义要保持不变否则检索到的内容会偏离用户需求。如果知识库有明确的类目结构还可以做查询路由先判断用户问的是产品、合同还是技术支持决定去哪个子知识库检索甚至决定要不要去调用数据库或外部 API。路由判断本质上就是一个分类任务用大模型做 few-shot 分类或者用轻量分类器都行。这一步能让检索的候选集更精准减少跨类目干扰。3.2 混合检索稠密加稀疏结合只用向量检索早晚会碰到一个尴尬场景用户输入的是精确的产品编号、合同号、人名向量相似度反而排不到最前面。因为向量检索擅长“语义相似”而精确匹配类查询需要的是 token 级完全一致。解决办法是混合检索同时跑两条路。一条路是向量检索稠密检索把 query 和文档块都编码成向量算余弦相似度擅长处理同义改写、语义相关另一条路是稀疏检索类似传统 BM25按关键词重叠度打分擅长精确命中、专有名词、编号类查询。两条路的结果做融合排序最常用的就是 RRFReciprocal Rank Fusion把每条结果在两个列表中的排名取倒数并求和综合排序。实践中混合检索的命中率通常比纯向量检索高 10 到 20 个百分点尤其知识库里代码编号、产品型号多的时候差距更明显。很多向量数据库现在都内置了混合检索接口Elasticsearch 更是天然就适合这套玩法。实现时可以先用文本检索拉一批候选再向量检索拉一批候选合并去重后统一送重排序。你不需要在一开始就把这套做得很复杂但一定要给架构留出扩展位否则等发现问题再改成本就大了。3.3 Rerank让最相关的排到第一位检索召回回来几十个候选块直接一股脑塞给大模型是不行的。先不说 token 成本关键是顺序问题——大模型对排在后面的内容关注度会下降如果最相关的那块排在第 30 位答案质量会大打折扣。这时候需要重排序模型。向量检索引擎里的相似度计算用的是“粗粒度”的双塔模型速度快但不够精细。Reranker 则用交叉编码器把 query 和文档块拼接起来一起过模型逐字交互能更准确地衡量这对组合的相关性。工程上常见做法是两阶段向量/混合检索召回 Top 50再用 Reranker 重新排序取 Top 5 送进提示词。用一个精准但慢的模型去处理五十个候选比直接让这个模型去全库检索划算得多。我之前的一个项目没有加 Rerank 之前用户问“退货流程”召回结果里出现大量关于“退款时间”的内容语义相关但答非所问加了 Rerank 之后排在首位的文档从“退款相关”变成了“退货流程具体步骤”端到端满意度一下子提升了。如果你的检索质量已经不错但答案总觉得“差点意思”优先排查 Rerank 有没有做。3.4 组装 Prompt 与引用溯源一切检索、重排的努力最终都要汇入提示词。不要简单粗暴地把检索到的内容拼成一个长字符串塞进系统提示词要结构化。我常用的格式是给每个文档块编号并在提示词里明确要求模型“请基于编号标注的资料作答如果资料中没有信息直接说明你无法回答不要编造引用资料时请标注对应编号。”这里有两个关键点。第一要明确设定“不可见即不知”。没有 RAG 系统的模型会有“强行回答”的倾向通过提示词约束可以显著降低幻觉但注意这不是万能的还是要靠检索内容本身的质量。第二引用溯源不只在提示词里要求后台要把召回块连同其元数据一起记录到日志前端可以把“资料来源”展示给用户。一个能点击出处的答案比一个完美但无依据的答案在业务端更可信。组装时还有一个细节控制输入长度。Top 5 个块每块 500 字加上历史对话和 system prompt一次请求的 token 量可能上万。要对块做冗余去除和截断把明显无关的块丢掉而不是盲目追求“召回的块越多越好”。召回的块越多模型被干扰的概率越大生成延迟也跟着涨。4. 从 0 到 1 的最小 RAG 工程实现4.1 技术栈清单不同语言能力圈的选型动手写代码之前先把技术栈定下来。Python 生态最成熟LangChain、LlamaIndex 这些框架把加载、切分、检索、生成全流程都封装好了适合快速验证和原型迭代。Java 服务端团队则可以考虑 Spring AI 和 LangChain4jSpring AI 提供了相对完备的 RAG 支持包括向量存储抽象、文档加载器和提示词模板配合 Spring Cloud 可以做企业级服务平台。Embedding 服务和 LLM 服务可以走本地部署也可以走云端 API。本地部署可以用 Ollama、vLLM 等工具跑开源模型优势是数据不出内网、可控性好云端则注意选择支持国内合规、接口兼容的服务。关于身份验证我特别提醒一句生产环境一定不要把 API Key 写死在代码里要用环境变量或密钥管理服务这个看似基本的操作我在不少项目里都见过翻车。下面给出一套最小可跑的实现以 Python LangChain 风格的代码演示你换用其他框架也是同一套逻辑。4.2 一次完整的最小实现先看离线索引阶段。假设本地有一个 docs 目录里面放了几篇 Markdown 格式的企业文档from langchain_huggingface import HuggingFaceEmbeddings from langchain_community.vectorstores import FAISS from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.document_loaders import DirectoryLoader # 1. 加载文档目录下的所有 Markdown 文件 loader DirectoryLoader(./docs, glob**/*.md) documents loader.load() # 2. 递归切分同时保留元数据 splitter RecursiveCharacterTextSplitter( chunk_size512, chunk_overlap64, separators[\n\n, \n, 。, , , , , ] ) chunks splitter.split_documents(documents) # 3. 用开源中文向量模型编码 embeddings HuggingFaceEmbeddings(model_nameBAAI/bge-small-zh-v1.5) # 4. 构建向量库并本地持久化 vectorstore FAISS.from_documents(chunks, embeddings) vectorstore.save_local(./faiss_index)这段代码的逻辑就是加载 → 切分 → 向量化 → 入库。RecursiveCharacterTextSplitter 里的 separators 顺序很重要它决定了切分的优先级先把长段落按空行拆开再往下拆长句子。chunk_size 定 512、overlap 定 64这是比较中庸的起点后续根据你的文档类型再调。检索和生成逻辑这样写from langchain_huggingface import HuggingFaceEmbeddings from langchain_community.vectorstores import FAISS from langchain_openai import ChatOpenAI from langchain.prompts import PromptTemplate embeddings HuggingFaceEmbeddings(model_nameBAAI/bge-small-zh-v1.5) vectorstore FAISS.load_local(./faiss_index, embeddings, allow_dangerous_deserializationTrue) retriever vectorstore.as_retriever(search_kwargs{k: 5}) docs retriever.invoke(公司年假政策是什么) context \n\n.join( f[{i1}] {doc.page_content} (来源: {doc.metadata.get(source, 未知)}) for i, doc in enumerate(docs) ) prompt PromptTemplate.from_template( 基于以下资料回答问题如果资料中没有相关信息请直接说无法回答。\n 回答时要标注引用编号。\n\n资料\n{context}\n\n问题{question} ) llm ChatOpenAI(model你的模型名称, base_url你的兼容接口地址) chain prompt | llm answer chain.invoke({context: context, question: 公司年假政策是什么}) print(answer)这段代码演示了最核心的检索增强生成链路。注意两点一是加载向量库时 FAISS 有反序列化安全机制生产环境不要随意加载来源不明的索引文件二是 retriever 的 k 值先设 5跑通之后再调。如果你已经在用 Spring AI核心逻辑也完全一致无非就是定义 DocumentReader、TextSplitter、VectorStore 这些 Bean再配一个 RetrievalAugmentationAdvisor。框架不同但“知识获取管道”的架构设计是通用的。4.3 衡量管道好坏不能只看“好像能答”很多人做完最小实现测了两三个问题就觉得完成了。这是很大的误区。要真正判断管道质量必须建立评测集。评测集可以是 30 到 50 条历史真实问题每条问题标注标准答案和对应的源文档。然后跑四个经典指标命中率Hit Rate是最直观的看检索结果里是否包含标准答案所在的文档反映出检索器是否有效MRR 关注标准答案文档排在第一位的情况衡量排序质量忠实度Faithfulness判断生成答案是否严格来自检索到的文档是否偏离资料内容答案相关性衡量生成内容是否真正回应了用户提问。RAGAS 这类开源库可以帮你算后两个指标但即便不用工具人工抽样审几十条答案也比啥都不测强。积累评测集是一个持续过程。每次线上遇到用户反馈“答得不对”就把这个问题沉淀进评测集然后回归跑一轮。这套机制看起来笨拙却是让 RAG 系统持续变好的唯一可靠路径。5. 我踩过的坑常见问题排查实录5.1 一套能救急的诊断流程系统上线后最常见的情况是用户说答得不对但你不知道为什么。我的排查习惯是“先检索引擎再生成环节”顺序一定不能乱。第一步把线上那条用户问题单独拿出来直接打印检索召回的 Top 5 结果用肉眼判断这些块到底相不相关。如果这一步就不相关问题出在召回侧跟模型生成能力强弱没有关系。第二步如果召回块相关但生成结果不对问题出在生成侧重点检查提示词约束是否足够、上下文是否截断、是否被无关块干扰。第三步如果 Top 5 里相关块排得靠后优先检查 Rerank 是否配置正确。第四步如果个别问题召回不好但整体不错大概率是数据覆盖和切分粒度的问题。这套流程我建议你做成一个可视化调试面板把每次检索的 query、召回块、得分、重排结果、最终答案和引用来源都记录下来。调 RAG 本质上是调数据没有日志做支撑你跟盲人摸象没有区别。5.2 高频问题速查表现象可能原因解决思路检索结果完全为空查询改写过于发散Embedding 模型与文档语言不匹配检查改写后的 query 是否偏离原意换用中文专项 Embedding 模型文档里明明有答案却召不回切块太大主题混合专有名词靠语义向量匹配不到调小 chunk_size增加 overlap启用 BM25 混合检索召回了相关文档但最终答错缺少 Rerank相关块排位靠后提示词约束不够接入交叉编码器 Rerank加强“无信息不可编造”约束回答内容编造事实检索到的弱相关块被模型当依据提示词未限死提高召回阈值、只把高相关块送入上下文提示词明确“资料中无答案就说不知道”知识更新后回答问题仍是旧内容向量库没有增量更新或旧块未被清理每次文档变更后重跑索引管道加入文档版本号并清理旧版本中文语义联想效果差用了英文向量模型或者未做领域适配换成 BGE 等中文模型必要时在领域语料上微调检索到无权限的敏感数据没有在检索阶段做元数据过滤索引时给每个块打权限标签检索时强制按权限标签过滤系统响应太慢检索链路过长、Rerank 候选集太多、上下文超长控制召回候选在 50 条以内、重排后只取 Top 5增加缓存5.3 几个容易被忽视的细节RAG 系统的不少问题出在小细节上这里专门提几个我踩过的坑。第一个是查询改写“过度发挥”。有时候原始问题已经足够清晰甚至包含专有名词改写反而把核心关键词稀释了。所以改写前要加一个判断逻辑如果 query 是常规问题且无指代可以跳过改写直接检索。第二个是向量库的旧数据清理。增量更新时如果只进不出库里的过期文档会和新文档竞争排序导致回答混乱。务必让每个文档块携带版本号更新时按版本号清理旧块。第三个是模型生成长度限制。有些模型 max_tokens 默认是 512输出稍微长一点就截断用户看到的是答案只说了一半。排查“答得不对”的时候先扫一眼输出有没有被截断。第四个是召回阈值配置。有些向量数据库支持 score threshold但阈值设置过高会把弱相关但有效的答案也给滤掉。建议先不设阈值靠 Rerank 和人工评估来判断哪些关联度可以接受积累数据后再定策略。6. 从 RAG 到 Agentic RAG以及给新手的建议6.1 下一代知识获取管道长什么样基础的 RAG 是“检索一次生成一次”链路是线性的。但真实业务里一次检索往往解决不了复杂问题。比如用户问“我今年的项目预算还剩多少”这个问题既要查文档了解预算规则又要查数据库看实际支出还要对比项目状态。这就是 Agentic RAG 的用武之地——把知识获取从“一次性调用”升级为“智能体的决策过程”。Agentic RAG 有几个明显特征。首先是查询路由Agent 判断这个问题该去哪个知识库、哪个工具、哪个数据源找答案而不是所有问题都丢给同一个向量库其次是迭代检索Agent 在生成过程中发现自己缺乏某段信息会主动发起一轮新的检索甚至改变检索策略第三是工具协同把 RAG 和数据库查询、API 调用组合在一个执行流程图里。这个阶段你可能会用到 LangGraph 这类编排框架或者直接写一套工具调用的循环。再往深走还有 GraphRAG 和本体 RAG 这类方向。GraphRAG 把实体和关系建成图结构擅长回答“哪些客户同时关注了这两类产品”这类跨文档关系型问题本体 RAG 则在检索时引入领域概念体系让系统理解“内存”和“存储”在特定语境下的关联。这些都是知识获取管道的进阶形态但核心思路没变仍然是“先用合适的检索手段把相关材料找全再让模型基于材料作答”。6.2 给正在搭管道的你几个建议做 RAG 这么久我的总体感觉是这是一个“木桶工程”加载、切分、向量化、检索、重排、生成哪一块短了整体效果都上不去。下面几条建议是给准备动手做知识获取管道的同学的个人经验。第一先手工梳理二十到三十条典型问题再开始搭代码。这 30 个问题就是你后面的评测基线没有基线你根本不知道自己是在优化还是在恶化。第二不要迷信某一个环节的花哨参数先看看数据质量。很多“检索效果差”的问题根源是 PDF 解析错乱、元数据丢失、切块切碎了条款这些基础工作做好了效果自然上来。第三把“来源引用”作为上线硬要求而不是加分项。有引用的 RAG 系统无论准确率怎样至少能给业务方一个复核的抓手这对建立信任太重要了。第四先离线批测再上线灰度。哪怕流程简陋先在评测集上跑一轮再放流量也比直接拿用户体验当测试强百倍。6.3 最后补充一个关于更新的细节知识获取管道上线后最容易被忽略的就是“更新机制”。我见过很多项目向量库建完之后就再也没重建过半年后文档改了三版系统还在回答老内容。更新机制要设计成可重复执行的管道而不是一次性脚本每次文档变更自动触发重新加载、切分、向量化的流程并且对旧块做版本替换。你可以在服务里接一个事件监听也可以每天定时跑增量任务但一定要保证管道能重复跑而且跑完的结果是可验证的。这个细节决定知识获取管道能不能长期活下去。初次搭建时把更新机制纳入设计范围比后期打补丁要省力得多。最后说一点个人体会。我做过好几个 RAG 相关项目最大的感受是决定 Agent 智商上限的往往不是模型本身而是它身后的知识获取管道。模型可以随时换更强的但管道里积累的数据、切分策略、检索规则和评估用例才是真正珍贵的部分。每次优化知识获取管道本质上都是在给 Agent 做“知识补钙”这个基础打得越扎实后面无论接多复杂的 Agent 编排都能站得稳。如果你正准备从 0 到 1 搭一个带知识库的 Agent别急着调模型参数先把这条管道的前端到后端完整走通再用评测集一点点打磨这才是投入产出比最高的路径。