Day01给 AI 应用开发工程师的大模型全景前言90% 的 AI 应用翻车根因不在 Prompt讲个上个月的真实事故。团队上线了一个 RAG 问答demo 漂亮老板满意。结果一上生产长文本场景下——成本三天翻了 3 倍首 token 延迟从 1 秒飙到 8 秒还时不时冒出幻觉。排查了三天根因是什么不是模型不行不是 Prompt 没写好。是没人在意 Token 计数没人管 Chunk 策略。一个 5 万字的长文档被整段塞进去每一次调用都在为几百块人民币的 token 买单。复盘的数字很难看单次调用的 token 数从 3k 飙到 47k月账单从 800 涨到 2600p99 延迟从 1.2 秒到 8.4 秒——而生成质量反而更差了。做了这么多年 AI 应用开发我越来越确定一件事调 API 谁都会真正卡住团队的永远是底层没吃透。长上下文为什么贵幻觉怎么治选型怎么定Fine-tune 还是 RAG——每一个决策点都通向同一个地方大模型的底层原理。今天这篇我默认你已经是个熟练的 AI 应用开发工程师。封面这张大模型全景图我们不把它当科普看——我们把它当成应用工程师的「决策地图」。顺着 数据 → Token → 向量 → Attention → 生成 → 训练 → RAG/Agent 这条链每一层我都只讲一件事这一层对你做应用开发到底意味着什么。读完下次技术评审你能一锤定音。PART 01Token Embedding —— 应用开发的「计价单位」与「检索基石」新手以为 Token 就是「切词」。老手知道Token 是大模型应用里的一切。它是计费单位——你按 token 付钱输入输出都算。它是上下文窗口——prompt 和生成共享同一份额度prompt 写爆了模型就没空间输出。它还有中英文差异——同样一段话中文切出来的 token 数常常是英文的两倍。你的中文应用成本天然比别人贵。不信拿 tiktoken 实测一下同义的中文和英文表达内容Token 数gpt-4o近似中文大模型应用开发工程师~10英文LLM application engineer~5中文检索增强生成~6英文retrieval-augmented generation~5看到了吧「大模型应用开发工程师」十个汉字切出来比等义的英文多一倍。这就是为什么中文应用的 token 成本天生比英文应用高出一截。所以一个合格的 AI 应用工程师上线前第一件事不是调 Prompt是做 token 预算一次调用平均多少 token、p99 多少、月成本多少、长尾请求会不会把额度打爆。几行代码就能算import tiktoken enc tiktoken.encoding_for_model(gpt-4o) # OpenAI 系列官方 tokenizer text 这是一段需要估算成本的中文输入... n_in len(enc.encode(text)) n_out 800 # 假设输出 800 token # 价格美元 / 1K token按你用的模型填 price_in, price_out 0.0025, 0.01 cost n_in / 1000 * price_in n_out / 1000 * price_out print(finput{n_in} tok, output{n_out} tok, 单次成本≈${cost:.4f})把这段扩成一张「月成本估算表」你就能提前知道这个应用烧不烧钱场景单次输入 token单次输出 tokenQPS月成本美元近似轻量客服8002001~250长文档 RAG470008000.5~1800Agent 多轮1200015000.2~150没有这张表就敢上线等于闭着眼烧钱。⚠️踩坑提醒tiktoken是 OpenAI 的 tokenizer对国产模型DeepSeek、Qwen、GLM计数不准——它们的词表不一样tiktoken 算出来的数能差 20%~40%。上线前一定要换成模型官方的 tokenizer重新估一遍否则预算会严重失真。再说 Embedding。它是RAG 的地基。向量维度选多少、相似度用 cosine 还是 dot product、Chunk 切多大、要不要重叠——每一个都直接决定检索质量。我见过太多团队RAG 效果差第一反应是「换个更强的模型」。错。多数 RAG 翻车翻在 Chunk 策略和 Embedding 选型不是生成模型不行。Chunk 策略的影响比你想的大得多Chunk 策略切法召回效果适用固定长度每 512 字硬切差常切断语义快速 demo按语义切段落 / 标题边界好正经 RAG带重叠相邻块重叠 50~100 字更好不漏边界生产环境至于维度和相似度记住两条经验维度不是越高越好。1536 维够用就别上 3072存储和检索成本翻倍效果未必涨。中文场景相似度优先 cosine。dot product 受向量模长影响归一化后的 cosine 更稳。挑 Embedding 模型别只看维度盯三个指标语种中文场景认准 bge / m3e 这类中文优化模型别拿英文模型硬上、MTEB 榜单排名看 retrieval 子任务不是总分、推理成本线上每秒几千次调用维度翻倍就是真金白银。三者拉齐再选比盲目追「最新最大」靠谱得多。给你一个最小可跑的相似度计算把「地基」摸到手from sentence_transformers import SentenceTransformer model SentenceTransformer(BAAI/bge-small-zh-v1.5) # 中文 embedding docs [如何重置密码, 忘记密码怎么办, 今天的天气不错] vec model.encode(docs, normalize_embeddingsTrue) # 已归一化点积即为 cosine 相似度 sim vec vec.T print(f重置密码 vs 忘记密码 相似度: {sim[0][1]:.3f}) print(f重置密码 vs 天气不错 相似度: {sim[0][2]:.3f})一句话送给同行Token 是大模型应用的「货币」Embedding 是检索的「地基」。这两层没吃透项目必爆预算、必翻检索。PART 02Attention Transformer —— 性能与选型的底层逻辑这一节我不教你手算 Q/K/V——那是研究者的活。作为应用工程师你真正要懂的是 Attention 的工程后果。记住一句话注意力是 O(n²)。意思是上下文长度翻倍注意力的计算量和显存涨 4 倍。这张表把「为什么长上下文贵」说透了上下文长度注意力矩阵大小显存FP16 近似相对成本4k4k × 4k~32 MB1×16k16k × 16k~512 MB16×128k128k × 128k~33 GB1024×1M1M × 1M~2 TB65536×看这张表就懂了把上下文从 16k 拉到 128k单是注意力这一项成本就涨了 64 倍。这就是为什么——长上下文 成本和延迟平方级上涨KV cache成了推理的核心它缓存历史 token 的 K/V避免重复算首 token 延迟就靠它上下文窗口128k / 200k / 1M是各家模型最卷的卖点背后全是 O(n²) 带来的工程取舍。KV cache 到底有多值钱一句话量化没有 KV cache每生成一个字都要把前面全部重新算一遍有了它历史部分直接查表首 token 延迟能从几秒压到几百毫秒。这也是为什么推理框架都在卷 prefill/decode 分离、卷 PagedAttention——本质都在伺候这块 cache。既然 O(n²) 躲不掉应用层得自己兜底三招最常用prompt 精简历史对话压缩成摘要、系统提示去废话、few-shot 例子从 5 个砍到 2 个——token 少一半成本和延迟都跟着掉。滑动窗口只把最近 N 轮塞进上下文更早的用摘要代替别一根筋全塞。分块检索RAG超长文档别整段喂切成 chunk 按需检索——把「必须全进上下文」变成「只进相关的那几段」。这三招的共同点就一句能用检索解决的长文本就别用上下文硬扛。上下文窗口是最后手段不是第一选择。底层逻辑就这几行import numpy as np x np.random.randn(8, 8) # 8 个 token每个 8 维 Q, K, V [x np.random.randn(8, 8) for _ in range(3)] scores Q K.T # 关键这里是 (8,8)token 数翻倍 → 计算量 ×4 weights np.exp(scores - scores.max(-1, keepdimsTrue)) weights / weights.sum(-1, keepdimsTrue) output weights V看Q K.T那行——它就是一个 n×n 矩阵。这就是 O(n²) 的源头也是你一切性能问题的源头。再补一个选型常识今天的主流大模型GPT、Claude、DeepSeek、Llama全是 Decoder-only。这意味着什么意味着你选型、微调、挑推理框架都在围绕同一套架构打转。先分清这三兄弟架构代表擅长注意力方向Encoder-onlyBERT理解分类、Embedding双向Decoder-onlyGPT / Claude / DeepSeek / Llama生成单向因果Encoder-DecoderT5 / 早期翻译模型序列到序列交叉为什么最后 Decoder-only 赢了因为它自回归、单向生成的特性天然契合 scaling law——堆参数和数据就能持续变强工程上也最好统一。生态高度收敛这是好事。选推理框架时认准这三家框架强项适合vLLM吞吐高、PagedAttention高并发在线服务SGLang复杂 prompt 结构、低延迟Agent / 多轮TensorRT-LLM极致单卡延迟英伟达栈、延迟敏感懂了 Attention 是 O(n²)、懂了 KV cache、懂了 Decoder-only——你就懂了为什么推理慢、为什么要缓存、为什么 prompt 该精简。PART 03训练链 RAG/Agent —— 什么自己做什么交给模型最后讲应用工程师最高频的决策这块需求我该 Prompt、RAG还是 Fine-tune先快速过训练链。你不碰预训练那是巨头的事但要懂三步各给模型注入了什么、花了多少成本阶段喂的数据量级给模型注入了什么预训练互联网级语料万亿 token世界常识SFT监督微调指令-回答对万~百万条按指令办事RLHF人类偏好排序千~万条说话得体、对齐预训练→ 给它世界常识SFT→ 教它按指令办事RLHF→ 让它对齐人类偏好。越往后数据越少、越贵、越决定模型「手感」。然后是那张你一定会用到的决策表场景推荐方案理由临时改个输出风格Prompt改一行就生效最便宜知识要可溯源、能更新RAG改库即生效不用重训风格 / 格式固化、领域术语密集Fine-tune把风格烙进权重省 token想用小模型替大模型降本Fine-tune小模型 微调逼近大模型效果三条铁律能用 Prompt 解决就别上 RAG。Prompt 是最便宜的工程改一行就生效。能 RAG就别 Fine-tune。RAG 可溯源、知识能随时更新Fine-tune 每次要重训。Fine-tune 是最后手段。它适合风格/格式固化、领域术语密集或者用「小模型 微调」替掉大模型来降本。RAG 和 Agent 的工程化记两条主线。RAG 标准链路切片 → 向量化 → 检索 →重排rerank很多人省不掉→ 拼上下文 → 生成。每一步都有它存在的理由切片切得不好一个知识点被劈成两半检索永远召不全。向量化Embedding 模型决定召回上限选型比调参重要。检索top-k 别贪多5~10 条够用召得太多既白塞上下文又把真正相关的稀释掉。混合检索向量 关键词 BM25比纯向量稳专有名词、人名、型号这种精确词向量往往召不准。重排向量检索召回快但粗rerank 模型精排把最相关的顶到前面——这一步省掉准确率掉一截。拼上下文召回到的片段要排序、去重、截断塞爆了既贵又触发「中间遗忘」。Agent LLM 工具 循环规划 → 调用 → 观察。它的工程坑不在「能跑起来」而在工具调用稳定性和上下文膨胀——Agent 跑几轮上下文就爆了。最小 Agent 循环长这样def agent_loop(task, max_turns5): context [task] for _ in range(max_turns): action llm_plan(context) # 规划下一步调哪个工具 if action.done: return action.answer result call_tool(action) # 调用执行工具 context compress(context, result) # 观察⚠️ 必须压缩否则几轮就爆 return None注意compress这步——它是 Agent 能不能上生产的分水岭。常用三招历史轮次 summary 压成一段、工具返回结果只留关键字段、超过阈值就滑动窗口丢最早的。不做这步Agent 跑 5 轮上下文就涨到几十 k又贵又慢还容易幻觉。一句话总结这一层资深工程师的判断力就是知道每一层该自己动手还是交给模型。结尾拼完了大模型应用这张全景图从应用工程师视角看就一句话Token 管钱Embedding 管检索Attention 管性能训练链管能力边界RAG/Agent 管落地形态。每一层都是你的一个决策点。做大模型应用调 API 是起点不是终点。真正的护城河是对从 Token 到 Agent 每一层的工程化理解——哪一层没吃透应用就会在哪一层翻车。你的 AI 应用翻过最贵的车是哪一层评论区告诉我下一篇就拆它。下一篇预告Day02 可能讲「RAG 检索为什么总拉胯——Chunk 策略、Embedding 选型与 Rerank 的工程实战」我是小刘檀木一个从二本摸爬滚打到上市公司 AI 负责人的普通人。关注我把 AI 学进简历。— END —小刘檀木 · 帮普通人把 AI 学进简历