LLM

去年这个时候,团队里讨论得最多的还是"这句 system prompt 该怎么措辞"。有人为了一个 Agent 不肯老老实实调用工具,把 prompt 改了三十多版,加感叹号、加大写、加"这非常重要"——最后发现真正起作用的,是把那个工具的描述从一坨 200 行的 JSON Schema 砍到 40 行。 prompt 没救活它,砍上下文救活了它。 这件事在 2026 年已经不是个例。Chroma 在 2025 年做过一组实验,测了 18 个当时最强的模型,结论很扎心:每一个模型,输入一长,准确率都会掉。有的模型能在 95% 稳住一阵,然后一旦输入越过某个长度,直接跳水到 60%。模型不是线性变笨的,是到了某个点"塌方"。 所以 2026 年大家嘴里挂着的词,从 prompt engineering 变成了 context engineering(上下文工程)。这不是换个时髦说法。它是承认了一件事:模型每一次推理,看到的是整个上下文窗口,而不只是你那段精心打磨的 prompt。 窗口里还有工具定义、历史对话、检索回来的文档、记忆、上一步工具吐出来的一大坨结果——这些东西你不管,它们就替你"管"了模型。 prompt engineering 没死,它只是被降格了 先把关系说清楚,免得误会。 context engineering 不是来取代 prompt engineering 的。Anthropic 在那篇《Effective context engineering for AI agents》里说得很直接:prompt engineering 是 context engineering 的一个子集。 写好一段指令,依然重要;只是它现在只是你要操心的众多东西里的一个。 两者问的问题不一样: prompt engineering 问的是:“这句话我该怎么措辞?” context engineering 问的是:“模型这一刻,到底需要看到哪些信息?” 一次性的任务——翻译一段话、改写一封邮件——prompt engineering 基本够用。但只要你做的是 Agent,是那种要跑很多轮、要调工具、要记住前面发生过什么的系统,问题立刻就变了。你面对的不再是"一段 prompt",而是一个随着每一步在不断变化的上下文状态。这个状态怎么攒、怎么裁、怎么压,就是 context engineering。 ...

你跟一个语音 AI 说完话,它停顿了一下,才开口回答。 那一下"停顿",就是它不像人的地方。 人类对话的轮次间隔(turn-taking gap)中位数只有约 200ms,熟悉的人之间还经常"抢话"——下一句在上一句结束前就接上了。一旦 AI 的回应超过 500ms,你会明显感觉到"它在想";超过 800ms,对话就开始别扭,你会忍不住重复自己,或者以为它没听见。 所以做语音 Agent,延迟不是"优化项",是及格线。这篇把从【用户说完最后一个字】到【AI 喇叭里出第一个音】之间发生的事,拆到毫秒。 这条流水线长什么样 flowchart LR A[用户说话] --> B[轮次判定VAD + 端点] B --> C[ASR语音转文字] C --> D[LLM首 token] D --> E[TTS首包音频] E --> F[AI 出声] style B fill:#fde7c2,stroke:#e8b23c style D fill:#fde7c2,stroke:#e8b23c 橙色的两块——轮次判定和 LLM 首 token——是预算里最大的两笔开销,也是最值得花力气的地方。 一份现实的延迟预算 环节 它在做什么 典型耗时 轮次判定(VAD + 端点) 判断"用户真的说完了" 50–250 ms ASR(语音转文字) 把语音转成文字 ~0–150 ms* LLM 首 token(TTFT) 想出第一个字 250–500 ms TTS 首包 合成出第一段音频 75–200 ms 网络往返 客户端 ↔ 服务端 30–80 ms 合计(可感知) 约 500–900 ms * ASR 与用户说话并行进行,大部分转写在用户说完之前就做完了,所以它对预算的增量很小——前提是你用的是流式 ASR。 ...

去年我们一个内部项目,用 Claude Opus 跑一个意图分类:输入一句用户的话,输出三个标签之一。上线两周,有人去看账单,愣住了——这个分类任务,一个 14B 的开源模型在自己的卡上跑,效果差不了几个点,成本是它的几十分之一。 这就是 2026 年选型最常见的错误:把"哪个模型最强"当成了"我该用哪个模型"。 这两个问题根本不是一回事。GPQA、SWE-bench、ARC-AGI-2 这些榜单告诉你的是天花板,而你大部分的线上请求,离天花板远着呢。一个分类、一段摘要、一次格式化抽取——这些活儿,旗舰模型是高射炮打蚊子。选型不是选最强,是给每一类任务配一个"刚好够用、且最便宜"的模型。 这篇不排名。给你一套按场景拆的决策框架。 先认清:2026 年的模型是分梯队的 2026 年 5 月,前沿模型大概是这么个格局——记住具体版本号意义不大,它们每两三个月就跳一次,记住梯队就行: 梯队 代表模型(2026.05) 典型 API 价格(输入/输出,每百万 token) 该干什么 旗舰 GPT-5.5、Claude Opus 4.7、Gemini 3.1 Pro $5 / $25 量级 复杂推理、Agent 编排、难代码 主力 Claude Sonnet 4.6、Gemini 3 Flash、DeepSeek V4-Pro $1–3 / $3–15 量级 绝大多数生产任务 快而省 Claude Haiku 4.5、Gemini 3 Flash-Lite、DeepSeek V4-Flash $0.1–1 / $0.3–5 量级 分类、抽取、路由、简单问答 这张表里藏着一个关键事实:旗舰和"快而省"之间,输出价格差了几十倍。 DeepSeek V4-Flash 的输出大约 $0.28,GPT-5.5 是 $30——一百多倍。这个差距不是边角料,它会直接决定你的产品能不能规模化。 而梯队之间的能力差距,这两年反而在缩小。2024 年你能明显感觉到旗舰和主力不是一个物种;2026 年,在很多具体任务上,主力模型只比旗舰差几个百分点,有时候你压根测不出来。能力在收敛,价格还拉得很开——这就是"按梯队选型"能省钱的根本原因。 ...

先说一个反直觉的数字:80% 喊着「我们要微调」的需求,换个更好的检索就解决了。 这是 2026 年做过几轮项目后,业内基本形成的共识。但凡你想让一个通用大模型「答对你自己的事」——公司的产品文档、内部规章、某个客户的历史订单——你大概率会在三条路里纠结:RAG(检索增强)、微调、长上下文(直接把材料塞进 prompt)。 这三条路经常被拿来对比,但很多对比都在装中立,列个表说「各有优劣,看场景」。这篇不装。它们不是平级的选项,它们解决的根本不是同一个问题。选错那条,代价不是「效果差一点」,而是要么每个月烧掉本不该烧的钱,要么半年后你的数据全过期、整个系统没人敢碰。 它们到底各自在解决什么 把这件事想清楚,后面就不纠结了。 RAG:模型不知道答案,你临时把答案找出来递给它。模型本身不变,变的是每次喂给它的上下文。 微调:你改的是模型本身的权重。让它换一种说话方式、固定输出某种格式、养成某种行为习惯。 长上下文:你不做检索、不做训练,直接把所有相关材料一次性塞进 prompt,让模型自己在里面找。 注意区别:RAG 和长上下文都是在「给模型补知识」,区别只是补的方式——一个精挑细选地补,一个一股脑全塞。而微调压根不是在补知识,它在补能力和行为。这是最常见的认知错位:有人想让模型「记住公司有 300 条规章」,跑去微调,结果训完发现模型还是答不准,因为微调不是用来塞事实的。 一句话记牢:知识用 RAG,行为用微调,长上下文是知识量小到不值得搭管道时的偷懒办法。 RAG:知识会变、要溯源,就选它 RAG 是 2026 年绝大多数团队的默认起点,理由很硬:它便宜、上线快,而且能干那件最常见的事——让模型回答关于你自家数据的问题。 它的真正杀手锏是另外两个: 知识能随时更新。 产品改了价、规章出了新版,你只要更新向量库里那几条,模型下一秒就用新的了。不用重训、不用重新部署。对任何一个数据会变的业务,这一条几乎是决定性的。 答案能溯源。 模型说「退款政策是 7 天」,你能指着它后面挂的那条文档说「依据在这」。金融、医疗、法律这类场景,「答得对」还不够,你得能证明它为什么这么答。微调和长上下文都给不了这种可追溯性——微调把知识熬进了权重里,你根本说不清它从哪学的。 但 RAG 不是免费午餐,2026 年的现实是:当 RAG 出错,73% 的锅在检索,不在生成。 模型没胡说,是你压根没把对的文档捞给它。所以现代 RAG 早就不是「embedding + 余弦相似度」那么简单了,一条能上生产的管道长这样: flowchart LR A[文档] --> B[语义切块] B --> C[向量库] D[用户提问] --> E[混合检索向量 + BM25] C --> E E --> F[Rerank取 Top 5-10] F --> G[LLM 生成] 几个关键点,踩过坑的都懂: 切块是默默崩掉 RAG 的地方。 切得太碎,一个 chunk 答不全一个问题;切得太大,塞进去全是噪音。语义切块(按 embedding 相似度找话题边界)比固定字数切块靠谱得多。 混合检索基本是标配了。 纯语义检索会漏掉「精确匹配」——比如某个型号编号、某个专有名词。把向量检索和 BM25(关键词)拼起来,准确率明显更稳。 Rerank 是那勺秘制酱。 先用混合检索捞 100 条候选,再用一个 cross-encoder 重排序模型(Cohere Rerank、BGE-Reranker 这类)精筛出 5-10 条真正喂给大模型。这一步加上,系统会从「有时有用」变成「能上生产」。 代价是:你得维护一整套数据管道——切块、embedding、向量库、rerank,每一环都能出问题。RAG 上线快,但养着它不轻松。 ...

用一个下午就能搭出一个像样的 Agent demo。接个大模型、写几个工具、调通 ReAct 循环,跑十条 case,全过。截图发群里,大家鼓掌。 两周后,一个客户在工单里贴出对话记录:你的 Agent 把退款金额算成了原价的三倍,还信誓旦旦地说"已为您处理"。你翻监控面板——CPU 正常、接口 P99 40ms、错误率 0.02%,一片绿。 这就是 Agent 工程里最反直觉的地方:搭出来是最简单的一步,知道它到底好不好,才是真正的工程。传统软件你写完测试、跑通 CI,基本就放心了;Agent 不行——它每次的输出都不一样,它"出错"的方式根本不会触发任何异常。这篇讲讲上线之后那部分:看什么指标、怎么评、怎么防回归。 为什么你那套监控不管用 先说清楚传统监控为什么在这里失灵。 传统软件的故障是二值的:要么 200,要么 500;要么返回了,要么超时了。你的告警系统盯着这些信号,出事就响。Agent 的故障是语义的:HTTP 200,JSON 合法,字段齐全,延迟正常——内容是错的。Agent 自信地编了一个不存在的退货政策,调了正确的工具但传错了参数,绕了七步才完成一件三步能干完的事。这些在传统监控眼里全是"成功请求"。 更麻烦的是 Agent 是非确定性的。同样一句"帮我查下上个月的账单",今天它走两步给出答案,明天可能走五步还问你要确认。你没法用"输入 X 必然输出 Y"来断言。所以 Agent 的评估,本质上是在做概率系统的质量管理——你管的不是单次对错,是一个分布。 还有一层:Agent 是多步的。一次任务里,规划器把目标拆成子步骤,工具选择器挑了几个工具,检索器拉了上下文,模型可能还重试了两次,最后才有一个回答。出了问题,你得知道是哪一步坏的。只盯着最终输出,等于只看考试总分不看错题——你知道它考砸了,但不知道为什么。 flowchart TD A[用户请求] --> B[规划拆解子任务] B --> C[工具选择] C --> D[工具调用] D --> E{结果够了吗} E -->|不够| B E -->|够了| F[生成回答] F --> G[返回用户] style B fill:#fde7c2,stroke:#e8b23c style C fill:#fde7c2,stroke:#e8b23c style D fill:#fde7c2,stroke:#e8b23c 橙色那三块——规划、选工具、调工具——是 Agent 区别于"一次 LLM 调用"的地方,也是大多数故障的发生地。你的可观测性必须能看进这三块,而不只是看进出。 ...

团队花三个月,搭了一套五个角色的多 Agent 编排:Planner、Researcher、Coder、Reviewer、Reporter,各司其职,消息总线串起来,架构图画得很漂亮。 上线后效果不理想——慢,贵,而且一出错就没人知道是哪一环错的。 后来有人把其中一个单 Agent 的 system prompt 重写了一遍,加了几个工具,效果追平了那套五角色编排。token 成本只有它的零头。 这种事我见过不止一次。2026 年,“上多 Agent"几乎成了一种默认的进步姿态——好像单 Agent 是入门,多 Agent 才是工程师该交的作业。我想把话说直白:大多数时候你并不需要多 Agent。 单 Agent 加上几个好用的工具,能解决的事比你以为的多得多。多 Agent 是一种有明确代价的架构选择,不是一次免费的升级。 先说清楚:什么是"多 Agent” 这个词被用得太松了,先收紧一下。 下面这些不是多 Agent,它们只是单 Agent 在干活: 一个 Agent 在循环里调用多个工具(查数据库、读文件、发请求); 一个 Agent 把一段固定的处理流程拆成几步顺序执行; 一个 Agent 调用一个"子任务工具"——把某个隔离的小任务丢给一次独立的 LLM 调用,拿回一段摘要。最后这个尤其重要,后面会专门讲。 真正的多 Agent,指的是多个各自带独立上下文、独立决策循环的 Agent,彼此之间要协调。它们要交接任务、传递状态、有时还要互相评审或辩论。LangGraph 的状态图、CrewAI 的"角色 crew"、AutoGen(现在叫 AG2)的多轮对话编排,做的都是这件事。 区别的关键在于:有没有"协调"这个动作。 单 Agent 调工具,工具是被动的、无状态的,调完就完;多 Agent 之间,每一个都是活的、有上下文的,它们要互相对齐。协调,就是多 Agent 全部代价的来源。 多 Agent 真正适用的三种场景 不是说多 Agent 没用。它有几个单 Agent 确实啃不动的场景,而且这几个场景的特征很清楚。 一,子任务能真正并行,而且彼此独立。 这是多 Agent 最硬的理由。Anthropic 公开过他们的多 Agent 研究系统:一个 lead agent 把一个宽泛的研究问题拆成若干互不相干的子查询,同时派出多个 subagent 各查各的,最后汇总。这里的"并行"是真并行——五个子查询之间没有依赖,谁先谁后无所谓,挂掉一个不影响其余四个。读密集型的、可扇出的活,是多 Agent 的主场。 ...

给你的知识库问一个问题:“我们去年 Q3 的退款政策,跟今年比有什么变化?” 朴素 RAG 会怎么做?它把这一整句话拿去向量库里查一次,取回 5 个最相似的片段,塞进 prompt,让大模型生成。结果大概率是:它检索到了"今年的退款政策",但没检索到"去年 Q3 的",因为这句话作为一个整体,语义上离"今年的政策文档"更近。于是模型用今年的政策,回答了一个关于"变化"的问题——而且它不会告诉你它只看到了一半。 这就是朴素 RAG 的根本毛病。它把检索当成一个一次性的、无脑的前置步骤:查一次,查到什么算什么,然后生成。它不会判断"我查到的东西够不够",不会发现"这个问题其实要查两次",更不会在检索失败时重来。它失败的时候不会报错,会编。 2026 年,生产环境里真正能扛住复杂问题的,已经不是这条流水线了。这篇讲清楚它怎么一步步长成 Agentic RAG,以及——这是重点——多出来的延迟和成本,什么时候值,什么时候是浪费。 朴素 RAG 到底卡在哪 先把它失败的几类问题说具体,不然后面所有"改进"都是空的。 多跳问题。“写《三体》的作者还写过哪些小说?"——这要先查”《三体》的作者是谁"(刘慈欣),再用这个答案去查"刘慈欣的其他作品"。一次检索拿不到第二跳需要的关键词,因为第二跳的查询词(“刘慈欣”)根本不在原始问题里。 **模糊 / 措辞错位。**用户问"那个会自动重试的配置项叫什么",知识库里写的是"retry_policy 重试策略"。用户的口语和文档的术语对不上,向量相似度也救不回来。 问题里藏着多个子问题。“对比一下 A 方案和 B 方案的成本和上线周期”——这是四个检索意图揉在一句话里,一次检索只会取回一堆"半相关"的片段,哪个都不深。 需要计算或外部数据。“我们这个季度的获客成本环比涨了多少”——答案不在任何一个文档片段里,它需要先取两个数,再算个除法。文本检索给不了。 这些问题的共同点是:正确答案不是"检索一次就能拿到的那 5 个片段"。要么得检索多次,要么得换个查法,要么检索根本不是最后一步。朴素 RAG 的架构里没有"再来一次"这个动作,所以它只能在第一次的结果上硬生成。 演进的主线:从「流水线」到「控制循环」 把朴素 RAG 和 Agentic RAG 摆在一起看,差别不是"加了几个模块",是控制权交给了谁。 朴素 RAG 是一条固定流水线:检索 → 生成,顺序写死,模型只负责最后那步生成,没有决策权。 Agentic RAG 是一个控制循环:大模型坐在中间当指挥,它拿到问题后自己决定下一步干什么——要不要检索、检索什么、查到的东西够不够、要不要换个查询词再来一次、还是已经可以回答了。检索从"前置步骤"变成了模型手里的一个工具,跟计算器、SQL 查询、API 调用平级。 flowchart TB subgraph naive[朴素 RAG:固定流水线] direction LR Q1[问题] --> R1[检索一次] --> G1[生成] --> A1[答案] end subgraph agentic[Agentic RAG:控制循环] direction LR Q2[问题] --> AG{Agent决策} AG -->|要查| R2[检索/改写/计算] R2 --> EV[评估结果够不够?] EV -->|不够| AG EV -->|够了| G2[生成] --> A2[答案] end style AG fill:#fde7c2,stroke:#e8b23c style EV fill:#fde7c2,stroke:#e8b23c 橙色的两块——决策和评估——是朴素 RAG 里完全没有的。整个演进,本质上就是把这两个能力一点点加进来。下面拆成四个阶段讲。 ...

让模型回答之前先"想一会儿",这件事确实有用。 2026 年 4 月有一篇论文,标题直接叫《When More Thinking Hurts》(想多了反而坏事)。里面有个例子我印象很深:让一个大推理模型算"9900 加 1",它居然烧掉了几千个思考 token,中途还一度把正确答案推翻又改回来。一道小学一年级的题,被它想成了奥数。 这就是推理模型这一年的缩影。o1 出来的时候,大家的第一反应是"哇,会思考了";到了 2026 年,大家学到的是另一句话——思考是要花钱的,而且大部分时候,你根本不需要它想那么多。 推理模型到底改了什么 先把概念说清楚。 传统 LLM 的算力几乎全花在训练上。模型训完,推理(inference)时就是一次前向计算,吐 token,快进快出。你给它一道难题,它"脱口而出"——答得对不对,基本取决于训练时见过没见过类似的东西。 推理模型动的是另一处:test-time compute,推理时算力。它在真正回答你之前,先在内部生成一长串"草稿"——拆解问题、试不同思路、自我检查、推翻重来。这串草稿就是所谓的思考过程(chain-of-thought)。你看到的最终回答可能只有三句话,但背后它可能写了一万五千个 token 的内心戏。 flowchart LR Q[你的问题] --> A{普通模型} A --> A1[直接吐答案] Q --> B{推理模型} B --> B1[内部草稿拆解·试错·自检] --> B2[最终答案] style B1 fill:#fde7c2,stroke:#e8b23c 这个改动的意义在于:模型的能力第一次变成了可以用算力买的。同一个模型,让它多想,它在数学、代码、逻辑题上的准确率就实打实地往上走。OpenAI 当初说 o3 在真实世界的难题上比 o1 少犯约 20% 的重大错误,靠的不是换了更大的底座,很大程度上就是想得更久、更会想。 从 o1 到 o3、o4-mini,再到 Gemini 2.5 的 thinking、Claude 的 extended thinking、DeepSeek R1、Qwen 3 的思考模式——2026 年你能叫得出名字的主力模型,基本都带"会思考"这一档。test-time compute 从一个研究概念,变成了产品标配。 这一年学到的:思考不是免费的 如果故事到这里就结束,那这篇文章没什么好写。问题恰恰在于——让模型多想,代价大得超出很多人的预期。 ...

你把 prompt 改了一版,在三个例子上试了试,看着比之前顺眼,于是上线。 第二天客服群里有人说 AI 答得不对劲。你回头去看,发现那三个例子确实变好了,但另外二十种你没试的情况里,有五种悄悄变差了。 这是做 LLM 应用最常见的窘境:你没法靠"看几个例子"判断一次改动是涨还是跌。模型是个高维的黑盒,你改 prompt、换模型、调温度,影响面是发散的——在你盯着的地方变好,在你没盯着的地方变坏。评估(eval)要解决的就是这件事:把"我觉得变好了"换成"我有证据说变好了"。 这篇讲怎么把这套证据系统搭起来,以及一路上的坑。 公开 benchmark:能看排名,不能信分数 打开任何一个模型发布页,都有一排 benchmark 分数:MMLU 多少、GPQA 多少、SWE-bench 多少。这些数字有用,但对你的应用,它的参考价值比你以为的小得多。 第一个问题是饱和。2026 年的前沿模型在 MMLU 上普遍是 92–94%,彼此之间的差距已经掉进噪声里了。一个 93%、一个 94%,你没法据此说后者更强——重跑一次,排名可能就反过来。MMLU 这种榜单现在只能告诉你"这是不是个能用的模型",没法在头部模型之间分高下。后来的 MMLU-Pro 想救场,到 2026 年初头部模型也挤到了 90% 附近,同样在走向饱和。 第二个问题更麻烦:污染。Benchmark 的题目是公开的,公开就意味着它们大概率被爬进了下一代模型的训练数据。模型可能不是"做对了"题,而是"背过"答案。已经被记录的案例不少:MMLU 的题目在 Common Crawl 里能找到原文;HumanEval 的题和 LeetCode 题高度重合;SWE-bench 的 issue 在公开 git 历史里能翻到现成的修复 commit。 污染有多严重?Scale AI 做过一个对照实验:他们照着小学数学题 GSM8K 的风格,重新出了 1250 道全新的题。结果模型在新题上系统性掉分,最差的那个掉了 13 个百分点。同一个模型,题目换成没见过的,能力就缩水一成多——这说明原来那个高分里,有相当一部分是"背"出来的。 所以 2026 年大家转向抗污染的 benchmark:LiveCodeBench、LiveBench 这类按时间切片,只用某个日期之后才出现的新题;FrontierMath 把题目压在手里不公开。这些比静态榜单可信。但即便如此,它们衡量的还是"通用能力",不是"你的任务"。 结论很直接:公开 benchmark 用来粗筛候选模型——把明显不行的排除掉。但"这个模型在我的客服场景里好不好用",它一个字都没回答。这个问题只能你自己回答。 自己的 eval 集:这才是真正的资产 你的应用有一个公开 benchmark 永远覆盖不到的东西:你的真实输入分布。你的用户怎么提问、问什么、用什么语气、夹杂什么错别字和行业黑话,这是你独有的。eval 集就是把这个分布固定下来。 ...

打开你的 iPhone,如果它是 16 或更新的型号,系统里已经常驻着一个约 30 亿参数的语言模型——它在帮你总结通知、改写短信、给照片打标签,全程不联网。你没装它,你也没感觉到它,但它一直在那。 这件事一年前还做不到。 过去这一年,所有头条都给了旗舰大模型:更长的上下文、更强的推理、更贵的订阅。但真正改变"AI 装在哪儿"这个问题的,是另一条没什么人盯着的线——几 B 参数的小模型,和把它们塞进手机、笔电、边缘盒子的工程。这条线今年悄悄拉满了。 我想把这件事讲清楚:小模型现在到底能做好哪些事,为什么端侧值得,量化和蒸馏在中间干了什么,以及——同样重要——它干不了什么。 先说清楚:小模型不是"大模型的劣化版" 很多人对小模型的印象停留在"便宜但是笨"。这个印象在 2024 年大致成立,现在不成立了。 关键的转变是:小模型不再靠"也学一点世界知识"来对标大模型,而是放弃了一部分知识广度,换取在窄任务上的密度。微软的 Phi 系列把这条路走得最直白——靠精心筛选的高质量训练数据,Phi-4 在 MATH 和 GPQA(研究生级科学题)这类基准上能压过体量大得多的模型。它不是"小一号的 GPT",它是另一种东西。 阿里的 Qwen3 把尺寸切得很细:0.6B、1.7B、4B、8B 一路排下来。官方技术报告里有个反直觉的数据——Qwen3 的 4B / 1.7B,在过半数基准上能打过上一代的 Qwen2.5-7B / 3B,尤其在 STEM 和代码题上。新一代的 4B,约等于老一代的 7B。 这就是过去一年小模型走过的距离。 谷歌的 Gemma 也在做同样的事。4 月发布的 Gemma 4,最小的 E2B / E4B 变体用了 Per-Layer Embeddings 这类结构技巧,4-bit 量化后 5GB 内存就能在现代手机上跑起来。 所以判断一个小模型,别再问"它知道的有没有大模型多"——它注定不多。要问的是:在我这个具体任务上,它够不够。 它现在能做好哪些任务 把场景摊开看,小模型今天在这几类任务上已经够用,而且是真的够用,不是"凑合": 文本的搬运和改造。 总结、改写、润色、抽取实体、分类、按格式重排——这类任务不需要模型"懂很多",只需要它"听话且稳"。苹果那个 3B 端侧模型的官方定位就写得很白:它擅长总结、抽取、文本理解、润色、短对话,它明确不是一个用来问世界知识的聊天机器人。这个定位是诚实的,也是对的。 结构化输出和函数调用。 这是过去一年小模型最大的一块进步。Gemma 4 是第一个把"agentic 能力"当成一等设计目标的开源模型族——它不靠语法约束,就能稳定吐出合法的、可解析的 JSON 工具调用。这意味着一个本地小模型可以真的当"调度员"用:理解你的意图,挑对工具,填对参数,剩下的交给确定性代码去做。对很多 Agent 场景,模型本来就不该负责"算出答案",它只负责"派活"。 ...

DeepSeek V3 一共有 6710 亿参数。但你每问它一句话,真正参与计算的只有 370 亿——剩下的 95% 在显存里待命,一个 token 都不碰。 这听起来像偷工减料,其实是过去三年大模型架构最重要的一次转向。到 2026 年,你叫得出名字的开源旗舰里,几乎没有一个还是"老老实实每个参数都算"的稠密模型:DeepSeek V4-Pro(1.6 万亿总参 / 490 亿激活)、Qwen 3.5(3970 亿 / 170 亿)、Llama 4 Maverick(4000 亿 / 170 亿)、Kimi K2(1 万亿 / 约 320 亿)、Mistral Large 3(6750 亿 / 410 亿)。这个架构叫 Mixture-of-Experts,混合专家。 它解决的是一个很具体的矛盾:模型想变聪明,最直接的办法是堆参数;但参数一多,推理就慢、就贵。MoE 的本质,是把"模型有多少知识"和"算一次要花多少钱"这两件事拆开。这篇讲清楚它怎么做到的,以及它换来了什么样的工程代价。 先讲清楚:稠密模型贵在哪 传统的大模型——也就是 GPT-3、早期 Llama 那种"稠密"(dense)模型——有一个朴素的规则:每个 token 经过每一层时,所有参数都要参与计算。 一个 700 亿参数的稠密模型,处理一个 token 就要做大约 700 亿次乘加。处理一句 100 字的话,乘以 100。参数翻倍到 1400 亿,这个账单也跟着翻倍。算力、显存带宽、电费,全是线性涨上去的。 问题是,模型里真的每个参数对每个 token 都有用吗? 直觉上不是。你问它"今天北京天气",和你让它"写一段 Rust 的并发代码",用到的知识完全不同。稠密模型的浪费就在这:不管你问什么,它都把"写代码的脑区"和"聊天气的脑区"全部点亮算一遍。 ...

你写了个 prompt,让 LLM 把一段用户评论解析成 JSON:情感、评分、关键词。本地跑了二十次,完美。上线。 三天后告警响了。某条响应里,LLM 在 JSON 后面多写了一句"希望这个分析对你有帮助!"。你的 json.loads() 当场抛异常,整条链路挂掉。 这不是小概率事件,是结构性问题。只要你还在用"自由文本里夹一段 JSON"的方式跟 LLM 要数据,这种崩溃就是迟早的——区别只是它发生在测试环境还是生产环境。 这篇讲清楚:为什么自由文本提 JSON 天生不可靠,2026 年有哪几种正经方案、各自的代价是什么,schema 怎么设计才不坑自己,以及最难的那块——流式场景下怎么拿到结构化数据。 为什么"让它输出 JSON"本身就是错的 先理解 LLM 在干什么。它做的是一件事:根据前面所有 token,预测下一个 token 的概率分布,然后采样。它没有“我现在要写一个合法 JSON"这种全局意识。 所以当你在 prompt 里写"请只返回 JSON,不要有多余文字”,你是在用一句话,对抗模型训练数据里成千上万条"先解释再给结果"的对话样本。大多数时候它听话,因为你的指令把概率压过去了。但只要某次采样,在该写 } 的位置,“希望"这个 token 的概率偶然爬到了第一,它就会写下去——而且一旦写下去,后面就会顺着"希望这个分析对你有帮助"这条最自然的路径滑下去。 常见的失败长这样: JSON 外面套了 ```json 代码块,或者前后有一段自然语言 字符串里有没转义的换行、引号 该是数字的字段写成了 "4.5"(带引号),或者写成 4.5分 嵌套对象少了一个括号,尤其是输出很长的时候 枚举字段返回了你没定义的值——你要 positive/negative/neutral,它给你个 mixed 这些都不是模型"笨”,是概率采样的必然结果。你不可能靠把 prompt 写得更恳切来根治它,你只能降低概率,没法归零。要归零,得换思路:不是请求它输出合法结构,而是从机制上让它没法输出不合法的结构。 五种方案,以及它们各自的代价 2026 年,从最弱到最强,实际可用的方案是这五种。关键不是"哪个最好",是搞清楚每个的边界。 flowchart TB A["LLM 要输出结构化数据"] --> B{"模型在哪?"} B -->|"闭源 API"| C{"要不要 100% 保证 schema?"} B -->|"自己部署的开源模型"| D["约束解码xgrammar / llguidance"] C -->|"要"| E["Structured Outputs / strict 工具"] C -->|"差不多就行"| F["JSON Mode（已是 legacy）"] E --> G["拿到必定合法的 JSON"] D --> G F --> H["只保证语法合法，schema 靠运气"] style E fill:#fde7c2,stroke:#e8b23c style D fill:#fde7c2,stroke:#e8b23c 1. 纯 prompt 约束。 就是开头那种"请只返回 JSON"。它的唯一价值是当作其他方案的补充——把字段含义、示例写清楚能提升内容质量。但别拿它当结构保证。如果你现在生产环境还在裸用这个,这篇文章后面的部分就是为你写的。 ...