8月26日晚上，阿里千问和智谱几乎同时开源新模型，把价格打到了地板：千问Qwen3.8-Flash-Next，API每百万tokens输入1元、输出3元，比DeepSeek-V4-Flash空闲时段还便宜三分之一，原生26.2万上下文、可扩展到100万；智谱GLM-5.3-Flash（就是之前爆火的匿名模型"牛来"）价格直接干到GLM-5.3的十分之一。36氪
几乎同一时间，“RAG已死"的讨论又在社区热了起来。知乎上"做一个RAG系统最难搞定的是什么"这个问题攒了2100多个收藏，高赞回答第一句就是"demo半天跑通，上线第一个礼拜就被骂了”。知乎一边是上下文越来越长、API越来越便宜，一边是知识库项目频繁翻车，很多正在选型的人开始纠结：知识库还建不建？微调还搞不搞？
这个问题最近几天在知乎、小红书反复出现，连大模型岗的面试题都在问"RAG相比微调到底解决了什么问题"。我把这几天社区里讨论度最高的几组真实数据和案例扒了一遍，结论先说：RAG和微调不是二选一，它们治的根本不是同一种病。选错路线，浪费的不是几天，是几周的工程量加一个越调越烂的模型。
一场2000例的测试，把选型的第一个问题问出来了
先看一组最近被讨论很多的数据。
据36氪报道，儿科AI公司小儿方联合北京儿童医院做了一项测试：拿2000例真实病例，让当前最优的7个通用大模型扮演医生问诊，结果准确率最高的模型只有68.1%。36氪更关键的是错误的构成——三分之二的错误出在"不会想"，模型缺乏专家级的临床推理能力；只有三分之一出在"知识不够"。
而小儿方自己基于专家思维链微调的系统，在同样2000例上的诊断准确率是89%，五次独立问诊的结论一致率80%——通用模型在这项上最好只有55.1%。36氪（注：这是厂商方提供的测试数据，但有央视新闻镜头背书，且测试设计本身说明了一个通用问题。）
这个测试把选型最容易被忽略的一刀切出来了：
检索（RAG）只能解决"知识不够"——它把资料塞给模型，但模型还是按原来的方式想问题；
"不会想"这类问题，RAG救不了——推理方式、判断习惯、输出格式，这些要靠微调把行为"焊"进权重里。
很多人做知识库问答翻车，翻就翻在没分清自己的badcase属于哪一种。问模型"数据库连接池怎么配"，它答一堆索引优化——这是检索没召回对，RAG的锅；模型答对了知识点但输出格式永远对不齐、JSON永远缺个括号——这是行为问题，加再多检索也没用。
儿科这个场景还有个细节值得琢磨：医生看病的价值不在"知道这个病"，而在"先问什么、先排除什么"。接诊医生那句"这个病我们也知道，但不会首先考虑到"，说的就是检索给不了的东西。你做的业务如果是这种类型——法律、医疗、投研、客服话术——判断逻辑比知识点更值钱，那微调的优先级就要往前提。
第一个变量：长上下文正在抢RAG的饭碗
再看这次价格战带来的实际变化。
Qwen3.8-Flash-Next原生26万上下文，YaRN扩展到100万。按输入1元/百万tokens算，把一份50万字（约70万tokens）的文档完整塞进上下文，一次调用成本不到1块钱。这个数字意味着：一大批"小规模、更新慢、调用量低"的知识库场景，已经不需要建RAG了——直接把文档丢进上下文，效果比检索更稳（不存在切块切碎、召回不准的问题），工程量还趋近于零。
那什么时候RAG还是绕不开？社区里踩坑最多的几个场景，基本都满足下面至少一条：
知识量大到塞不进：几百万份文档、几十GB手册，上下文再长也装不下；
调用量大：一天几万次调用，每次都塞全量文档，账单会教你做人——RAG检索一次只塞几千字，成本差几个数量级；
知识更新快、来源多：今天改的规程明天就要生效，RAG更新索引就行，微调得重训；
需要引用溯源：答案必须标出"出自哪份文件第几条"，合规场景这是硬需求。
反过来，如果你的知识库就几十份文档、一天几百次调用、内容半年才更新一次——认真考虑一下，是不是直接塞上下文就够了。省下的切块、embedding、向量库、重排序这一整套的调试时间，是实打实的成本。知乎上"假如LLM无限上下文了，RAG还有意义吗"这个问题有146个收藏，吵的就是这件事。
还有一条工程经验来自高赞回答：知识库不是越大越好。有个做电力行业知识库的团队吐槽，把调度规程、继电保护手册、设备说明书全扔进一个库，"问一个继电保护的问题"召回一锅粥。分库、过滤、重排序，这些活一个都省不掉。有行业实施总结提到，企业RAG项目里相当比例的效果问题根因在数据接入层——数据质量决定上限，算法优化只是逼近上限。
第二个变量：微调治的是"格式"和"推理"，不治"知识"
再看微调这一边。最近小红书上有个Qwen3私有化落地的实操帖，把"为什么不直接写Prompt"说得很透：
System Prompt为了对齐格式和规则，写得比正文还长，每次调用都在烧token；
复杂逻辑模型会"偷懒"、遗忘指令，格式崩溃频繁出现。
他们的解法是拿业务数据做SFT（监督微调），把输出格式和业务规则直接"吃"进权重里。小红书这套说法和儿科测试的结论对上了：微调买到的不是知识，是行为。格式、语气、推理路径、输出结构——这些靠提示词反复教，不如一次性炼进模型。
但微调有两个大坑，最近社区里全是血泪案例：
坑一：拿微调灌知识。 有医药企业的真实案例：基础模型准确率72%，微调后掉到65%，典型的"调了不如没调"。知乎原因大概率就是往模型里硬灌事实性知识——知识这东西，模型本来就会的和它记混的搅在一起，反而污染原有能力。知识更新快的领域尤其如此：规则一变就得重训，所以实操帖都建议"微调管行为，RAG管新知识"。
坑二：数据没洗干净就开训。 知乎上"微调时数据清洗占整个周期多大比例"这个问题最近被反复问，几个做过领域模型的人给出的经验高度一致：清洗通常占整个项目周期的一半到七成，宁可要2万条干净样本，不要5万条带噪数据。知乎很多人的微调流程是"收集数据-直接喂进去-效果变差-怀疑模型不行"，其实第一步就错了。一个实用的门槛：手里没有至少上千条人工校验过的高质量问答对，先别启动SFT，把钱花在数据整理上更值。
顺便说一句工具链：现在这套流程已经被标准化了，LLaMA-Factory做LoRA微调加vLLM部署是社区事实标配，单卡3080Ti就能微调4B级别的模型做本地验证，国产昇腾NPU也有成熟适配。微调的工程门槛在2026年已经不高了，高的是数据和判断。
争议摆上桌："RAG已死"到底是不是真的
这波讨论里最激烈的争议，是"RAG是不是要死了"。
支持方的论据很硬：据社区引用的说法，Claude Code负责人Boris Cherny今年初在X上表示，早期Claude Code用过RAG，后来Anthropic自己把它删了，那条推文浏览量过百万。知乎写代码的场景里，Agent直接用grep、直接读文件，比先建向量库再检索更准——因为代码检索要的是精确匹配，不是语义相似。知乎上"为什么现在Agent重新用回Grep"的讨论里，有人干脆说"RAG死了是事实"。
但反方同样有理：被删掉RAG的是代码场景，那里的"知识"是结构化文件，精确检索天然够用。而企业问答、行业知识库面对的是非结构化文档和语义模糊的提问，向量检索加重排序仍然是性价比最高的方案。更准确的说法是：RAG没有死，它在分化——简单场景被长上下文吃掉，精确场景被Agent检索吃掉，剩下的"海量文档+语义问答"场景反而需要更复杂的RAG（Agentic RAG、GraphRAG）。
所以"RAG已死"当成口号喊很爽，当成选型依据就危险了。就像有人引用Gartner报告说"67%的企业AI项目采用RAG"——这类数字出自行业顾问文章，权威性和统计口径都存疑，看看方向就好，别拿去当决策论据。知乎
三个问题，今晚就能做完的自检
把上面的信号收拢成一个可执行的判断流程，其实就三个问题：
第一问：你的badcase属于哪一类？ 抽50-100条真实业务问题，人工归因：答错是因为"没找到资料"（知识问题→RAG/长上下文），还是"找到了但说不对、格式乱"（行为问题→微调），还是"推理方向就不对"（推理问题→思维链微调）。错误构成决定路线，这一步比任何技术对比文章都管用。
第二问：知识多大量、更新多快、调用多少？ 小文档+低频调用→直接塞长上下文；大库+高频+更新快→RAG；涉密不能出内网→私有化部署，RAG和微调的工具链都已适配国产硬件。
第三问：如果决定微调，数据够干净吗？ 有上千条校验过的高质量样本再开训；没有就先做数据，别急着跑LoRA。记住那个72%掉到65%的案例——微调翻车的成本不是白训一次，是污染一个本来好用的模型。
接下来值得盯的三个信号
最后按惯例给几个观察点：
Qwen4完整家族还没落地。 这次开源的Qwen3.8-Flash-Next是基于Qwen4架构的"先导预览版"，千问官方明说是为了让社区先检验结构改动。36氪正式版发布时，价格和上下文大概率还有变化，选型别把宝押在当前的价格表上；
GLM-5.3-Flash的限时折扣。 智谱这波1/10定价里含限时1/20的折扣，窗口期过后成本会变，拿它做预算基准要留余量；
"微调+RAG"组合方案的成熟度。 现在社区的主流答案已经收敛到"微调管行为、RAG管知识"，但两者之间怎么配合（比如微调后的模型怎么更好地遵循检索结果、引用格式怎么统一）还在快速演进，这个方向值得持续跟。
一句话总结：API降价改变的是成本账，没改变的是"知识靠检索、行为靠微调"这条分界线。先给badcase归因，再算账，比在群里问"RAG还是微调"有用得多。
