Appearance
LLM 与生产化总目录
版本：
v1.9最后更新：
2026-07-08
这个目录现在作为 LLM专题 和 LLMOps专题 的统一入口使用。
它的目标不是把两套内容平铺在一起，而是把“能力层理解”和“生产化治理”串成一条更自然的阅读路径：先理解模型、RAG、Embedding、Fine-tuning、Evals、Token 和成本，再进入发布、灰度、评测闭环、观测、回滚和长期运行治理。
1. 合并后的目录结构
1.1 LLM核心专题
- 01-RAG详解.md
- 02-Embeddings详解.md
- 03-Fine-tuning详解.md
- 04-Evals与评测体系详解.md
- 05-Token、Tokenizer与上下文窗口.md
- 06-模型选择、成本与延迟.md
- 07-LLM参数与采样控制.md
- 08-LLM协议、消息与工具交互.md
1.2 生产化与治理
- 生产化与治理首页
- 01-LLMOps与生产化详解.md
- 02-发布、灰度与回滚治理.md
- 03-评测门禁、回放与版本基线.md
- 04-成本、延迟与异步运行策略.md
- [05-可观测性、Tracing与Trace Grading.md](../LLMOps专题/05-可观测性、Tracing与Trace Grading.md)
- 06-缓存、Batch、Flex与后台任务编排.md
2. 这个总目录适合怎么读
2.1 想先把大模型主线补完整
- 01-RAG详解.md
- 02-Embeddings详解.md
- 04-Evals与评测体系详解.md
- 05-Token、Tokenizer与上下文窗口.md
- 06-模型选择、成本与延迟.md
- 07-LLM参数与采样控制.md
- 08-LLM协议、消息与工具交互.md
2.2 想直接补生产治理
- 生产化与治理首页
- 01-LLMOps与生产化详解.md
- 03-评测门禁、回放与版本基线.md
- [05-可观测性、Tracing与Trace Grading.md](../LLMOps专题/05-可观测性、Tracing与Trace Grading.md)
- 06-缓存、Batch、Flex与后台任务编排.md
- 04-Evals与评测体系详解.md
- 06-模型选择、成本与延迟.md
- 07-LLM参数与采样控制.md
- 08-LLM协议、消息与工具交互.md
- 平台工程/index.md
2.3 想往 RAG / Agent / 平台工程继续延伸
3. 这两层内容之间是什么关系
3.1 LLM核心专题
这一层主要解决“模型能力层”的问题：
- 知识怎么补
- 语义表示怎么做
- 微调什么时候值得做
- 评测怎么建
- 上下文和 token 约束怎么理解
- 参数和采样怎么收敛
- 协议和工具交互怎么定边界
- 模型、成本和延迟怎么权衡
3.2 生产化与治理
这一层主要解决“运行层”的问题：
- 版本怎么发
- 评测怎么接进发布
- 成本、缓存、batch、background 怎么治理
- trace、后台任务和任务分层怎么接成运维闭环
- 质量波动怎么定位
- 回滚、审批和长期运行怎么接住
4. 当前官方资料最值得先建立的几个共识
按 2026-07-08 复核可访问的 OpenAI 官方指南、MCP 官方文档和 A2A 官方文档，比较值得先建立的共识有这些：
4.1 Text generation 只是入口，不是完整系统设计
OpenAI 当前 Text generation、Conversation state、Built-in tools、Background mode、Streaming 这些资料放在一起看，会很清楚地发现一件事：
- 大模型接口不再只是“给 prompt 回一段文本”
一旦进入真实业务，系统就会同时面对：
- 会话状态
- 工具调用
- 结构化输出
- 异步运行
- 审批与人审
- 评测与回放
所以 LLM专题 不该只学提示词和模型名字，还要学消息组织、输出约束、工具 contract 和运行边界。
4.2 Embeddings 解决的是表示与召回，不直接解决正确答案
OpenAI 当前 Embeddings、Retrieval 与 File search 的资料都在提醒一个现实：
- embedding 把内容变成可比较的表示空间
- retrieval 把候选证据取回来
- 但最终答案是否可信，还取决于切片、过滤、重排、引用和生成
这也是为什么：
- RAG 做不好，不能只怪 embedding
- 向量数据库也不是完整知识系统
4.3 Fine-tuning 更像“优化手段”，不是默认起手式
OpenAI 当前 Fine-tuning 与 Model optimization 路径更强调：
- 先明确任务目标
- 先用 prompt、schema、工具和评测把问题描述清楚
- 再判断是否真的值得进入微调
也就是说，更成熟的顺序通常是：
- 先把输入输出 contract 讲清楚。
- 先用 eval 看清稳定退化点。
- 再决定是否用 fine-tuning 去换稳定性、风格或格式收益。
4.4 Evals 不是附录，而是发布门禁
OpenAI 当前 Evals、Evals design guide、Graders、Tools evaluation 这类资料已经把评测放到了非常靠前的位置。
更贴近生产环境的理解通常是：
- eval 不是论文式跑分
- 而是版本切换、prompt 变更、工具变更、检索变更前的门禁机制
所以 04-Evals与评测体系详解.md 不是可选补充，而是整组资料里的关键中轴。
4.5 参数、schema 和协议是“稳定性控制面”
很多人把 temperature、top_p、structured outputs、function calling、消息协议当成互不相关的小功能，但系统做大以后，这几件事其实都在解决同一个问题：
- 怎样让模型输出更可预测、更可验证、更适合接系统
这也是为什么：
07-LLM参数与采样控制.md应该和08-LLM协议、消息与工具交互.md
放在一条连续阅读链上。
4.6 MCP 和 A2A 处在不同层，不要混成一个概念
当前公开资料里，MCP 和 A2A 的定位并不相同：
- OpenAI
MCP and Connectors与 MCP 官方文档，更偏“如何把工具、资源、提示模板标准化暴露给模型或应用” - A2A 官方文档，更偏“不同 agent / agentic service 之间如何交换任务、状态和结果”
更务实的理解通常是：
messages / tools / structured outputs先解决单模型与单应用边界MCP再解决能力接入标准A2A再解决 agent 与 agent 之间的协作协议
4.7 Responses、conversation state 和 streaming 已经把“接口层”升级成系统设计问题
OpenAI 当前 Text generation、Conversation state、Streaming API responses、Migrate to the Responses API 的资料放在一起看，会发现一个很关键的变化：
- 接口层不再只是“换个 endpoint”
它已经开始直接影响：
- 会话状态放在哪一层
- 流式事件怎么被消费
- 工具调用和结构化输出怎样进入运行循环
- 前端、编排层、回放层怎样理解一次响应的生命周期
尤其在 Responses API 路径下，streaming 不再只是“拼接文本片段”，而是 typed events。工程上这意味着：
- UI 消费层
- trace / replay 层
- tool loop 编排层
最好都明确知道自己在处理哪一类事件，而不是把所有输出都当成一串纯文本增量。
4.8 reasoning models 和 GPT models 更像分工协作，不是简单替代
OpenAI 当前 Reasoning models 与 Reasoning best practices 的资料已经把差异说得很明确：
- GPT 系列更适合速度、成本和定义清晰的执行任务
- reasoning 系列更适合高可靠性、复杂决策和多步推理
这给 LLM 主线带来一个非常实用的判断：
- 模型选择不是只看排行榜，而是先看任务 lane
很多真实系统更像：
- GPT 模型负责高频执行
- reasoning 模型负责复杂判定、评审或 planning
如果这一层不分清，团队就很容易在：
- 不需要推理的地方过度花钱
- 真正需要高可靠推理的地方又配了错误模型
5. 这组内容里最容易混淆的五个决策
5.1 先改 prompt，还是先做 fine-tuning
如果问题主要是：
- 指令不清晰
- 输出字段不稳定
- 工具参数经常乱填
- 格式不一致
通常应先看：
而不是立刻做 fine-tuning。
5.2 先做 RAG，还是先做微调
如果核心问题是：
- 知识更新快
- 事实来源需要可追溯
- 需要引用
- 每个租户知识不同
一般应优先看：
如果核心问题是：
- 输出风格长期不稳
- 标签判断或格式化模式需要被模型固化
再去看：
5.3 先控 token 与上下文，还是先换更强模型
很多成本和效果问题并不是“模型不够强”，而是：
- context 组织太乱
- 历史消息冗余
- 检索证据过脏
- 输出约束不够清楚
这类问题通常先读：
再决定是否升级模型规格。
5.4 参数问题和策略问题不要混在一起
很多“temperature 调不稳”的问题，本质上其实是：
- 任务没有 schema
- 判定没有示例
- 工具 contract 太宽
- 系统消息职责混乱
参数更像调味，不该替代结构化设计。
5.5 工具调用、MCP、Agent 协作不是同一层问题
可以把它们粗分成三层：
- 模型怎么产出结构化调用意图。
- 工具怎么以本地 function 或 MCP 形式暴露。
- 多个 agent 怎么通过 A2A 或工作流相互分工。
如果这三层不分清，系统会很容易一开始就设计过度。
5.6 Built-in tools、function calling、MCP 和 Agents SDK 也不是同一层问题
OpenAI 当前 Using tools、Function calling、MCP and Connectors、Agents SDK 的官方资料，实际上对应四类不同需求：
- built-in tools：优先复用官方内建能力
- function calling：你自己掌控工具执行与二次请求循环
- MCP：把工具、资源、提示模板标准化暴露出来
- Agents SDK：把 recurring orchestration、sessions、tracing、guardrails、approval flow 一起托管进运行框架
更贴近工程现实的判断通常不是“哪个更新潮”，而是：
- 你要不要自己写 tool loop
- 你要不要标准化接企业能力
- 你要不要内建 sessions、trace、approval 和 handoff 这些运行层能力
5.7 Model optimization / RFT 更适合放在 eval 成熟之后，而不是放在问题描述之前
OpenAI 当前 Model optimization、Fine-tuning、Reinforcement fine-tuning 放在一起看，会得到一个很一致的工程结论：
- 先把任务、输出 contract、grader 和基线讲清楚
- 再进入 optimization 或 RFT
尤其 RFT 明确依赖 programmable grader。也就是说，如果团队现在还说不清：
- 好答案到底怎样判
- 哪类失败最值得优化
- 当前基线和回归门禁是什么
那直接进入优化阶段，通常只会把混乱放大。
6. 按角色更适合怎么读
6.1 应用研发
优先顺序通常是：
重点关注：
- 输入输出 contract
- token 与上下文预算
- 结构化输出和工具接入
6.2 平台与架构
优先顺序通常是：
重点关注：
- 路由与成本
- 发布门禁
- 工具 contract
- 运行治理
6.3 产品、运营与评测
优先顺序通常是：
重点关注：
- 任务分桶
- 样例治理
- 版本比较
- 成本与体验平衡
6.4 安全与治理
优先顺序通常是：
重点关注：
- 工具和协议边界
- 数据进入上下文的方式
- 人审、审批和审计留痕
6.5 模型平台或基础设施负责人
优先顺序通常是：
重点关注：
- lane 分层
- 会话状态策略
- streaming / replay 事件模型
- 评测门禁与运行治理
7. 建议搭配阅读
8. 重点官方资源
以下资源已按 2026-07-08 复核可访问：
- OpenAI Text generation
- OpenAI Conversation state
- OpenAI Streaming API responses
- OpenAI Migrate to the Responses API
- OpenAI Embeddings
- OpenAI Retrieval
- OpenAI File search
- OpenAI Fine-tuning
- OpenAI Model optimization
- OpenAI Reinforcement fine-tuning
- OpenAI Evals design guide
- OpenAI Evaluating model performance
- OpenAI Reasoning models
- OpenAI Reasoning best practices
- OpenAI Cost optimization
- OpenAI Structured outputs
- OpenAI Built-in tools guide
- OpenAI Function calling
- OpenAI MCP and Connectors
- Model Context Protocol Intro
- Model Context Protocol Specification
- A2A Protocol