ChatGPT、Claude、Gemini 应付日常问答已经足够好，但助手一旦要面向自己的客户，现成产品就不够用了。System Design Newsletter 五月发布了一篇自建 AI 聊天助手的系统教程，执笔的是《Building LLMs for Production》作者、Towards AI 联合创始人 Louis-François Bouchard，把”从一次 API 调用到生产级助手”的设计过程完整拆开。本文整理其中已公开的核心内容——为什么要自建、系统怎么分层、Token 机制对成本的影响、模型训练管线与选型逻辑——并补上国内落地时需要调整的地方。
现成产品的边界在哪里
客户需要的助手要了解你的产品、你的政策、他与你的历史往来。这些知识存在业务系统里，不在任何模型的训练数据里。把私有数据在运行时塞给模型也不现实：数据量往往超出上下文窗口，敏感程度不允许发给第三方 API，更新频率也让静态提示词很快过时。
教程给出了自建的五个理由，分量并不均等。最硬的一条是隐私与数据主权：对话留在自己的基础设施上，记录什么、存多久、何时删除都由自己决定，对医疗、法律、金融和企业场景来说，这是合规的硬性要求。行为控制其次——系统提示词、人设、护栏都握在自己手里，可以限定回答范围、随时更换底层模型、做 A/B 测试，用现成产品则只能等厂商发什么用什么。剩下三条更偏工程收益：规模化后的成本（提示词缓存、模型分流等手段在日均几千次对话的量级上省得非常可观）、产品集成（助手长在自己的产品里，共享登录态、界面和用户上下文，而不是挂在另一个浏览器标签页里）、以及安全（进模型的内容、出模型的内容、中间跑什么过滤器，整条请求链路都由自己控制）。
作者把界线划得清楚：现成工具适合个人使用和内部原型；当助手本身就是产品或核心功能时，才值得自建。
目标系统与四层架构
教程要做的是一个完全受控的 ChatGPT 式对话助手，需求清单有五项：多轮对话且上下文跨轮保留；流式输出，文字边生成边出现；行为可配置，头脑风暴时发散、数据提取时精确；能抵抗提示词注入攻击；日均几千次对话下成本可控。另有一项后续加入的扩展：跨会话的持久记忆，让助手记住用户偏好。
同样明确的是这个系统不做什么：不检索外部文档，没有训练数据之外的领域知识，也不调用工具执行动作，纯对话。需要工具调用能力的场景属于另一套复杂度，可参考站内的 AI Agent 入门实战。
图：自建 AI 聊天助手的四层架构（据原文架构图重绘）
整个系统分四层：一条用户消息先经过上下文工程层（拼装系统提示词与对话历史），交给生成引擎（大模型 API），结果通过 SSE（Server-Sent Events，服务器推送事件）流式返回前端；持久记忆层与上下文工程双向交互，负责跨会话存取用户信息。教程的各个部分就是逐层展开这张图。
底层模型直接用 OpenAI、Anthropic 这类模型 API，GPU、扩容、推理优化都由服务商处理，这是多数团队合理的起点；等规模大到 API 不划算，再迁移到 vLLM、llama.cpp 或 SGLang 自托管开源模型。
发出一条消息后发生了什么：Token
模型的处理单位是 Token（词元）——映射成数字编号的文本小块，可能是完整单词、词的一部分或单个字符。把文本切成 Token 的过程叫分词（tokenization）。按字符切，序列太长；按整词切，词表爆炸且没法处理生词；子词切分是折中方案，现代模型几乎都用它。最常见的算法是 BPE（Byte Pair Encoding，字节对编码）：从单个字符出发，反复把出现频率最高的相邻组合并成一个 Token。常用词如 “the” 成为单个 Token，长词、生僻词被拆成有意义的片段，比如 “unbelievable” 拆成 “un”+”believ”+”able”。词表规模因此能控制在 3 万到 10 万之间，遇到没见过的词也能用已知子词拼出来。
图：文本切分成 Token 的过程（据原文示意图重绘）
这套机制解释了模型的一类经典失误。问 “strawberry 里有几个 r”，模型可能答错，因为这个词被切成了 “str”+”aw”+”berry”，字母 r 分散在不同 Token 里，模型根本看不到单个字母。倒写单词、数特定字符，这类字符级操作难做的原因相同：模型操作的单位是 Token，不是字母。
对做聊天助手的人来说，分词的工程影响很直接。Token 数不等于单词数，10 个英文单词的句子通常是 13 到 15 个 Token；代码比散文更费 Token；非英语文本每个词消耗的 Token 更多，因为 BPE 词表主要从英文语料构建。API 计费、上下文窗口上限、延迟都按 Token 计算，成本估算和上下文管理都得从这里算起。
中文场景在这一条上要多留一个心眼。早期模型的词表里，一个汉字常被拆成两三个 Token，同样一段话中文比英文费量明显；近两年国产模型（DeepSeek、Qwen 等）针对中文优化词表后，一个汉字大致对应一个 Token 上下。这意味着不同模型跑中文业务的实际成本可能差出一截，报价单上的每百万 Token 单价不能直接横向比较，需要拿自己的真实语料实测折算。
模型是怎么炼成的，以及这对选型意味着什么
预训练阶段模型学语言：在书籍、网页、代码、论文组成的海量语料上学习”给定前文预测下一个 Token”，全程自监督、无人标注。通用知识、语法、写代码的能力都来自这一阶段，同时带来一个副作用：模型学到的是生成看起来合理的续文，并不保证内容真实。聊天助手一本正经说错话（幻觉），根源就在这里。
预训练完的模型只会补全文本，不会听指令、不会对话、不会拒绝有害请求，后训练分两步解决这个问题。SFT（Supervised Fine-Tuning，监督微调）用人工编写的优质对话示范，教会模型助手应有的格式和风格；RLHF（Reinforcement Learning from Human Feedback，基于人类反馈的强化学习）再往前推一步，由标注员在成对回答里选出更好的那个，模型从这些偏好中继续学习。同一个基座模型经过不同的后训练，产品手感可以完全不同；系统提示词之所以有效，也是因为模型在后训练阶段被专门训练过服从开发者层级的指令。
图：从预训练到聊天助手的三个训练阶段
第三个概念是缩放定律（scaling laws）。OpenAI 的 Kaplan 等人与 DeepMind 的 Chinchilla 论文证明，模型能力随参数量和训练数据量按幂律曲线可预测地提升，行业不断做大模型的底气来自这里。对开发者，它解释了 API 报价的分层逻辑：旗舰模型（数千亿参数）单价高但能处理难任务，轻量模型便宜快速但能力有限，frontier、mini、nano 的档位差就是缩放曲线上的位置差。教程由此引出反复强调的省钱手段——模型分流（model routing）：简单问题走便宜模型，识别到复杂问题才切到贵的。放到国内语境这套打法同样成立，常见组合是用 DeepSeek-V3、Qwen-Turbo 一类低价模型接住大部分日常问答，复杂推理需求再切到推理模型；分流判断本身可以用规则或最便宜的模型来做，这一层设计的好坏直接决定账单。
国内落地的两个前提
教程默认使用 OpenAI 或 Anthropic 的 API，这两家在中国大陆都无法直接访问，涉及用户数据的合规场景也不允许把数据发往境外。国内落地一般走两条路：一是换用国内大模型 API——DeepSeek、通义千问、智谱 GLM、Kimi 均提供 OpenAI 兼容接口，教程里的代码结构基本原样可用，只需改 base_url 和模型名；二是按教程后半段的思路直接自托管开源模型，数据完全不出内网，对医疗、金融类场景反而更贴合原文强调的隐私诉求。
另一个前置判断是要不要从零写。如果目标只是内部知识问答或轻量客服，Dify、FastGPT 这类开源应用平台已经把多轮对话、流式输出、提示词管理封装好，配置即可上线，先用平台验证需求再决定是否自研，是更稳妥的路径。这篇教程的价值在于把封装背后的原理讲透——Token 怎么计费、上下文怎么拼、模型怎么选——这些知识在用平台时同样绕不开。
完整教程还覆盖什么
公开部分到训练管线为止。按目录，付费部分还包括：预填充与解码阶段、KV-cache 机制与长对话越聊越慢越贵的原因；temperature、top-p、top-k 等输出参数与幻觉成因；系统提示词、少样本示例、思维链、结构化输出与上下文窗口管理；各档模型的 Token 成本细算、提示词缓存、黄金测试集与 LLM-as-Judge 评估；最后是一个八步实战，从单次 API 调用逐步加到流式输出、JSON 输出、多轮对话压缩、注入防御和持久记忆。评估这一环，站内此前整理过 LLM 评估的 29 个核心概念，可作配套阅读。
原文发布于 System Design Newsletter（newsletter.systemdesign.one），订阅后可读全文，新用户有 7 天免费试读。
© 版权声明
文章版权归作者所有，未经允许请勿转载。
