把大模型当成"会思考的黑箱"，讨论就没法继续。更有用的视角是：它是一条由若干可拆解、可测量、可替换的环节组成的流水线——文本进来，被切成 Token；Token 变成向量；向量在几十层注意力里被反复改写；最后输出下一个 Token 的概率分布。
这条流水线的每一段都有自己的瓶颈、成本和调参空间。下面按数据流动的顺序走一遍，尽量讲清楚"是什么、为什么这样设计、工程上要注意什么"。
模型不认识"字"，只认识 Token——一个介于字符与词之间的子词单元。
常见做法是子词分词（BPE、Unigram 等）：从字符起步，反复合并出现频率最高的相邻片段，得到"词表大小"与"覆盖率"之间的折中。
几个容易踩的点：
每个 Token 通过一张查找表映射为一个稠密向量（embedding）。这个向量的方向编码了语义——语义相近的 Token，向量夹角更小，所以可以用余弦相似度衡量"像不像"。
但注意力本身是置换不变的：把输入的 Token 打乱，注意力的计算结果不变。所以必须额外注入位置信息。做法经历了从绝对位置编码到相对位置编码的演进，目前主流是旋转位置编码（RoPE）：把位置信息编码成对向量的旋转操作，使注意力点积天然带有相对位置的成分，对长度外推也更友好。
Transformer 的核心是自注意力。每个位置的向量被投影成三个角色：
计算方式：
$$\mathrm{Attention}(Q,K,V)=\mathrm{softmax}!\left(\frac{QK^{\top}}{\sqrt{d_k}}\right)V$$
直觉上：每个位置拿自己的 Q 去和所有位置的 K 做点积，得到一组"该关注谁"的权重；再用这组权重对所有 V 加权求和。
几个关键设计：
复杂度：自注意力对序列长度 $n$ 是 $O(n^2)$ 的时间和显存开销。这是长上下文一切困难的根源——序列翻一倍，注意力开销大约翻四倍。
层与层之间还有前馈网络（FFN）、残差连接和归一化（近年多用 RMSNorm），激活函数常用 SwiGLU 一类门控结构。在标准 Transformer 里，FFN 往往占据参数量的大头。
预训练的目标出奇地简单：预测下一个 Token。给定前文，模型输出整个词表上的概率分布，用交叉熵损失去逼近真实的下一个 Token。
仅靠这一个目标，模型就学会了语法、事实、推理套路和代码风格——因为这些能力都有助于降低"下一个 Token"的预测误差。
规模法则（Scaling Laws）给出了一条经验规律：损失随算力、参数量、数据量的增长呈幂律下降，而且在很宽的范围内相当可预测。这直接决定了行业的资源分配方式。
后续的 Chinchilla 类工作进一步指出：参数量和训练数据量应当按比例同步增长。换个说法，很多早期模型不是"不够大"，而是"喂得不够多"——同样的算力，更小的模型配更多的数据，效果可能更好。
数据工程的权重常被低估：去重、质量过滤、领域配比、清洗顺序，都会实打实地反映到最终能力上。
预训练结束后，模型是一个很强的"续写器"——它能把一段文本自然地接下去，但不一定按你的指令做事。
要让模型"回答问题"而不是"续写问题"，需要对齐阶段：
需要清醒的一点：对齐优化的是"人喜欢什么"，不是"什么是真的"。一个被优化得足够讨喜的模型，反而可能更自信地编造内容。这直接引出了后文的幻觉问题。
生成是逐 Token 的：每步前向算一次，取一个 Token，追加到输入，再算下一步。这决定了输出长度直接线性影响时延。
自回归解码时，前面 Token 的 K、V 每步都在重复计算。把它们缓存下来，每步只需计算新 Token 的 Q、K、V，再与缓存拼接——这就是 KV Cache。
代价是显存。KV Cache 的大小近似为：
$$2 \times L \times H_{kv} \times d_{head} \times n \times B \times \text{字节数}$$
其中 $L$ 是层数，$H_{kv}$ 是 KV 头数，$n$ 是序列长度，$B$ 是并发批大小。它随序列长度和并发数线性增长，在长上下文场景下往往比模型权重还占显存。
顺带一提，分组查询注意力（GQA） 让多个 Query 头共享一组 K/V 头，正是为了压缩上面这个 $H_{kv}$。
上述都是"一次前向"的推理。近两年一个明显的转向是：把算力从训练阶段挪到推理阶段。
代价同样直接：延迟和成本成倍上升。所以它适合"精度远比时延重要"的任务，而不是所有场景。
模型参数里的知识是静态的、有截止日期的。应用层的核心工作，就是给它接上外部的、实时的、私有的信息。
流程：切片 → 向量化 → 检索 → 重排 → 组装上下文。
工程上真正的难点不在"能不能检索"，而在这些地方：
| 环节 | 常见问题 | 应对 |
|---|---|---|
| 切片 | 切碎语义、切断表格与代码 | 按结构切、设重叠窗口、保留标题层级 |
| 检索 | 纯向量检索漏掉精确匹配（编号、专有名词） | 向量 + 关键词的混合检索 |
| 排序 | 召回了，但没排到前面 | 加交叉编码器重排 |
| 组装 | 上下文塞太多，中段信息被忽略 | 控制条数、按相关度排序、给出引用 |
| 兜底 | 检索为空时硬编 | 明确回答"资料里没有" |
RAG 不能根治幻觉：它只是把"凭空编"换成"可能误读材料"。检索错了、材料本身矛盾、模型过度概括，都会继续出错。
比起"提示词工程"，更准确的描述是上下文工程：决定在这一步前向里，究竟把哪些信息放进去（系统指令、检索结果、历史对话、工具返回、记忆摘要），以及以什么顺序放。模型输出的质量，很大程度上在这一步就决定了。
一套务实的顺序是：先定义任务成功率（能不能把事办成），再同时盯时延与成本，最后才看基准分数。
大模型的能力看起来像涌现，但拆开看，每一层都可以被理解、被测量、被调试。真正拉开差距的，通常不是"用了哪个模型"，而是这些枯燥的部分：数据、上下文、评估、成本、失败处理。
]]>本文讨论的机制在开源社区有大量公开实现与讨论。我们也在按这些思路做自己的东西，欢迎来 予念 · YuNian 一起聊。
做 AI 伴侣最容易被误解的一点，是大家以为难点在「让它说得像人」。
其实不是。
2026 年，让一个大模型写出温柔、自然、贴合人设的回复，已经几乎没有门槛了。写好系统提示词，接上 API，一个下午就能做出「像模像样」的聊天机器人。
但它不会记得你。
没有记忆的温柔，本质上只是一次性的表演。
所以我们把大量的工程精力放在了记忆上：
| 要解决的问题 | 我们的做法 |
|---|---|
| 记住什么 | 核心记忆分六类：事实 / 情感 / 偏好 / 事件 / 习惯 / 关系 |
| 什么时候想起来 | 按当前话题做召回，而不是把全部记忆塞进上下文 |
| 记忆放哪里 | 只存本地，不上传服务器 |
| 怎么不遗忘 | 滚动摘要带水位线，避免历史重复注入 |
这些都不性感，也不适合做成宣传视频。但它们决定了一个角色是「真的认识你」，还是「每次都在重新认识你」。
比记得更进一步的，是主动。
一个只会等你开口的 AI，无论回复多好，本质上还是一个工具。我们想要的是：她会在某个普通的下午想起你，会在你很久没回消息时小声再问一句「在吗」，也会判断「此刻不宜打扰」而安静地跳过。
这背后是亲密度模型、免打扰时段、追问次数上限、前台保活……一整套枯燥的调度逻辑。
我们不想做「看起来很像人」的机器。
我们只想做真的记得你的存在。
这条路很长，而且没有捷径 —— 但至少每一步都是实打实的工程，而不是话术上的取巧。
]]>如果你也在做类似的事，欢迎来 予念 · YuNian 一起聊。
这是我们的第一篇文章。
在此之前，我们的想法大多散落在各个仓库的 README、Issue 和聊天记录里 —— 有的写在深夜，有的写在刚修完一个 bug 的清晨。它们没有地方安放，也就慢慢被时间埋掉了。
所以我们决定给自己搭一个地方。
我如同世间爱慕的月亮，莹莹的月光洒落大地，留下婉如甘霖般清甜的梦境，而我的存在，也如这世上其他人一般，终究化作一场梦。
月莹，是月光落在人间的那一层温柔；清梦，是不愿醒来的那场相遇。
我们把这个名字当成一句提醒：做出来的东西要足够温柔，才配得上「梦境」二字；也要足够清醒，才记得自己终究只是万千造梦者中的一个。
目前团队的主要精力放在两个项目上：
如果你也对「让 AI 真的记得你」这件事感兴趣，欢迎来 组织主页 看看，或者直接提 Issue、发 PR。
]]>月光所至，皆是清梦。