第 6 章 · 工程化与进阶

本章目标：把前面学的东西拼成"能上线的产品"，并看清进阶方向。核心一句话——Demo 人人会写，能上线、能评测、能控成本，才是工程师的价值。

6.1 记忆管理：让对话"记得住、记得准"

模型本身是无状态的——你不把历史发过去，它就不知道你们之前聊过啥。所以"记忆"本质上是你怎么管理发给模型的 messages。

三种由简到繁的做法：

做法 1：直接带历史（最简单，窗口内够用）

把最近 N 轮对话原样塞进 messages。短对话够用，但窗口会越用越大、越用越贵。

做法 2：滑动窗口 + 摘要

• 滑动窗口：只保留最近 N 轮原文，更早的丢掉。
• 摘要：超出窗口的旧对话，先让模型压缩成一段摘要，再带进上下文。

def manage_memory(history: list, max_turns=10):
    """只保留最近 10 轮，更早的交给模型压缩成摘要。"""
    recent = history[-max_turns:]
    old = history[:-max_turns]
    if old:
        summary = llm.chat.completions.create(
            model="deepseek-v4-flash",
            messages=[{"role": "user",
                       "content": f"把下面对话压缩成 3 句话摘要：\n{old}"}],
        ).choices[0].message.content
        recent.insert(0, {"role": "assistant", "content": f"[历史摘要] {summary}"})
    return recent

做法 3：长期记忆用 RAG（最实用）

把用户的历史、偏好、重要事实存进向量库（就是第 4 章的东西），需要时检索出来喂给模型。这是目前"长期记忆"的主流实现。

一句话：短期记忆靠消息历史，长期记忆靠 RAG。 你已经会 RAG 了，所以"长期记忆"对你不是新概念，只是换个用法。

6.2 评测（Evals）：用指标说话

改了 Prompt、换了模型、调了温度——怎么知道是变好了还是变坏了？ 靠评测，不靠感觉。

建立评测集

准备一批"输入 + 期望输出"的样本，比如 50 条 SQL 翻译对：

EVAL_SET = [
    {"input": "玉米一共入库多少公斤", "expected_sql": "SELECT SUM(weight_kg) FROM grain_inbound WHERE grain_type='玉米'"},
    {"input": "昨天入库几批",       "expected_sql": "SELECT COUNT(*) FROM grain_inbound WHERE DATE(inbound_time)=CURDATE()-INTERVAL 1 DAY"},
    # ... 更多样本
]

跑评测、算分

def evaluate(eval_set):
    passed = 0
    for item in eval_set:
        got = text_to_sql(item["input"])       # 你的函数（第 3 章）
        # SQL 比较不能纯字符串匹配，至少要规范化（去空格、统一大小写）
        if normalize(got) == normalize(item["expected_sql"]):
            passed += 1
    print(f"准确率：{passed}/{len(eval_set)} = {passed/len(eval_set):.1%}")

评测的两类指标：

• 客观题（SQL、JSON、分类）：能自动比对的，直接程序算分。
• 主观题（文案、摘要质量）：用 LLM 当"评委"打分（即"LLM-as-judge"），或人工抽检。

建评测集是件"前期麻烦、后期巨省心"的事。有了它，你每次改动都有据可依，不再靠玄学调 Prompt。

6.3 成本控制

大模型是按 token 计费的，省钱就是省真金白银。几个杠杆：

1. 选对模型：简单任务用便宜模型，复杂任务才上贵的（分级路由）。DeepSeek 之类便宜模型做日常，旗舰模型做关键步骤。
2. 缓存：相同的 system prompt、相同的前缀，很多平台支持"上下文缓存"，命中后输入价格大幅下降。
3. 精简输入：RAG 只喂 top-k 相关段落；历史对话做摘要压缩；别把无关内容塞进 prompt。
4. 控制输出：设合理的 max_tokens，别让模型长篇大论。
5. 算清账：每次调用记 usage，做一个成本看板。你知道"一条请求多少钱"，才能谈"哪里能省"。

6.4 可观测性：出了问题能定位

AI 应用比传统应用更难排查（因为模型是个"黑盒"），所以必须留好"现场"：

• 日志：记录每次请求的完整 messages、模型输出、工具调用、耗时、token 消耗。
• Trace：把一次 Agent 的多步调用串成一条链路，能看到"它先调了 A、再调了 B、结果 C 出错"。
• 工具选择：LangSmith（LangChain 官方）、Langfuse（开源）等，都能自动记录这些。

最低要求：每次模型调用，把"输入 + 输出 + token + 耗时"四样记下来。没有这些日志，线上出问题你只能干瞪眼。

6.5 部署

把 AI 应用变成服务，其实和你熟悉的传统后端部署没本质区别：

1. 封装成 API：用 FastAPI 把"对话 / RAG / Agent"封装成 HTTP 接口。
2. 流式返回：用 SSE 把生成结果边出边推给前端（呼应第 3 章）。
3. 容器化：Docker 打包，密钥走环境变量，别写进镜像。
4. 网关与限流：在 API 前面加鉴权、限流、配额——AI 接口很贵，必须控调用量。

你的优势又来了：部署、鉴权、限流、监控这些，你做了十几年，只是换了个"上游是模型"而已。

6.6 进阶方向（按优先级排序）

学完前面 12 周，你已经能独立做 AI 应用了。想再往上走，按这个顺序：

1. 多 Agent 系统

让多个 Agent 分工协作（研究员、写手、审核员……），用 CrewAI / LangGraph 编排。这是 2026 年企业落地的标配。

2. MCP（Model Context Protocol）

一个"工具接入的通用协议"，让任何 MCP 兼容的工具都能被任何 Agent 直接调用，不用每个框架都写一遍适配。已经成为事实标准。文档：https://modelcontextprotocol.io/

3. 评测体系化

把 Evals 做成 CI 的一部分：每次改代码/Prompt，自动跑评测集，不通过不让上线。

4. 微调（Fine-tuning）

RAG 解决"知识"问题，微调解决"风格/格式/能力"问题（让模型稳定按某种格式输出、学会某种特定任务）。成本高、门槛高，只有 RAG 和 Prompt 都搞不定时才考虑。入门看 Hugging Face 课程：https://huggingface.co/learn

5. 多模态

让模型处理图片、语音、视频（识别单据、语音指令等）。按需学，不必一开始就碰。

6.7 完整资料清单（全部已核实，2026-08）

入门课程（免费，按顺序看）

官方文档（最权威）

• DeepSeek API：https://api-docs.deepseek.com/zh-cn ｜ 开放平台：https://platform.deepseek.com
• LangChain：https://python.langchain.com/ ｜ LangGraph：https://langchain-ai.github.io/langgraph/
• Chroma：https://docs.trychroma.com/ ｜ Milvus：https://milvus.io/zh
• Dify：https://docs.dify.ai/ ｜ MCP：https://modelcontextprotocol.io/

中文教程与社区

• 《RAG 从入门到实战完整教程》：https://rag.deeptoai.com/docs
• Datawhale（LLM 中文学习社区）：https://github.com/datawhalechina

6.8 本章小结

• 记忆：短期靠历史消息，长期靠 RAG。
• 评测：建评测集，用指标说话，别靠感觉。
• 成本：选模型、缓存、精简输入、控制输出、算清账。
• 可观测：记录"输入 + 输出 + token + 耗时"，用 LangSmith/Langfuse 做 trace。
• 部署：FastAPI + SSE + Docker + 网关限流，就是你熟悉的老一套。
• 进阶顺序：多 Agent → MCP → 评测体系化 → 微调 → 多模态。

附：12 周学习计划总表

最后，一句话总结

你不是从零转行，你是给已有的工程能力换一个新的大脑。别人要补的是工程，你要补的只有"跟模型对话"这一件事——而它比你想的薄得多。跟着这份教程，从第 0 周的第一个 API 调用开始，12 周做完那个能上线的项目，你就完成了从"传统工程师"到"AI 应用工程师"的转身。