煎饼果子不放葱

Transformer 到底怎么生成文本：逐层拆解一句话：Transformer 推理就四个阶段——Attention（信息路由）→ FFN（知识存储）→ 层层堆叠（抽象升级）→ 解码（从向量到词）。一旦你把这四个阶段吃透，KV Cache 为什么吃内存、长上下文为什么贵、temperature 到底在调什么、模型为什么会产生幻觉、speculative decoding 怎么加速——这些工程决策突然就变得自然而然了。 阶段一：Attention——让每个 token “看到”其他所有 token一个 token 刚进入 Transformer 层的时候，它对周围的 token 一无所知。Attention 就是来解决这个问题的。 每个 token 通过三个学出来的权重矩阵做投影，产出三个向量： Q（Query，查询）： “我现在需要什么信息？”——当前 token 对历史的检索请求 K（Key，键）： “我这里有什么信息可查。”——每个 token 的索引条目 V（Value，值）： “这就是具体内容。”——被”关注”时实际传递出去的信息 当前 token 的 Q 去跟每...

从 Token 到 RAG：理解 AI Native 数据管道一句话：RAG 不是什么魔法，它只是在”大模型读不懂你的私有数据”这个问题上，搭了一条最务实的桥。这条桥由三块砖铺成——Token、Embedding、Vector Database。搞懂它们怎么连起来的、哪里会断，是每个做 AI 产品的工程师逃不掉的功课。 第一块砖：Token——模型看到的”文字”LLM 不读单词，也不读句子。它只认 token 序列。 输入是 token 序列，输出也是 token 序列。模型一辈子只干一件事：给定一串 token，猜下一个最可能的 token，然后把这个 token 拼到序列末尾，再猜下一个，循环往复。 一个 token 可能是一个完整单词（”apple”），也可能是子词碎片（”un” + “believ” + “able”），甚至只是单个字符——全看分词器怎么切。这是整个管道里最底层的粒度，一切从这里开始。 第二块砖：Embedding——把含义变成数字机器不认文字，只认数字。这是根本矛盾。 Embedding 模型做的事：把一段文本映射成一个固定长度的浮点数向量。Open...

低端设备上让 AI 原生应用”感觉快”的实战指南 一句话结论：在 150 美元、3GB 内存、弱信号的手机上，让应用”感觉快”靠的不是某个单一优化——而是把首次绘制拆成流水线、让虚拟列表根据设备内存动态适配、以及把图片加载做成优先级调度系统。这三件事做到位，白屏、卡顿、图片乱跳全消失。 场景还原做一个新闻资讯应用。首页是卡片滚动列表——标题、摘要、缩略图、日期。纸面上看着简单。 扔到一台 150 美元的 Android 手机上试试：3GB 内存，不稳定的 3G。白屏数秒。图片延迟加载挤得文字到处乱跳。滚动卡成幻灯片。应用”坏了”。 这不是假设——这是每个面向真实用户的工程师最终都要面对的场景。 第一条：首次绘制是流水线，不是单步事件最大的思维误区：认为”首页加载=请求数据→渲染→完事”。 在低端设备上，这个模式必然导致痛苦的白屏。实际上，首次绘制应该是一串渐进的里程碑： 1骨架屏 → 缓存读取 → 缓存渲染 → 网络合并 → 缓存写入 阶段一：骨架屏，0ms 出现应用壳就绪的那一刻，网络字节还没到。骨架屏立刻上屏。 这不是装饰——这是心理锚点。用户看到骨架，认知...

流式输出：AI 原生应用的默认交互范式 一句话结论：流式输出不是 UX 上的锦上添花——它是 LLM 应用的身份基石。但真正的难点从来不是”把 chunk 拼起来显示”，而是分布式状态一致性。搞不定这件事，你的停止按钮、刷新恢复、聊天持久化全是 bug。 本质：LLM 天生就该流式LLM 不是一次性产出整段文字。它 autoregressive 地工作：给定一串 token，预测下一个最可能的 token，追加到序列尾部，循环往复。 换句话说，模型本身就在增量地”吐”内容。那你把内容增量地交给用户，就是最自然的选择。 反过来，让用户盯着白屏等 5 秒、10 秒甚至 30 秒，等完整答复再一口气显示——这等于把”慢”暴露给用户，没有任何缓冲。用户会觉得应用坏了。 流式输出把体验翻转了：文字立刻开始出现，感知延迟大幅降低。更关键的是，它把”黑盒查询”变成了”实时协作”——用户可以边看边判断方向对不对，发现模型跑偏就立刻打断，省下浪费的 token。 这种可中断、可纠偏的交互模式，正是 AI 原生应用和传统 Web 应用的分水岭。 核心难点：三层状态机聊天 UI 看起来简单——接...