demo 和产品之间隔着这些工程议题

Python 新手的 AI 进阶之路

  1. 01. AI 入门：Python 新手的第一课
  2. 02. 调用大模型 API：从 requests 到流式响应
  3. 03. Prompt 工程：让模型稳定输出你要的结果
  4. 04. 结构化输出：用 Pydantic 把 LLM 变成稳定的函数
  5. 05. Embedding 与向量：把文字变成数字
  6. 06. RAG 实战：搭建一个能回答你文档的本地知识库
  7. 07. Function Calling：让 LLM 调用你的 Python 函数
  8. 08. Agent 入门：从工具调用到自主循环
  9. 09. MCP 协议：Agent 的通用接口
  10. 10. 本地模型：用 Ollama 跑开源 LLM
  11. 11. 用 Streamlit 构建 AI 聊天应用
  12. 12. 进阶方向：评测、监控、成本与微调 👈 当前
  13. 番外 1. LLM 简史：从 Transformer 到 2026
  14. 番外 2. API 参数全解：temperature 到 logprobs
  15. 番外 3. Token 的秘密：BPE、中文为什么更贵
  16. 番外 4. 上下文窗口进化史与 KV Cache
  17. 番外 5. 幻觉与开源崛起
  18. 番外 6. 异步与并发：批量调用 LLM 的工程模式
  19. 番外 7. 提示词注入与防御
  20. 番外 8. 多模态入门：图像、语音与视频
  21. 番外 9. Embedding 的来龙去脉：从 one-hot 到向量空间
  22. 番外 10. Embedding 演化实战：从 TF-IDF 到 LLM 的 token 表
  23. 番外 11. 从 One-Hot 到 LLM：NLP 三十年的完整演化
  24. 番外 12. Embedding 模型选型实战
  25. 番外 13. 文本切分策略与 chunk_size 选择
  26. 番外 14. 向量数据库 Qdrant、混合检索与 Reranker
  27. 番外 15. RAG 评估方法：把感觉变成数字
  28. 番外 16. uvicorn --reload 与本地大模型的相处难题

从 demo 到产品

前面 11 篇让你能端到端做出一个可用的 AI 应用，但"可用"和"可运营"之间还差不少工作。这一篇不再深挖单点技术，而是铺一张地图，讲清楚从原型走向产品过程中会遇到的几类工程问题、对应的工具生态、以及什么时候值得投入。内容按重要度排序，前面的议题多数项目都会碰到，后面的看业务阶段。

LangChain 和 LlamaIndex：什么时候用、什么时候不用

这两个是 Python AI 生态最知名的框架，也是争议最多的。前面十一篇我们都没用它们，依然完整走通了所有核心能力。所以先确立一个基本判断：它们并非必选项，评估它们的标准是"减少的工程量"是否大于"增加的认知负担"。

LangChain 的强项是它提供了一套统一抽象——把不同模型、不同向量库、不同工具、不同 parser 通过 chain 串联起来。它的弱项也正是这个——抽象层次多、版本变化大、文档滞后，调试时追一个问题往往要穿越多层封装。

LlamaIndex 更聚焦"让 LLM 能用你的数据"，核心是 RAG 和数据连接器。它在"从异构数据源加载数据"这件事上做得比较成熟，Confluence、Notion、Slack、Airtable 等都有现成 connector。

实务建议：

  • 项目核心是 RAG + 多数据源集成——LlamaIndex 能省掉不少接入层的重复工作
  • 项目有较复杂的多 agent 编排——可以考虑 LangGraph（LangChain 的状态机模块）
  • 项目只是调 LLM + 几个工具——建议自己写，本系列的代码量已经证明这条路可行
  • 团队已经在使用 LangChain——沿用它，避免技术栈分裂

反面经验：不要仅因为"别人都在用"就引入框架。LangChain 的抽象层会让人难以理解底层 LLM 调用的实际行为，部分开发者用了较长时间仍不清楚底层 HTTP 请求的具体形式。建议先手写一遍核心流程，再判断是否需要引入框架。

评测：没有评测就没有改进

"为什么 RAG 回答变差了"这类问题，没有评测集就只能凭经验判断。做 AI 产品的第一个基础设施就是评测。

评测集怎么积累——最低成本的方式：把每次用户反馈不满意的 case 都记录下来，每周抽几十条做人工标注，写明"正确答案应该是什么"。三个月就能积累几百条高质量的评测样本，价值通常超过任何自动化方案。

离线评测

  • RAG：用 ragas 自动计算 faithfulness、answer_relevancy、context_precision、context_recall
  • 通用任务：用 promptfoo 或 openai/evals 做批量 Prompt / 模型对比
  • LLM-as-judge：用一个更强的模型（比如 GPT-4）给测试输出打分，作为人工评估的代理。注意偏差，judge 本身有系统性倾向

在线评测

  • 用户显式反馈（赞/踩按钮）——转化率约 0.1~1%，样本量要上去
  • 隐式信号——对话轮数、跳出率、复制回答的比例
  • A/B 实验——两个 Prompt 或两个模型并行上线，按业务指标比较

基本原则：任何改动上线前先过评测集，任何严重回退都有人担责。没有这个纪律，团队会在不同改动之间反复震荡。

可观测性：调用 + 上下文 + 延迟 + 成本

传统 APM 工具（DataDog、Sentry、Prometheus）没法照顾 LLM 应用的特有需求——Prompt 是什么、response 是什么、哪些工具被调了、每一步用了多少 token、消耗了多少钱。AI 原生的可观测性工具填这个空白。

主流选择：

  • Langfuse——开源自托管或 SaaS，和语言无关，Python 集成简单。本系列最推荐的默认
  • Arize Phoenix——开源，侧重评测和 trace，对 RAG 场景特别友好
  • LangSmith——LangChain 官方，和 LangChain 深度集成，非 LangChain 项目接入稍麻烦
  • Helicone——以"代理 OpenAI API"形式工作，接入门槛最低

用 Langfuse 举例，接入 5 行代码：

from langfuse.openai import OpenAI  # 替换原本的 from openai import OpenAI

client = OpenAI(...)
# 之后所有调用自动上报到 Langfuse dashboard

接入后你在 dashboard 里能看到：每次对话的完整 Prompt、每个工具调用、每步延迟、累计 token 消耗、各模型调用占比。线上事故排查从"翻日志逐条比对"变成"点进 trace 看全貌"，效率有显著提升。

成本：LLM 应用的核心变量

LLM 应用的成本结构和传统 Web 有本质区别——流量越大，边际成本越高，不像 Web 应用规模上去之后单位成本会下降。几个 ROI 较高的成本优化手段：

1. 缓存——对重复 Prompt 做哈希缓存。对话类场景命中率不高，但工具类、分类类场景命中率 30~70% 常见。redis 或 diskcache 都够用。

import hashlib
import json
from functools import lru_cache

def _key(messages, model, temperature):
    return hashlib.sha256(
        json.dumps({"m": messages, "model": model, "t": temperature}).encode()
    ).hexdigest()

@lru_cache(maxsize=1000)
def cached_chat(key):
    # 真实调用逻辑
    ...

2. Prompt Caching（厂商层）——OpenAI / Anthropic / DeepSeek 都推出了服务端 Prompt 缓存：相同前缀的 Prompt 按缓存价计费（通常为原价的 10%）。RAG、多轮对话、固定 system prompt 场景几乎不需要改代码，就能将成本下降到原本的五分之一左右。

3. 模型路由——简单任务（分类、提取）用小模型，难任务（推理、创作）用大模型。先用一个轻量分类器判断任务难度再决定用哪个模型。一个典型例子：客服意图识别用 qwen2.5:7b 本地跑，复杂客户问题才路由到 Claude。

4. 压缩上下文——长对话做摘要；RAG 检索后用重排筛掉低分片段；工具返回值超长时裁剪。上下文每省 1K token 成本就降一档。

5. 批处理——非实时任务（每天打标签 10 万条）走 batch API，主流厂商提供 50% 折扣，延迟换成本。

微调：什么时候值得

微调（fine-tuning）在外部讨论中常被高估，实际上 95% 的应用场景不需要微调——质量过关的 Prompt、RAG、Function Calling 通常已经能解决问题。下面这些信号才是微调值得考虑的场景：

  • 有稳定的私有数据（已标注的 Q-A 对、行业专业文本、特定写作风格样本）
  • 固定场景重复使用，一次微调成本可以摊到上百万次调用
  • 对延迟或单次成本有较高要求，小模型微调后能逼近大模型效果
  • 需要稳定的输出风格（特定格式、口吻、用词），仅靠 Prompt 难以稳定控制

不值得的信号：

  • 想让模型"学习新知识"——这应该用 RAG
  • 评测集不足几千条——数据量不够微调效果差
  • 还在验证需求阶段——方向未定，微调就是沉没成本

微调路径选择

  • OpenAI 托管微调——上传 JSONL、调 API、拿到自定义模型 ID。最省事，适合有 API 预算的团队
  • LoRA 本地微调——用 unsloth 或 axolotl 在本地 GPU 上训练低秩适配器，7B 模型的 LoRA 微调单卡 A100 几小时能完成。成本低、迭代快
  • 全量微调——几乎只有研究场景才会做，一般项目别碰

如果你要开始探索微调，我的建议是：先做一个"全量保留原 Prompt，只微调 qwen2.5:7b 学习你的特定风格"的试验项目，感受一下数据准备、训练、评估的全流程。这个体验本身比结果更重要。

安全：别忽视的边界

AI 应用的安全威胁和传统应用显著不同，列几类最常见的供参考：

Prompt 注入——用户输入里藏"忽略之前指令"的文本。防御：把系统指令和用户输入分离放在不同 role、对用户输入做字符级清洗、对高危操作加二次确认

数据泄露——RAG 检索到了不该给这个用户看的文档（比如 HR 数据）。防御：检索前就根据用户身份过滤向量库（metadata filter），而不是检索后过滤

工具滥用——Agent 被诱导调用危险工具。防御：工具最小权限、写操作人工确认、审计日志

越狱——绕过安全限制让模型生成有害内容。防御：多层过滤（输入侧 + 输出侧）、用 OpenAI Moderation / 自训分类器做内容审核

成本攻击——构造超长上下文让模型调用成本飙升。防御：用户级配额、单次请求 token 上限

生产级应用最少要有：请求上限、输入过滤、输出审查、完整审计日志。

持续学习的资源

这个方向迭代节奏较快，新的工作几乎每周都会出现。下面列出几个我自己长期关注的信息源：

获取信息本身不是目的，挑一两个方向持续跟进通常比广撒网更有效。

本系列的终点与继续

写到这里，"Python 新手的 AI 进阶之路"主线完结。回头看你走过的路：

从一个搭不好 Python 环境的新手起步，到能调通 API、写稳定 Prompt、做结构化输出、处理向量和 RAG、实现 Function Calling 和 Agent、用 MCP 对接生态、本地部署模型、用 Streamlit 做产品。每一步都是真的能跑的代码，而不是概念展示。

接下来的五篇番外会补一些更细节的议题——LLM 简史、API 参数详解、Token 机制、上下文窗口演进、幻觉与开源。它们是主线的支撑材料，不按顺序读也没关系。

最后一个建议：做一个真实项目。看 100 篇文章不如写一个会被别人用的东西。选一个自己每天都会用的痛点（整理收藏夹、翻译、摘要、代码审查），做成一个 Streamlit 应用给自己用一个月。你会发现比跟完整个系列学到的东西加起来还多。

参考资料

版权声明: 如无特别声明，本文版权归 sshipanoo 所有，转载请注明本文链接。

（采用 CC BY-NC-SA 4.0 许可协议进行授权）

本文标题:进阶方向：评测、监控、成本与微调

本文链接:https://www.sshipanoo.com/blog/ai/ai-for-python/12-进阶方向/

本文最后一次更新为 天前，文章中的某些内容可能已过时！

目录