大模型技术栈精讲：Transformer、RAG、微调与智能体实战

1. 先从基础聊起当我们在说“大模型”时到底在说什么把时间拉回到2022年底ChatGPT一出来几乎所有做技术的人都能感受到那种冲击——原来机器可以这样“说话”。但热闹归热闹真正要把它落进自己的项目、业务甚至论文里光会用聊天界面远远不够。你至少得搞清楚三件事它为什么这么能打、它怎么才能更懂你的业务、以及如何不花冤枉钱就让模型干好事。这篇文章不是那种把一个知识点翻来覆去讲两万字的教程而是想用一位工程实践者的视角把大模型技术栈里四条主线串起来Transformer不管GPT、Qwen、Llama还是DeepSeek底层都是它的变体不理解它后面所有操作都是空中楼阁。RAG检索增强生成解决模型“不知道”和“瞎编”这两个老大难问题的当前最佳实践。微调让模型具备领域性格、说话方式或私有知识的关键手段。智能体Agent把模型从“回答问题”变成“完成任务”这是大模型真正进入工作流的方向。适合谁来读呢如果你是刚入门大模型、只会调API但不知道内部发生了什么的开发或者你已经在做RAG和微调但总觉得哪里差一口气想系统查漏补缺又或者你想在企业里汇报“AI能干点啥”却不知道怎么动手——这篇文章就是给你准备的。先说好我不打算把代码全部贴出来只贴关键步骤和遇到坑的地方。我会尽量把每个选择背后的原因讲清楚因为大模型项目跟传统软件开发最大的不同在于它不是一个“改bug”的过程而是一个“做实验、拍配置、看指标”的过程理解设计思路往往比抄代码更值钱。2. Transformer大模型这座大厦的地基2.1 注意力机制——模型凭什么知道你说了什么讲大模型不提Attention是不行的但我尽量不绕弯子。早年做机器翻译大家用RNN/LSTM一句话读进去从左往右一个词一个词地推进最后一个时间步的隐藏状态里要塞下整句话的意思。这个设计有天然缺陷——句子一长前面的信息会被后面的信息“稀释”掉字面意思就是模型读到句号的时候已经快把句首的主语给忘了。2017年Google那篇Attention Is All You Need给出了一个完全不同的做法句子里的每个词都去跟句子里的所有词计算“相关性”然后用相关性加权融合所有词的信息。这就是自注意力机制。它跳过了“按顺序读”这个限制任何位置的词都直接能跟任何位置的词建立关系长距离依赖不再是问题。这里有个初学时容易懵的点就是Q、K、V到底什么意思。我的理解方式是这样QQuery问句当前这个位置想从别人那里获取什么信息。KKey标签每个位置能提供什么信息以及它跟Q有多匹配。VValue内容一旦匹配上实际把内容贡献出来。打分的方式就是Q和K做点积再除以(\sqrt{d_k})做缩放进softmax变成权重最后跟V做加权求和。那为什么除以(\sqrt{d_k})一个说得通的解释是维度越高点积的数值方差就越大这会把softmax推到两极化一个接近1其余接近0梯度很容易就消失了。除以(\sqrt{d_k})是为了把方差拉回到一个合理的范围让训练更稳。所以你现在再看到一行代码import torch.nn.functional as F # scores: [batch, heads, seq_len, seq_len] attention_weights F.softmax(scores / (key_dim ** 0.5), dim-1) output torch.matmul(attention_weights, values)心里应该清楚每一行在干嘛了。2.2 位置编码和Embedding的那些细节注意力机制本身是“无序”的——你把一句话打乱顺序丢给它计算出的每个位置之间的关系跟顺序完全无关但这显然不符合语言逻辑。于是Transformer引入了位置编码。训练出来的位置编码很简单给每个位置一个可学习向量而经典的正弦位置编码是拿不同频率的sin/cos函数去生成位置向量。原版论文用的是后者原因是它可以外推到训练时没见过的更长序列。到了GPT时代位置编码又简化了。GPT系列用的是“可学习位置编码”直接让模型在训练时自己学每个位置长什么样。而最近的一些模型比如RoPE旋转位置编码则是把位置信息旋转地“注入”到Q和K里让模型能更自然地理解相对位置。至于Embedding它是把token序列转换成稠密向量的第一道工序。一个token经过embedding层变成一个比如4096维的向量。这里有个常见误解Embedding层本身是一个查表操作不是神经网络运算真正决定词向量“语义”的是整个模型的训练过程。我在“动手学大模型”那个GitHub仓库里看到过一个不错的比喻Embedding好比把每个词放进一个多维空间语义相近的词会落在邻近的位置语义相反的词会被拉开而Transformer的每一层其实就是在不断“修正”每个向量的位置让它越来越贴合当前语境下的真实含义。2.3 为什么Transformer训练快、效果好传统RNN没法并行——当前时间步一定要等前面所有时间步算完才能推进。Transformer则不一样所有位置同时计算GPU的并行能力被充分利用这让它可以一口气在数十亿甚至万亿token上预训练规模效应从此起飞。再加上残差连接和LayerNorm深层网络训练起来也不容易崩。你去看GPT、Qwen的模型结构基本就是多层Transformer Block堆叠每一层包含多头自注意力、前馈网络、残差连接和归一化。整个架构简洁到近乎朴素但大规模数据和算力堆上去之后涌现出的能力in-context learning、思维链、代码理解是早期研究完全没预料到的。这里我给一个“手写简化版”的前向计算伪代码帮你建立直观感受。真正的实现比如用PyTorch写GPT远不止这些但核心骨架就是下面这些步骤# 伪代码单层 Transformer Block 前向 def transformer_block(x, attn, ff, norm1, norm2): # x: [batch, seq_len, hidden_dim] residue x x norm1(x) x attn(x) # 多头自注意力 x x residue # 残差连接 residue x x norm2(x) x ff(x) # 前馈网络通常是 MLP x x residue # 残差连接 return x如果你想上手试试我建议先去跑一个最小GPT训练自己的“莎士比亚生成器”不用追求效果关键是理解“输入token怎么变输出概率”这条链路。很多做RAG和微调的人之所以在后续踩坑就是因为对模型内部的这个“概率预测”本质缺乏感知——大模型本质上就是一个超级强的条件概率模型给它前面一串token它预测下一个token是什么。3. RAG让模型“张开眼睛”看业务数据3.1 为什么单个模型永远做不到“什么都懂”每个大模型都有知识截止日期即便GPT-4级别的模型它也不知道它训练完之后这个世界发生了什么。更重要的是企业内部的知识库、规章手册、产品文档、用户对话记录这些私有数据根本不在任何开源模型的训练语料里。微调能让模型记住部分知识但代价高、更新麻烦、还可能破坏原有能力。RAG的思路完全不训模型而是“让模型在回答问题之前先去查资料”。整个链路非常直白把文档切块、向量化存进向量数据库。用户提问时把问题也向量化在库中召回最相关的Top-K个片段。把问题片段提示词模板一起拼到上下文里交给大模型生成回答。这样模型每一次回答都是基于最新、最相关的资料而不是它自己脑补。幻觉下去了、知识鲜度上来了、还不用动模型权重——RAG能火不是没道理。跟微调比RAG更适合的场景是知识日新月异比如医疗指南、产品参数、政策法规。回答必须带引用来源比如客服、法务、投研。你不想为每一个细分领域都准备训练数据。而微调更适合的场景是让模型学会某种输出格式、模仿某种语气、遵循某种业务规则。这两种手段不是二选一项目大了之后两者经常一起用后面我会细说。3.2 RAG链路怎么做从文档切分到召回再到重排我这里直接给一个生产级的RAG流程每一阶段都有可以落地的建议。首先切分是RAG里最容易被低估的一步。切大了语义完整但召回精度低切小了精度高但上下文碎片化。我目前常用的经验结构化文档比如Markdown、HTML按语义块切不要按固定字数切。普通正文文本chunk_size设为300-500个字符左右overlap设50-100具体按你文档风格调。遇到表格、代码块等特殊内容尽量单独处理不要裹在正文里切成碎块。其次向量化与存储。Embedding模型的选择会影响召回好坏的半条命。开源的BGE系列、M3E闭源的OpenAI text-embedding-3-small跑过几个项目下来中文场景首选BGE效果稳定而且可以本地部署。向量数据库选型上小项目Qdrant或者Chroma就够了量大的考虑Milvus如果团队已经在用ES那ES的向量检索模块也完全能顶上。第三召回与重排。很多人做RAG只做向量召回效果往往差强人意。为什么因为纯向量相似度扛不住语义上的细微差异比如“这几种药的用量区别是什么”跟“药品用法用量对比”可能向量距离很远。实际生产中我会把召回结果用两种以上方式合并向量召回BM25关键词召回这叫多路召回合并之后再用重排模型Reranker精排取前3-5。重排模型是个跨编码器对query和doc的交叉语义建模能力比双向量强很多效果提升非常明显。我之前用LangChain搭过一个演示知识库问答做成系统后召回命中率在70%左右加入重排后直接升到88%以上。所以千万别在“多路召回重排”这步上省事它带来的提升比换个embedding模型大得多。3.3 RAG评测别凭感觉说“效果好效果差”RAG项目做到后面最大的痛点是不知道“改得好不好”。改个embedding换个切块策略加了个reranker——环节太多任何改动都会影响最终答案质量不量化就没法优化。我的做法是搭一个评测集准备至少100条业务真实问题每条问题带上标准答案或者答案里的关键要点。然后跑一遍拿LLM当裁判用几个关键指标打分忠实度Faithfulness回答是否严格依据检索到的上下文有没有编造。答案相关性是否直接回答了用户问题。上下文召回率被召回的文档中是否包含能支撑正确答案的关键信息。引用准确性回答中给的引用编号是否真的对应正确来源。跑完一轮之后把回答失败的问题挑出来逐一分析是检索断了召回没取到好内容还是生成阶段坏了模型没用上召回的内容。很多RAG项目里80%的问题其实出在检索阶段生成模型反而是被冤枉的。3.4 一个RAG速通示例用Qwen做本地知识库问答以下是我在本地做过的一个最小验证环境是MacBook M1内存16G用Ollama部署Qwen2.5-7B向量库用Chroma。第一步安装并启动Ollamaollama pull qwen2.5:7b ollama serve第二步用Python安装LangChain相关库把文档读入、切块、向量化、存Chromafrom langchain_community.document_loaders import TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import Chroma documents TextLoader(data/medical_guide.md).load() splitter RecursiveCharacterTextSplitter(chunk_size400, chunk_overlap80) chunks splitter.split_documents(documents) embeddings HuggingFaceEmbeddings(model_nameBAAI/bge-small-zh-v1.5) vectorstore Chroma.from_documents(documentschunks, embeddingembeddings)第三步构造RAG问答链from langchain_community.chat_models import ChatOllama from langchain.chains import create_retrieval_chain from langchain.chains.combine_documents import create_stuff_documents_chain from langchain_core.prompts import ChatPromptTemplate llm ChatOllama(modelqwen2.5:7b, temperature0.1) retriever vectorstore.as_retriever(search_kwargs{k: 5}) prompt ChatPromptTemplate.from_messages([ (system, 你是专业医学知识助手。请严格依据以下上下文回答问题不要使用自己的常识推断{context}), (human, {input}), ]) combine_docs_chain create_stuff_documents_chain(llm, prompt) rag_chain create_retrieval_chain(retriever, combine_docs_chain) answer rag_chain.invoke({input: 高血压患者能服用布洛芬吗}) print(answer[answer])跑完之后请先不要急着调优先用上面说的评测方法跑一轮记录问题再针对性改动。我在刚做RAG时最容易犯的错误就是“改一个参数就换另一种embedding”没有基准线改到最后根本分不清哪次改动是正向的。4. 微调当RAG不够用时怎么给模型“定制基因”4.1 微调跟RAG的分工各自管好自己那一摊事很多人一上来就问“做知识库用RAG好还是微调好”。我的回答是他们解决的根本不是同一类问题。RAG解决的是“信息不存在于模型参数里”——你需要模型替你实时读外部的资料。微调解决的是“模型行为模式不匹配”——比如你希望模型回答问题时先给结论再给分析、每次回答都控制在100字以内、或者在法律咨询场景下必须给出“答案法条依据”的结构。有一个特别生动的对比RAG相当于你在考试时带了参考书翻书作答微调相当于你上了一个针对性补习班老师把你脑子里答题的方式重塑了一遍。带书解决不了“不会答题风格”的问题补习班也解决不了“考题刚好来自最新时事”的问题。这两种手段不互斥。我见过做得好的项目是先用业务数据微调模型让模型学会领域术语、输出结构、专业语气再在推理阶段挂上RAG把最新的政策、报价、配方等信息实时检索进来。微调负责“人格”和“能力”RAG负责“当下事实”。4.2 没搞懂freeze、全量微调、LoRA的区别就别急着开跑微调不是“把模型再训练一遍”这么简单它分好几个流派理解每种流派背后的计算代价和适用场景是微调的第一课。全量微调就是模型的所有层、所有参数都参与训练。效果上限最高但代价也最大——显存不但要装下模型本身还要装下梯度、优化器状态、激活值7B模型的全量微调在单卡A100上也就勉强能跑普通人别轻易尝试。Freeze微调指冻结大部分底层参数负责通用语言理解只训练高层参数或特定模块。底层学到了通用的语法和语义知识高层更多负责任务相关的输出风格。Freeze的本质是“底子不动只练上层”内存比全量小一半还多效果在大多数任务上也不差。**LoRALow-Rank Adaptation**是当前事实上的主流方案。它的思路极为巧妙不直接更新原来的权重矩阵而是在原权重旁边加两个低秩矩阵A和B训练时只更新这两个小矩阵。以7B模型为例LoRA训练的可能参数量大概只有0.1%-1%一台24G显存的消费卡就能跑。最终合并时把A×B加回原权重模型输出完全不受影响。打个比方全量微调相当于把一栋大楼每面墙都重新刷漆LoRA则只是在关键位置挂了几块新的装饰板住的人还住里面但风格已经变了。4.3 实战用LoRA微调Qwen的完整流程这里以Qwen2.5-7B-Instruct为例目标场景是让模型学会“工业设备故障排查报告”的写作风格和思维方式。假设你已经有一台至少22G显存的GPU。**第一步准备数据。**数据集格式直接决定模型能不能学会。大部分开源模型用的是对话格式{ conversations: [ { role: system, content: 你是工厂设备故障诊断专家必须按故障现象、可能原因、排查步骤、解决方案的结构输出。 }, { role: user, content: 注塑机液压油温过高持续报警怎么处理 }, { role: assistant, content: 故障现象液压油温过高超过60度触发报警。可能原因冷却器堵塞、油箱油量不足、液压泵内部磨损。排查步骤1.检查冷却器进出水压差...解决方案清洗冷却器、补充油液至标准油位、更换磨损泵芯。 } ] }数据量上类目清晰的任务50-500条就能看到明显效果复杂的风格模仿至少要1000条以上。数据质量 数据量这一点怎么强调都不为过。我见过有人用500条乱糟糟的数据微调最后效果还不如不调。**第二步配置LoRA参数。**用HuggingFace PEFT库关键参数如下from peft import LoraConfig, TaskType lora_config LoraConfig( task_typeTaskType.CAUSAL_LM, r16, lora_alpha32, target_modules[q_proj, k_proj, v_proj, o_proj], lora_dropout0.05, )这里面r是低秩矩阵的秩r16是一个“大众稳妥值”。r设得小参数少、欠拟合概率高r设得大参数多、容易过拟合。lora_alpha是缩放因子通常设成r的两倍alpha/r2起步后续微调时可以去调。第三步训练脚本核心部分。from transformers import AutoModelForCausalLM, AutoTokenizer, Trainer, TrainingArguments from peft import get_peft_model model AutoModelForCausalLM.from_pretrained(Qwen/Qwen2.5-7B-Instruct) model get_peft_model(model, lora_config) training_args TrainingArguments( output_diroutput_lora, num_train_epochs3, per_device_train_batch_size1, gradient_accumulation_steps4, learning_rate2e-4, lr_scheduler_typecosine, warmup_ratio0.03, logging_steps10, save_steps100, bf16True, )learning_rate是LoRA训练里最容易出问题的参数。记忆里有个经验LoRA的学习率设定在1e-4到3e-4之间比较安全。调太高权重更新太猛模型原先的能力会被破坏调太低LoRA参数学不到东西白训。第四步合并LoRA权重。训练完成后需要把LoRA低秩矩阵合回原模型才能直接部署from peft import PeftModel base_model AutoModelForCausalLM.from_pretrained(Qwen/Qwen2.5-7B-Instruct) merged_model PeftModel.from_pretrained(base_model, output_lora/checkpoint-500) merged_model merged_model.merge_and_unload() merged_model.save_pretrained(merged_model)4.4 微调的高频翻车现场与避坑清单微调踩坑的频率远超过我的预期几乎每个项目都躲不开这几件事**过拟合。**验证集loss先降后升训练集效果极好验证集上回答开始“背书”——把你训练数据里的固定句式反复背出来。解决方案减少训练轮次2-3轮就够、加大LoRA的dropout、增加数据多样性。**灾难性遗忘。**微调之后模型原本的通用能力比如翻译、数学、通用问答明显退化这是因为训练数据几乎全来自目标领域模型“偏科”了。解决方式在训练数据里混入20%-30%的通用指令数据比如用Alpaca样本打底再掺业务数据。**Loss一直在降但回答完全对不上需求。**这大概率是数据格式或评价指标的问题。Loss低只能说明下一个token预测得准并不等于“输出过审”。请务必在训练前拿出20%的数据留作验证集每训练完一个checkpoint都实际跑几条对话看看效果。**训练Loss在一开始就飙升。**多半是学习率设置太高或者base model与数据集tokenizer不匹配。首先做一次“空跑验证”直接用pretrained模型推理一条训练数据确认回答格式和输入输出长短没问题再开始训练。还要啰嗦一句**微调前先确认基线。**不要拿一个没经过RAG优化、prompt也没调过的模型直接开跑微调。很多时候一个精心设计的prompt比你花几小时训练微调的效果还好成本是零。这事我吃过亏——花了三天微调出来的模型效果跟我在prompt里加一句“你是一个医疗领域的资深医生严格按以下格式回答”差不多大呼上当。5. 智能体从“聊天机器人”升级成“执行工作流的人”5.1 智能体到底比普通对话模型多了什么对话模型你问一句它答一句回答完就结束了。而智能体的核心差异是模型决策——调用工具——观察结果——再决策这个循环可以一直持续到完成任务为止。打个比方你让普通模型“帮我在GitHub上找一个支持中文的OCR项目并看看它的星星数”它是没法直接做的。智能体却可以自己拆解步骤调用网页搜索工具搜索“GitHub 中文 OCR 项目”。拿到搜索结果列表。调用网页访问工具打开第一个候选项目的页面。获取stars数据。如果第一个项目不合适回退到第二个继续。最后汇总成一份回答。这种能力在技术上依赖于两个关键点一是模型被训练出“能输出结构化的工具调用指令”的能力比如当它觉得需要查资料时会输出一个特定格式的JSON指令由运行时去执行并返回结果二是循环控制——让模型不止跑一次而是反复思考“当前结果是否满足目标不满足就继续调用工具”。目前的主流实现方式是ReAct模式的变体模型在每个循环里输出思考过程Thought、动作Action和动作输入Action Input运行环境执行动作后返回观察结果Observation模型再基于观察继续。看到这你可能就明白了智能体本质上是把大模型的“规划能力”和“执行能力”拆开模型只负责想具体干活靠的是运行时调用真实世界的API。5.2 智能体怎么搭框架选型与本地部署方案如果是企业项目千万不要自己从零写循环逻辑。市面上的框架已经相当成熟Dify国内项目落地用得非常多图形化编排、内置RAG管道和Agent节点适合做业务系统集成开源可私有化部署。LangChain / LangGraph灵活度最高适合需要细粒度控制状态流的场景。Phidata、MetaGPT、AutoGen各有侧重MetaGPT偏向模拟多角色协作AutoGen偏向多智能体对话。我个人的建议是验证阶段用Dify拖拖拽拽跑通流程然后如果对性能、状态控制有更高要求再用LangGraph把关键链路程式化。别一上来就选最炫的框架框架只是壳核心难点永远在“你如何拆解任务、定义工具、校验结果”。本地部署方面为了隐私和成本我用Ollama部署了Qwen2.5-7B或32B看显存然后让智能体框架对接OpenAI兼容接口好处是以后换模型不改架构。Windows系统下部署智能体几件事要记住如果不是最新N卡务必对齐CUDA、PyTorch版本这个坑能折腾你一天。内存至少16G推荐32G7B模型量化的ollama大概需要6-8G内存。如果只是测试直接跑OpenAI兼容API别急着在本地起量化推理服务先确认业务链路通不通。给一个Dify里的最小智能体搭建思路创建一个Agent应用模型选Ollama里的qwen2.5:7b工具里加上“高德地图查询”“天气API”“网页搜索”然后在提示词里写清楚智能体的角色和目标。接着你就可以问它“帮我查一下明天杭州的天气如果下雨找一下附近三公里内适合带娃的室内游乐场”。它会自己把天气查询和地图搜索串起来。5.3 记忆与工具调用智能体落地最容易翻车的地方智能体看起来不难搭但一放到真实业务里几个问题马上暴露。第一记忆混乱。多轮对话中模型经常分不清“用户是哪一轮提到的地点”或者把工具的中间结果误当成最终答案。这不只是prompt能解决的需要你在架构层面把对话历史、检索结果、工具返回结果分槽存放让模型只关注当前决策所需的信息。这在我做的项目中叫“状态管理”比模型本身还重要。第二工具调用的“死循环”。模型可能会反复调用同一个工具拿回同一个结果就是不知道下一步干嘛。解决办法有三设置最大迭代次数比如10轮在prompt里明确“如果某个工具连续调用两次未获得新信息请停止并基于现有信息回答”以及在运行时判断工具返回结果是否与上轮相同相同则强制终止。第三模型的“幻觉链条”。普通对话里模型瞎编一句也就过去了智能体里它可能基于一个虚造的工具返回结果接着规划后续步骤一层层把错误放大。对策是每个工具调用的返回结果都要做格式校验和内容校验凡是跟用户有关的关键信息订单号、金额、时间尽量从工具返回的真实数据中抽取不要让模型自由发挥了再抄一遍。5.4 智能体的“自我反思”与多智能体协作现在做智能体最前沿的方向不是给它接更多工具而是让它在行动之前先“想清楚”。具体做法就是把LLM“思维链”的能力延伸到行动中让智能体在计划阶段先写出若干个候选方案逐个评估可行性再选一个执行执行完之后再核对结果是否满足子目标不满足就重新调整计划。在复杂任务里把一个大Agent拆成多个子Agent各管一段能显著提升稳定性和可维护性。比如做一个“行业研报生成”智能体一个Agent负责收集数据一个Agent负责图表生成一个Agent负责写作润色还有一个主控Agent负责仲裁和汇总。这在MetaGPT这类框架里已经是标准套路了。但要注意多智能体不是越大越好每个Agent交互都有token成本和延迟。我实践下来的感受是先单Agent做到极限再拆子任务别一上来就搞“复仇者联盟”。6. 学习路线建议与最后的实操忠告很多人问大模型学习从哪开始。我想说不要被热搜词吓到也不要被“手写Transformer”这种硬核梗劝退。我走过一套闭环路线亲测有效第一周用Ollama部署一个开源模型先跑起来聊天把API接上感受模型的行为。别管原理先建立直观。第二周系统学Transformer。看《Attention Is All You Need》配合图解文章在PyTorch里写一个最小GPT拿莎士比亚文本训练几十个epoch让它输出像模像样的句子。第三到第四周做RAG。用LangChain或者Dify搭一个知识库问答跑一轮评测记录失败案例再做“多路召回重排”优化。做完你就算真正跨进了门。第五周微调。准备一个500条以上的业务数据集用LoRA训练Qwen或其他开源模型部署并跟基础模型对比效果。第六周智能体。用Dify或LangGraph把之前做好的RAG能力封装成一个工具再让智能体调用它完成一个多步骤任务。这套路线之所以有效是因为每一个环节的产物都会成为下一个环节的基础设施。RAG是智能体的工具微调是智能体行为质量的保障Transformer知识则是在一切出错的时候帮你定位的导航仪。最后分享几个我反复踩过的坑当做成语写在项目启动前的便签上**多大的任务都用“先跑通最小闭环”开场。**不要在一开始就奔着生产级去先用最小数据量、最小模型、最小流程跑通你会对这个系统产生手感然后再做性能优化。很多项目做不下去不是技术不够强而是从一开始就“配到最大、训死了”。**别贪多。**模型不是越大越好任务不是越复杂越好。7B模型足够应付大多数内部知识库问答多了智能体来回调度延迟上升、成本翻倍效果反而不如一个简单的RAG。我做的项目里最后上线的方案往往不是最“聪明”的而是最稳定的。**数据永远比模型重要。**不管是RAG的文档切分还是微调的数据集绝大多数效果问题都出在数据上——格式脏、质量乱、覆盖不全。先把数据收拾干净再谈模型调参。大模型这条技术栈最迷人的地方就是它不靠单点突破而是靠整体编排一个普通的开源模型配合好的RAG检索、恰到好处的LoRA微调、清晰的智能体工作流完全可以在真实业务里达到让人惊讶的效果。希望你也能用这套思维真正把大模型用起来而不是只停留在“跟ChatGPT聊天”的层面。