LLM

把一份 80 万字的项目文档整个粘进对话框,模型没报错,也回答了你的问题。你松了口气:看,1M 上下文真香。 但你有没有验证过——它引用的那段需求,是真的从文档第 40 万字的位置取出来的,还是它顺着上下文的语气编了一段听起来很对的话? 这是 2026 年长上下文最尴尬的地方:“放得进"是确定的,“用得好"是不确定的,而大多数人只测了前者。 模型厂商标 1M、2M,你看到的是窗口大小;你真正需要的是这个窗口里有多少 token 是"模型会认真看"的。这两个数字,差得比你想的大。 标称上下文 vs 有效上下文 先把两个概念分清楚。 标称上下文(advertised context)是模型 API 允许你塞进去的最大 token 数,超了就报错。有效上下文(effective context)是模型在性能开始明显掉档之前,真正能可靠利用的 token 数。 RULER 这个 benchmark 当年就是为了量化这件事造出来的。它的结论很扎心:很多号称 32K+ 的模型,在 32K 长度下能维持及格表现的,只有一半。到了 2026 年,百万级窗口普及之后,这个差距并没有消失——多份独立测试给出的经验值是,有效上下文通常只有标称值的 60%~70%,而且性能下滑的方式,简单的 token 计数根本看不出来:漏检的内容、编造的细节、断掉的推理链。 把 2026 年几个主流模型的标称窗口和实测召回放在一起看: 模型 标称窗口 1M 长度实测召回 备注 Claude Opus 4.6 1M ~76% 256K 下约 93%,长度档位领先 Gemini 3.1 Pro 1M ~70% 次于 Opus Gemini 1.5 Pro 2M ~55%~65% 窗口最大,召回反而靠后 Llama 4 Scout 10M 1M 后明显衰减 标称最大,有效区间远小于标称 注意 Gemini 1.5 Pro 这一行:它标 2M,是表里窗口最大的,但 1M 长度下的召回反而排在后面。窗口大小和有效质量,不是同一个排行榜。 标称 10M 的 Llama 4 Scout 也一样,过了 1M 之后衰减得很明显,适合做的是"检索式"任务,不是"全局理解"任务。 ...

2025 年初,DeepSeek 放出一组叫 R1-Distill 的模型,其中那个 7B 版本在 AIME 2024 数学竞赛题上拿到了 55.5% 的 pass@1。 这个数字有意思的地方在于:它比 QwQ-32B-Preview 还高。一个 7B 的小模型,在硬核推理题上,打过了一个参数量是它四倍多的模型。 更反常识的是后面这句——DeepSeek 自己说的:直接拿强化学习去训练那个 7B 小模型,效果还不如蒸馏。小模型自己练,练不出这种推理能力;但你拿一个 671B 的大模型当老师,把它的思考过程喂给小模型学,小模型就学会了。 这就是蒸馏。它不是模型压缩里的某种玄学技巧,而是 2026 年几乎每家做小模型的团队都在用的标准动作。这篇把它讲清楚:蒸馏到底搬走了什么,和微调是什么关系,能搬多少,做不到什么,以及一套能落地的流程。 为什么要蒸馏:质量和成本之间那道墙 先说动机。 大模型好用,但贵。一个 400B 参数的旗舰模型,推理延迟高、单次调用成本高、显存吃得狠,你不可能把它塞进每一台手机、每一个边缘设备、每一条高并发的客服管道。可小模型呢?便宜、快、能本地跑,但你直接拿一个 7B 模型出来用,它在复杂任务上的回答质量,和旗舰模型差着一大截。 这就是那道墙:质量在大模型这边,成本和延迟在小模型那边,你想两个都要。 传统的过墙办法有两种。一种是直接训练一个小模型——但小模型受参数量限制,见的数据再多,某些能力(尤其是多步推理)就是练不出来,这是容量天花板。另一种是把大模型剪枝、量化——这能省一点,但省不了数量级,而且剪过头质量就崩。 蒸馏是第三条路,也是目前性价比最高的一条:不让小模型自己悟,而是让大模型手把手教它。Meta 拿 Llama 4 Behemoth 去训 Llama 4 的 Scout 和 Maverick,Google 用 Gemini 去带 Gemma 2 和 Gemma 3,DeepSeek 用 R1 蒸出 1.5B 到 70B 一整个系列——2026 年你能叫得出名字的小模型,背后基本都站着一个大模型老师。 道理很朴素:让一个聪明人把题做一遍、把思路讲给你听,比你自己对着标准答案死磕,学得快得多。 蒸馏到底在传递什么 很多人对蒸馏的第一印象是"用大模型造点数据,拿去训小模型"。这个理解对了一半,但漏掉了最关键的东西。 蒸馏的精髓在于软标签(soft label)。 举个例子。你问模型"这句话情感是正面还是负面",一个普通的训练样本只会告诉小模型一个硬标签:正面。但大模型老师给出的不是一个字,而是一整个概率分布——比如"正面 0.82、负面 0.11、中性 0.07"。 ...

两年前,你让 AI 生成一张「咖啡馆门口的招牌,写着 OPEN」,大概率会得到一块写着「OPNE」或者「OEPN」的牌子——文字是糊的,字母是乱的,整张图一眼假。 现在你再试一次。GPT Image 1.5、Nano Banana Pro 这一批模型,能把整段菜单文字清清楚楚画在招牌上,中英文混排都行,连字距都对。 这件事说明了一个变化:2026 年的图像生成,已经过了「拼画质」的阶段。 照片级真实感这道坎,几乎所有头部模型都迈过去了。差异不再在「画得像不像」,而是上移到了——能不能听懂复杂指令、能不能把字写对、能不能精确控制构图、版权干不干净。 这篇不吹也不黑,就把 2026 年这批工具的能力边界,实打实地拆给你看。 主流工具:四个梯队,各有各的活 2026 年的图像生成已经不是「一家独大」,而是按场景分工。我把现在真正能打的工具排成四组。 工具 定位 最擅长 短板 GPT Image 1.5(OpenAI) 指令理解之王 复杂多对象指令、文字渲染 风格偏「数字感」,审美不够野 Nano Banana Pro(Gemini 3 Pro Image) 知识型生成 文字、信息图、多语言、4K 偏「正确」,有时缺惊喜 Midjourney V7 / Niji 7 审美天花板 氛围、光影、风格化 指令偏「自由发挥」,可控性弱 FLUX.2(Black Forest Labs) 开发者与可控性 参考图、局部重绘、品牌色精确 开箱审美一般,要调 即梦 Seedream 5 / 通义万相 国产主力 中文场景、电商图、性价比 海外生态、英文长文本略弱 几个判断: GPT Image 1.5 是 DALL-E 3 的继任者。它最大的本事是「听话」——你给一段绕口的指令,比如「左边一只戴红围巾的橘猫看向右边,右边窗台上有三盆多肉,从左到右依次是高、矮、高」,它能基本照做。这种精确执行复杂指令的能力,目前没有对手。 Nano Banana Pro 是 Google 基于 Gemini 3 Pro 做的,特点是「带脑子画图」——它能调用 Gemini 的推理和真实世界知识。你让它画一张「解释光合作用的信息图」,它真能把流程画对,文字标注也对。支持上传最多 14 张参考图同时喂一整套品牌规范,这一点对企业用户很关键。 ...

给你看一个真实的对比。 两个团队,同样要做一支 30 秒的产品宣传片。A 团队拿最强的文生视频模型,写了一段漂亮的 prompt,十分钟出片,画质惊艳——然后发现主角的衣服在第二个镜头变了颜色,客户不要。B 团队画质明显糙一截,但每个镜头的相机怎么推、主角长什么样、最后一帧停在哪,全都对得上。客户选了 B。 这件事说明一个被低估的事实:AI 视频生成早就过了"画得好不好看"的阶段,现在卡在"画得跟不跟你想的一样"。 2026 年发布的模型——Veo 3.1、Runway Gen-4.5、Kling O1、Pika 2.5——画质都够用了,真正的竞争发生在控制层。这篇不横评工具,只讲一件事:怎么让 AI 视频听话。 为什么"可控"比"画质"更卡落地 画质是个连续变量,差一点也能用;可控性是个二元变量,要么对要么废。 商业视频的本质是"带着约束的创作"。客户给你一张产品图,主角的脸不能变,品牌色是固定的 RGB 值,这个镜头要从左往右摇,下个镜头要接得上。这些都不是"建议",是硬约束。一个画质 95 分但主角换了张脸的镜头,商业价值是 0,不是 95。 文生视频的根本问题在这:prompt 是个低带宽的接口。 你想说的是"相机以每秒 15 度的速度向右平摇,主角始终在画面左三分之一",你能写的是"镜头缓缓摇过,主角在一侧"。中间丢掉的信息,模型用它训练数据里的先验给你补——补出来的东西好不好看是一回事,是不是你要的,完全是另一回事。 所以可控视频生成这两年的所有进展,本质上是在干同一件事:给模型加上 prompt 之外的、带宽更高的控制信号。 参考图、相机轨迹、首尾帧、mask,都是这个东西。 flowchart TB P[文字 prompt低带宽] --> M[视频生成模型] R[参考图锁身份/风格] --> M C[相机轨迹锁运镜] --> M K[首尾帧锁起止] --> M K2[局部 mask锁编辑范围] --> M M --> V[可控的视频] style P fill:#fde7c2,stroke:#e8b23c style R fill:#cfe8d5,stroke:#4f9d69 style C fill:#cfe8d5,stroke:#4f9d69 style K fill:#cfe8d5,stroke:#4f9d69 style K2 fill:#cfe8d5,stroke:#4f9d69 橙色那条是大多数人唯一在用的接口,绿色那几条才是 2026 年真正在拉开差距的地方。下面逐个拆。 ...

三年前做一个带检索的 AI 功能,默认动作是去注册一个 Pinecone,或者在 k8s 上拉起一套 Milvus。“做向量检索就得有向量数据库”,这是当时的常识。 2026 年我不会这么干了。我现在的默认动作是反问一句:你的业务数据是不是已经在 Postgres 里了? 如果是,那大概率你不需要再多一个数据库——装个 pgvector 扩展就够了。 这不是图省事。这两年向量检索这个领域发生了一件挺反常识的事:专用向量数据库的护城河,被"在已有数据库里加一个向量列"这件事填掉了一大半。 这篇就讲清楚这件事是怎么发生的,以及——什么场景下你还是真的需要一个专用的。 向量检索这两年变了什么 先说结论:向量检索从"一项需要专门系统的黑科技",退化成了"一种索引类型"。 2022、2023 年的时候,向量检索确实特殊。HNSW 索引怎么建、近似最近邻(ANN)怎么调参、召回率和延迟怎么权衡,这些都是新东西,通用数据库根本不支持。你想做语义检索,除了上专用向量库没有别的选择。专用向量库的价值,很大程度上来自于"别人还做不了"。 到 2026 年,情况倒过来了。HNSW 这种图索引已经是成熟、公开、被反复实现的算法,不再是谁家的秘密。pgvector 作为 Postgres 扩展,把 HNSW 和 IVFFlat 索引、多种距离度量、半精度存储这些都做齐了;0.8 版本之后还补上了"迭代索引扫描"(iterative index scan),专门解决带过滤的向量查询里那个老大难问题——后面会细讲。 换句话说,“做向量检索"这件事本身,已经不构成开一个新数据库的理由了。 它现在更像是"我需要一个 JSON 字段"或者"我需要全文检索”——你的现有数据库基本都能干,只是早几年还不行。 专用向量库不是没价值了,而是价值的位置变了:它不再赢在"能不能做",而是赢在"做到什么规模、做得多快、过滤多复杂"。这是一个量变到质变的边界问题,而不是一个有无问题。 pgvector 为什么吃掉了大半场景 把向量检索塞进 Postgres,带来的好处不是"少装一个软件"这么肤浅。真正值钱的是下面三件事。 第一,数据不用搬,事务是一致的。 绝大多数 AI 功能不是孤立的——一段文档的 embedding,总是挂在某个用户、某个项目、某个权限边界下面。如果向量在专用库、业务数据在 Postgres,你就得自己维护两套数据的同步:文档删了,向量要跟着删;权限变了,检索结果要跟着变。这套同步逻辑写起来不难,但它是一类永远会出 bug 的胶水代码——双写失败、顺序错乱、补偿任务追不上。向量和业务数据待在同一个 Postgres 事务里,这一整类问题直接不存在。 第二,过滤就是普通的 SQL WHERE。 “找语义相近的文档,但限定这个用户、这个时间段、状态是已发布”——这种带元数据过滤的检索是 RAG 里的常态,几乎没有哪个真实业务是纯粹的全库 ANN。在 pgvector 里,这就是一条 SQL,WHERE 子句和向量排序写在一起,还能直接 JOIN 业务表。在专用向量库里,过滤得靠它自己那套 payload/metadata 过滤机制,表达能力通常比 SQL 弱,跨"表"的关联更是做不了。 ...