AI 从零到精通验收清单

这一页用来判断你是否真正理解 AI 应用，而不是只会调用一次模型接口。商业 AI 系统的难点不在“能不能生成一段话”，而在“能不能稳定、可控、安全、低成本地把模型能力接入业务流程”。

学懂 AI 应用，至少要能回答：

大模型为什么能生成文本，也为什么会幻觉。
Token、上下文窗口、温度、流式输出分别影响什么。
Transformer、Attention、Embedding、向量检索、RAG 的工作链路是什么。
Prompt 为什么不是万能安全边界。
工具调用为什么必须由后端做权限、参数、幂等和审计。
AI 上线后如何评估、灰度、回滚、监控成本和排查问题。

总学习路线

mermaid

flowchart TD
    A["AI 基础概念"] --> B["大模型与 Token"]
    B --> C["Transformer 与 Attention"]
    C --> D["Prompt 与结构化输出"]
    D --> E["Embedding 与向量数据库"]
    E --> F["RAG 离线建库和在线问答"]
    F --> G["Tool Calling 与 Agent"]
    G --> H["评估、安全、数据治理"]
    H --> I["LLMOps、部署、推理优化"]
    I --> J["商业场景落地和面试闭环"]

不要一上来就学 Agent 或微调。很多企业 AI 项目失败，不是因为模型不够强，而是基础链路没做好：文档切分混乱、权限过滤缺失、Prompt 不可评估、工具调用没有幂等、日志泄露敏感信息、上线后没有效果监控。

阶段一：AI、大模型和传统程序的区别

传统程序是“规则驱动”：开发者写清楚 if/else、SQL、流程图，机器按规则执行。

大模型是“概率生成”：模型根据上下文预测下一个 token，不是像数据库一样查出一个确定事实。

mermaid

flowchart TD
    A["用户输入"] --> B["上下文和 Prompt"]
    B --> C["模型计算 token 概率"]
    C --> D["选择下一个 token"]
    D --> E{"是否结束"}
    E -- "否" --> C
    E -- "是" --> F["生成最终回答"]

这解释了两个关键现象：

现象	原因	商业后果
模型能写自然语言	它学习了大量语言模式和知识关联	适合问答、摘要、抽取、生成、辅助分析
模型会幻觉	它生成的是最可能文本，不是事实校验结果	医疗、金融、权限、金额等场景必须接 RAG、工具和校验

所以 AI 应用不能把所有问题都丢给模型。正确做法是：规则能确定的用规则，事实数据从业务系统查，文档知识用 RAG，模型负责理解、组织、生成和辅助决策。

阶段二：Token、上下文窗口和推理参数

Token 是模型处理文本的基本单位，不完全等于汉字、英文单词或字符。

Token 影响三件事：

影响	解释
成本	很多模型按输入 token 和输出 token 计费
延迟	输入越长、输出越长，推理越慢
截断	超过上下文窗口后，旧内容或资料可能被截断

上下文窗口不是“无限记忆”。如果把大量无关历史、文档和工具结果都塞进 Prompt，会出现：

成本升高。
响应变慢。
重要资料被噪声淹没。
模型注意力分散，回答反而变差。

温度可以简单理解为随机性：

参数倾向	适合场景
低 temperature	客服、知识库、抽取、代码、标准回答
高 temperature	创意写作、标题生成、脑暴

商业系统里，知识库问答、结构化抽取、工具调用通常要低随机性，因为稳定比“有创意”更重要。

阶段三：Transformer 和 Attention

Transformer 是很多大模型的基础结构，核心是 Self-Attention。Self-Attention 让每个 token 在理解自己时，都能根据相关性关注其他 token。

简化流程：

mermaid

flowchart TD
    A["输入 token"] --> B["转成向量"]
    B --> C["计算 Q、K、V"]
    C --> D["Q 和 K 计算相关性"]
    D --> E["按权重汇总 V"]
    E --> F["得到上下文相关表示"]
    F --> G["多层堆叠形成复杂能力"]

Q、K、V 的理解：

名称	类比
Query	当前 token 想找什么信息
Key	其他 token 提供什么匹配特征
Value	其他 token 真正贡献的内容

为什么需要位置编码：Attention 本身不天然知道顺序。如果没有位置，模型很难区分“用户删除订单”和“订单删除用户”这种顺序差异。

你不需要从零训练 Transformer，但必须理解它带来的工程后果：

上下文越长，计算成本越高。
模型逐 token 生成，所以长输出会慢。
相同 Prompt 不一定每次完全相同，必须做评估和约束。
模型不是数据库，事实要由业务系统或 RAG 提供。

阶段四：Prompt 和结构化输出

Prompt 的作用是把任务说清楚，但它不是安全边界。

一个商业 Prompt 至少包含：

部分	作用
角色	限定模型身份，例如“你是医疗数据资产助手”
任务	明确要做什么，例如“根据资料回答问题”
上下文	提供 RAG 资料、业务字段、历史摘要
约束	不知道就拒答，不编造，不泄露敏感信息
输出格式	JSON、Markdown、表格或固定字段
示例	给模型稳定参考

结构化输出示例：

json

{
  "answer": "根据资料，资产状态分为启用、停用、报废。",
  "citations": ["doc-1001#chunk-3"],
  "confidence": "high",
  "needHumanReview": false
}

为什么结构化输出重要：

后端可以解析。
前端可以稳定展示。
可以做字段校验和重试。
可以记录引用、置信度、是否需要人工审核。

错误做法是只告诉模型“请返回 JSON”。模型仍可能返回解释文字、漏字段、字段类型不对。生产上要配合 JSON Schema、解析失败重试、字段校验和兜底。

阶段五：Embedding 和向量数据库

Embedding 是把文本变成向量，让机器能比较语义相似度。

mermaid

flowchart TD
    A["文档文本"] --> B["Embedding 模型"]
    B --> C["向量"]
    C --> D["写入向量数据库"]
    E["用户问题"] --> F["同一个 Embedding 模型"]
    F --> G["问题向量"]
    G --> H["相似度检索"]
    D --> H
    H --> I["返回相似 Chunk"]

关键原则：入库文档和查询问题必须使用同一个 Embedding 模型，否则不在同一个向量空间，距离没有意义。

向量相似度高不等于一定能回答。原因包括：

片段语义接近，但没有答案。
Chunk 切太碎，缺上下文。
Chunk 切太大，噪声太多。
问题需要精确字段、错误码、表名，纯向量召回不如关键词。
用户没有权限访问被召回资料。

所以生产 RAG 常用混合检索：向量检索负责语义，关键词检索负责精确词，Rerank 负责二次排序，权限过滤负责安全。

阶段六：RAG 离线建库

RAG 不是“把文档丢进向量库”这么简单。离线建库质量决定在线回答质量。

mermaid

flowchart TD
    A["采集文档"] --> B["解析文本和表格"]
    B --> C["清洗无效内容"]
    C --> D["敏感信息脱敏"]
    D --> E["按语义切分 Chunk"]
    E --> F["补充元数据"]
    F --> G["生成 Embedding"]
    G --> H["写入向量库"]
    F --> I["写入结构化库"]

元数据至少要有：

字段	用途
docId	定位原文
chunkId	定位具体片段
title/path	展示引用和上下文
version	支持发布、回滚、排查
tenant/department/role	权限过滤
status	删除、下线、草稿、已发布
contentHash	判断内容是否变化
embeddingModel	追踪向量模型版本
batchId	排查一次入库任务

如果只存文本和向量，会导致：

删除文档后旧 Chunk 仍被召回。
用户越权看到其他部门资料。
答案没有引用来源。
更换 Embedding 模型后不知道哪些数据要重建。
RAG 答错时无法追踪是哪次入库导致。

阶段七：RAG 在线问答

在线问答链路：

mermaid

flowchart TD
    A["用户提问"] --> B["鉴权和参数校验"]
    B --> C["问题改写和意图识别"]
    C --> D["生成权限过滤条件"]
    D --> E["向量和关键词混合检索"]
    E --> F["Rerank 二次排序"]
    F --> G{"是否达到阈值"}
    G -- "否" --> H["拒答或转人工"]
    G -- "是" --> I["组装 Prompt"]
    I --> J["调用模型生成"]
    J --> K["引用校验和安全检查"]
    K --> L["返回答案并记录日志"]

为什么不能先全库检索再让模型“不要泄露”：模型不是权限系统。权限过滤必须在检索前或检索时完成，只在用户有权访问的集合里召回。

RAG 答错排查：

层次	检查问题
数据层	正确文档是否入库，是否被删除或未发布
切分层	正确答案是否被切散，表格是否解析错
权限层	当前用户是否有权召回正确资料
召回层	TopK 是否包含正确 Chunk
排序层	Rerank 是否把正确 Chunk 排前面
Prompt 层	是否明确要求基于资料回答
生成层	模型是否编造、是否引用不一致
日志层	是否记录 docId、chunkId、score、promptVersion、modelVersion

阶段八：Tool Calling 和 Agent

Tool Calling 让模型选择业务工具并生成参数，但真正执行工具的是后端。

mermaid

flowchart TD
    A["用户问题"] --> B["模型看到工具 Schema"]
    B --> C["模型选择工具和参数"]
    C --> D["后端解析工具调用"]
    D --> E["鉴权、校验、幂等、风控"]
    E --> F{"是否允许执行"}
    F -- "否" --> G["拒绝并审计"]
    F -- "是" --> H["调用真实业务系统"]
    H --> I["裁剪和脱敏结果"]
    I --> J["交给模型总结"]

工具 Schema 不要设计成 query(text) 这种大口子。应该明确工具名、用途、参数类型、枚举、必填项、权限要求和返回字段。

写操作必须更严格：

操作	风险	控制
查询订单	越权、泄露	后端按当前用户过滤
创建工单	重复创建	幂等号、参数校验
发送短信	骚扰、成本	频控、模板、审批
删除数据	不可逆	通常不直接开放给模型
退款、改权限	高风险	二次确认或人工审批

Agent 是 Tool Calling 的进阶：模型可以规划、调用工具、观察结果、继续下一步。Agent 更强，也更危险。商业系统中要限制最大步数、工具范围、超时、预算和人工确认点。

阶段九：评估、灰度和 LLMOps

AI 应用必须有评估集。没有评估集，Prompt 改动、模型切换、知识库更新都只能靠感觉。

评估样例建议包含：

字段	说明
question	用户问题
scene	客服、知识库、抽取、工具调用等
riskLevel	普通、高风险、敏感
mustContain	答案必须包含点
mustNotContain	禁止出现点
expectedCitation	期望引用
rejectCondition	什么时候必须拒答
scoreRule	人工或自动评分规则

上线流程：

mermaid

flowchart TD
    A["修改 Prompt/模型/知识库"] --> B["跑固定评估集"]
    B --> C{"质量、安全、格式是否达标"}
    C -- "否" --> D["回滚修改"]
    C -- "是" --> E["内部灰度"]
    E --> F["小流量灰度"]
    F --> G["观察效果、成本、错误率"]
    G --> H{"是否异常"}
    H -- "是" --> I["回滚版本"]
    H -- "否" --> J["扩大流量"]

LLMOps 管的是：Prompt 版本、模型版本、知识库版本、评估集、发布灰度、成本、日志、安全、反馈和回滚。它是 AI 应用能不能长期维护的关键。

阶段十：安全和数据治理

Prompt 注入、RAG 文档注入、工具越权、数据泄露是 AI 项目的常见风险。

安全设计原则：

原则	解释
后端鉴权	模型不能决定用户有没有权限
数据最小化	只给模型完成任务必需的数据
文档只当资料	RAG 文档不能覆盖系统规则
工具分级	查询、写入、高风险工具分级控制
输出检查	敏感信息、危险建议、格式错误要拦截
审计日志	记录谁、何时、调用了什么工具、结果如何

错误示例：把完整用户资料、手机号、身份证、内部成本、支付 Token 全部放进 Prompt。这样会增加泄露风险、token 成本和噪声。正确做法是后端先裁剪字段、脱敏，再给模型最小必要上下文。

阶段十一：推理优化和部署

AI 请求慢，要先拆链路，不要一上来换模型。

指标	含义
TTFT	首 token 时间，影响用户是否感觉“卡住”
TPOT	每个输出 token 耗时
P95/P99	高分位延迟，比平均值更能反映体验
input/output tokens	成本和延迟核心因素
queue time	是否排队
cache hit	缓存是否有效

排查流程：

mermaid

flowchart TD
    A["AI 请求慢"] --> B{"慢在哪里"}
    B -- "入口慢" --> C["查限流、鉴权、网关"]
    B -- "RAG 慢" --> D["查向量库、TopK、Rerank"]
    B -- "Prompt 长" --> E["压缩历史和 Chunk"]
    B -- "模型慢" --> F["查 TTFT、并发、上下文、显存"]
    B -- "工具慢" --> G["查下游接口和超时"]
    C --> H["优化并重新评估"]
    D --> H
    E --> H
    F --> H
    G --> H

本地部署和云模型 API 选择：

方案	优点	缺点
云模型 API	上手快、能力强、弹性好	数据出内网、按 token 计费、受供应商限制
本地部署	数据可控、内网可用、固定高频成本可控	硬件、运维、并发、升级都要自己负责
混合架构	兼顾能力和隐私	路由、评估、安全策略更复杂

商业常用场景

场景	推荐方案	关键控制点
企业知识库问答	RAG + 引用 + 权限过滤	文档治理、召回、引用校验
医疗数据资产助手	RAG + 工具查询 + 审计	数据脱敏、部门权限、人工兜底
客服助手	Prompt + RAG + 工单工具	拒答、转人工、话术合规
合同/报告抽取	结构化输出 + 校验	JSON Schema、字段置信度、人工复核
数据分析助手	Tool Calling 查询指标	SQL 权限、只读、限流、结果脱敏
运维排查助手	RAG + 日志摘要 + Runbook	禁止自动执行高危命令
批量内容生成	模板 Prompt + 评估	质量抽检、敏感词、成本控制

可运行 Demo：带权限过滤的 RAG 伪实现

这个 demo 不依赖真实模型，重点展示商业 RAG 的后端结构：先鉴权，再按权限过滤资料，再组装 Prompt。

python

from dataclasses import dataclass


@dataclass
class Chunk:
    chunk_id: str
    content: str
    departments: set[str]


chunks = [
    Chunk("c1", "资产状态包括启用、停用、报废。", {"asset"}),
    Chunk("c2", "财务成本字段只允许财务部门查看。", {"finance"}),
]


def retrieve(question: str, user_department: str) -> list[Chunk]:
    allowed = []
    for chunk in chunks:
        if user_department in chunk.departments:
            allowed.append(chunk)
    return allowed[:3]


def build_prompt(question: str, retrieved: list[Chunk]) -> str:
    context = "\n".join(f"[{c.chunk_id}] {c.content}" for c in retrieved)
    return f"""你只能根据资料回答。
资料:
{context}

问题:
{question}

如果资料不足，请回答：资料不足，无法确认。"""


def answer(question: str, user_department: str) -> str:
    docs = retrieve(question, user_department)
    prompt = build_prompt(question, docs)
    # 真实项目这里调用模型。demo 直接返回 prompt，方便观察权限过滤结果。
    return prompt


print(answer("资产状态有哪些？", "asset"))
print(answer("财务成本字段是什么？", "asset"))

这个 demo 的关键点：

权限过滤发生在检索阶段，不是生成后。
Prompt 明确“只能根据资料回答”。
资料不足要拒答。
真实项目要把 chunkId、score、用户、Prompt 版本、模型版本写入日志。

面试标准回答

AI 应用生产化要补什么

不能只调用模型接口。生产级 AI 应用要有场景边界、权限控制、Prompt 版本、RAG 或工具调用、结构化输出校验、评估集、安全防护、日志审计、成本监控、失败兜底和灰度回滚。高风险场景还要人工审核。

RAG 为什么能减少幻觉

RAG 先从外部知识库检索相关资料，再把资料和问题一起交给模型，让模型基于指定上下文回答。它能补充企业私有知识和最新资料，并通过引用来源让答案可追溯。但 RAG 不能彻底消除幻觉，仍要做切分、召回、Rerank、权限过滤、引用校验和评估。

Tool Calling 为什么必须后端校验

模型只能生成工具调用意图和参数，它不是权限系统，也不能保证参数正确。真实执行前，后端必须基于当前登录用户做鉴权、租户过滤、参数校验、风险判断、幂等控制和审计。写操作要二次确认或人工审批。

AI 请求慢怎么排查

先拆入口、RAG、Rerank、Prompt 组装、工具调用和模型生成耗时。看 TTFT、总耗时、P95/P99、输入输出 token、队列长度、缓存命中率。如果是 RAG 慢，查向量库和 Rerank；如果 Prompt 太长，压缩历史和 Chunk；如果模型慢，查并发、上下文长度、显存或供应商延迟。

学懂验收问题

大模型为什么会幻觉？
Token 为什么影响成本、延迟和截断？
Attention 的 Q、K、V 分别表示什么？
Prompt 为什么不是安全边界？
JSON 结构化输出为什么还要校验？
Embedding 为什么要求文档和问题使用同一模型？
向量相似度高为什么不一定能回答？
RAG 离线建库为什么必须保存元数据？
删除文档后为什么可能仍被 RAG 回答？
RAG 在线问答为什么要先做权限过滤？
TopK 太大和太小分别有什么问题？
Rerank 解决什么问题？
Tool Calling 为什么不能直接执行模型参数？
Agent 为什么比普通问答风险更高？
评估集为什么要包含拒答、安全和权限样例？
Prompt 改一句话为什么也要灰度？
本地部署和云模型 API 怎么选？
AI 日志为什么不能记录完整 Prompt？
AI 缓存为什么要带权限和版本？
AI 商业项目失败通常失败在哪些环节？

关联知识点跳转

本页小结

AI 从零到精通的核心不是会背概念，而是能把“模型为什么这样工作”和“商业系统为什么必须这样治理”连起来。真正学懂后，你应该能从一次用户提问开始，讲清鉴权、RAG、Prompt、模型调用、工具执行、输出校验、日志评估、安全审计、成本优化和故障排查的全过程。

AI 从零到精通验收清单 ​

总学习路线 ​

阶段一：AI、大模型和传统程序的区别 ​

阶段二：Token、上下文窗口和推理参数 ​

阶段三：Transformer 和 Attention ​

阶段四：Prompt 和结构化输出 ​

阶段五：Embedding 和向量数据库 ​

阶段六：RAG 离线建库 ​

阶段七：RAG 在线问答 ​

阶段八：Tool Calling 和 Agent ​

阶段九：评估、灰度和 LLMOps ​

阶段十：安全和数据治理 ​

阶段十一：推理优化和部署 ​

商业常用场景 ​

可运行 Demo：带权限过滤的 RAG 伪实现 ​

面试标准回答 ​

AI 应用生产化要补什么 ​

RAG 为什么能减少幻觉 ​

Tool Calling 为什么必须后端校验 ​

AI 请求慢怎么排查 ​

学懂验收问题 ​

关联知识点跳转 ​

本页小结 ​

AI 从零到精通验收清单

总学习路线

阶段一：AI、大模型和传统程序的区别

阶段二：Token、上下文窗口和推理参数

阶段三：Transformer 和 Attention

阶段四：Prompt 和结构化输出

阶段五：Embedding 和向量数据库

阶段六：RAG 离线建库

阶段七：RAG 在线问答

阶段八：Tool Calling 和 Agent

阶段九：评估、灰度和 LLMOps

阶段十：安全和数据治理

阶段十一：推理优化和部署

商业常用场景

可运行 Demo：带权限过滤的 RAG 伪实现

面试标准回答

AI 应用生产化要补什么

RAG 为什么能减少幻觉

Tool Calling 为什么必须后端校验

AI 请求慢怎么排查

学懂验收问题

关联知识点跳转

本页小结