前沿与实践 · Frontier & Practice lv.4 前沿 kp-044

AI 与 LLM 生态

前置知识：kp-041、kp-026

1. 一句话定义

Python 是 AI 的事实通用语：PyTorch（张量计算与训练底座）、HuggingFace transformers（模型与数据集枢纽）、以及 LLM 应用层（官方 SDK、LangChain/LlamaIndex、Agent 框架）——前两者重计算，LLM 应用层重工程。

2. 为什么重要

"模型用 Python 写、训练用 Python 驱动、应用用 Python 组装"。即使不做算法研究，调用与编排 LLM 也已成为后端/自动化的日常技能。

3. 前置知识

kp-041（张量与向量化心智）、kp-020（Pydantic）、kp-042（API 服务）。

4. 核心概念（两层地图）

模型层（重计算）：

python

import torch

t = torch.randn(2, 3, device="mps")     # GPU/Apple Silicon 张量（NumPy 心智 + 设备维度）
t @ t.T                                  # 矩阵乘：autograd 会自动记录梯度

张量 = NumPy 数组 + 自动微分 + GPU——NumPy 语法直接平移（kp-041 的地基价值）。
transformers 的两层抽象：AutoTokenizer（文本→token）、AutoModel（token→表示/生成）。
LLM API 应用层（重工程）：

python

from openai import OpenAI        # OpenAI 兼容协议已成行业事实标准
client = OpenAI()                # base_url/api_key 从环境变量来（kp-037 纪律）

resp = client.chat.completions.create(
    model="gpt-4.1-mini",
    messages=[{"role": "user", "content": "用一句话解释 GIL"}],
    temperature=0.2,
)
print(resp.choices[0].message.content)

结构化输出：Pydantic 模型 + response_format/函数调用 → LLM 输出强类型化（kp-020 的用武之地）。
Agent 框架谱系：LangChain/LlamaIndex（编排与检索）、smolagents/PydanticAI（轻量）、自研循环（工具调用 while 循环）——多数场景自研循环已足够。

5. 原理与机制

text

LLM 应用工程的四根支柱：
  ① 调用层：统一协议（OpenAI 兼容）、流式（SSE）、重试与超时（kp-015）
  ② 上下文层：Prompt 模板、RAG（检索增强：向量化文档 → 相似度召回 → 拼上下文）
  ③ 结构层：Pydantic 校验输出、工具调用（function calling）协议
  ④ 评测层：离线评估集、回归测试（把 prompt 当代码管，kp-035 心智）
本地模型路线：ollama（一行起本地服务，OpenAI 兼容端点）→ 同一套代码切模型

6. 关键事实（模型/图示）

text

选型心智：
  调现成 LLM 做应用     → OpenAI 兼容 SDK + Pydantic（90% 的需求）
  检索私有知识          → RAG（embedding + 向量库）
  要跑本地/私有部署     → ollama / vLLM（推理服务）
  训练/微调             → PyTorch + transformers/peft（进入算法领域，另立学习地图）

7. 直观类比

PyTorch 之于 Python 像自动挡赛车的 ECU：把"梯度怎么传、显存怎么排"这些精密脏活自动化，你只管踩油门（定义网络与损失）。LLM SDK 像请了个极聪明但记性靠不住的外包顾问——要给明确工单（prompt）、要验收交付物（结构化输出校验）、要留工作记录（日志与评测）。

8. 实例与案例

python

# 带结构化输出的最小 LLM 管道
from pydantic import BaseModel

class Review(BaseModel):
    sentiment: str          # "positive" | "negative"
    keywords: list[str]

resp = client.chat.completions.create(
    model="gpt-4.1-mini",
    messages=[{"role": "user", "content": f"分析评论并按 schema 输出: {text}"}],
    response_format={"type": "json_object"},
)
review = Review.model_validate_json(resp.choices[0].message.content)

9. 常见误区

API key 写进代码/前端 —— 泄漏即账单灾难；环境变量 + 服务端代理（kp-037/048）。
把 LLM 当数据库 —— 会编造（幻觉）；事实性查询走检索（RAG）+ 引用，生成只做表达。
不做输出校验 —— JSON 直接 json.loads 后裸用；Pydantic 校验 + 失败重试。
一上来就上框架 —— Agent 编排的本质是"while 循环 + 工具调用 + 状态"；先用裸 SDK 跑通，再评估框架是否值得引入。

10. 自测题

PyTorch 张量与 NumPy 数组的三个本质差异？
RAG 解决 LLM 的什么缺陷？核心流程三步？
为什么 LLM 输出必须过 Pydantic？

参考答案

设备维度（GPU/加速器）、自动微分（autograd 记录计算图）、面向训练的内存/算子生态。
幻觉与知识时效；流程 = 文档切块向量化入库 → 查询向量化召回相似片段 → 把片段拼进 prompt 让模型基于证据作答。
LLM 输出是自然语言概率产物，结构不稳定；Pydantic 提供类型校验与失败信号，是"合同验收"环节。

11. 与其他知识点的关系

kp-041 NumPy/Polars：张量计算的地基心智。
kp-042 FastAPI：LLM 应用的服务层标配。
kp-037 日志：调用与 token 用量的可观测性。

12. 延伸阅读

OpenAI/Anthropic SDK 文档；HuggingFace Course（免费）
ollama：本地模型快速起步