Appearance
术语表：用 Java 工程师听得懂的话解释
1. 本节产出
扫一眼能看懂整个知识体系里的关键名词，并且每个术语都配了一个你熟悉的 Java 类比。之后看任何一篇教程或官方文档不会再被名词劝退。
2. 前置依赖
无。建议收藏，随时回来查。
3. 为什么术语是 Java 工程师的第一道坎
AI 领域的很多名词来自算法和语言学背景，翻译后又混杂了各家厂商的自定义叫法。同一个东西可能有四五个名字：
- 工具调用 = Function Calling = Tool Use = Tools = 函数调用
- 提示词 = Prompt = 提示工程（这是动作不是东西）
- RAG = 检索增强生成 = 知识库问答（后者是场景不是技术）
本表给出一个白话解释 + 一个 Java 类比，读完能建立直觉就够了。
4. 核心内容：六组术语
4.1 模型基础
| 术语 | 白话解释 | Java 类比 |
|---|---|---|
| Token | 模型处理文本的最小单位，不是字也不是词 | 类似于数据库的计费单位 IO：看不见，但账单按它算 |
| 上下文窗口（Context Window） | 一次请求里模型能看到的全部内容的容量上限 | 方法栈深度：超出就报错，而且越大越贵 |
| Temperature | 控制输出随机性，0 偏向确定，越大越发散 | 类似于随机数种子强度；做分类/抽取要设低 |
| Top-P | 另一种控制随机性的方式，按概率累积截断 | 和 temperature 选一个调即可，同时调容易混乱 |
| 多模态 | 能同时处理文字、图片、音频等输入 | 接口支持 MultipartFile，不止接收 JSON |
| Embedding（向量化） | 把一段文本转成一串浮点数 | 类似于哈希：内容相近的串，数值距离也近 |
| 微调（Fine-tuning） | 用自有数据调整模型参数 | 类似于定制 ROM：成本高、周期长，多数场景不需要 |
4.2 调用层
| 术语 | 白话解释 | Java 类比 |
|---|---|---|
| Prompt | 发给模型的全部输入内容 | 请求的 Payload，不是「一句话咒语」 |
| System Prompt | 设定模型角色与约束的固定前缀 | 类似于全局 @ControllerAdvice：对所有请求生效 |
| Completion / Chat | 单次补全 vs 多轮对话两种接口形态 | 一次性调用 vs 带状态的会话 |
| 结构化输出 | 强制模型返回符合 Schema 的 JSON | Controller 直接返回 DTO，而不是 String |
| 流式输出（Streaming） | 边生成边返回，不用等全部完成 | Flux<String> 而不是 Mono<String> |
| SSE | Server-Sent Events，服务端推送的轻量协议 | 比 WebSocket 简单，单向够用就不要上双向 |
4.3 Spring AI 专名
| 术语 | 白话解释 | Java 类比 |
|---|---|---|
| ChatModel | 最底层的模型调用接口 | 类似于 JdbcTemplate：直接干活的那层 |
| ChatClient | 链式的高层 API，推荐入口 | 类似于 RestClient：builder 风格，带默认拦截器 |
| Advisor | 请求前后的拦截增强链 | 就是 Filter 链 / AOP 切面，概念完全一致 |
| ChatMemory | 多轮对话历史存储 | 类似于 HttpSession，但一定要能持久化 |
| VectorStore | 向量的存储与相似度检索抽象 | 类似于 JpaRepository：换实现不改代码 |
| ToolCallback | 一个可被模型调用的工具对象 | 类似于注册进容器的 RPC 服务接口 |
| MCP | Model Context Protocol，工具能力的标准协议 | 类似于 SPI / 插件规范：一次实现多处复用 |
4.4 RAG
| 术语 | 白话解释 | Java 类比 |
|---|---|---|
| RAG | 先检索相关资料，再把资料塞给模型让它据此回答 | 给模型装了个外部数据访问层 |
| Chunk（分片） | 长文档切成的小块 | 分页：太大装不下，太小语义断裂 |
| 召回（Retrieval） | 从库里找出候选相关片段 | 粗查：查全优先，准确性其次 |
| 向量检索 / ANN | 按语义相似度查找 | ORDER BY vector_distance LIMIT k |
| 关键词检索 / BM25 | 按字面词频查找，喊天天不应叫地地不灵时用得上 | 就是全文索引 MATCH AGAINST |
| 混合检索 | 两种检索都用，各取所长 | 多路查询 + 归并排序 |
| RRF | 一种融合多路排序结果的算法 | 归并排序时的打分规则：只看排名不看重分数 |
| Rerank（重排序） | 用更强的模型对候选结果精排 | 二阶段排序：粗排求快，精排求准 |
| Top-K | 取相似度最高的 K 个结果 | LIMIT K |
| 幻觉（Hallucination） | 模型一本正经编造事实 | 编数据：普通 bug 会抛异常，幻觉会给你一个自信的错误答案 |
| 引用溯源 | 回答里标注来自第几个文档片段 | 类似于 Source 的 traceId：可回溯才能被信任 |
4.5 Agent
| 术语 | 白话解释 | Java 类比 |
|---|---|---|
| Agent | 能自己决定「下一步做什么」的程序 | 带决策能力的工作流引擎 |
| ReAct | Reasoning + Acting，思考→行动→观察的循环 | while 循环 + 状态判断 |
| Thought / Action / Observation | ReAct 一轮里的三段 | 推理日志 / 发出的调用 / 拿到的返回值 |
| Tool / Function Calling | 模型输出「我要调用 X 工具，参数是 Y」 | 模型返回调用意图，由你的代码真正执行 |
| Planning | 先产出计划再执行 | 先生成有向无环图再调度 |
| Reflection | 让模型检查自己的结果并修正 | 自检 + 重试，类似乐观锁的冲突校验 |
| 多 Agent | 多个专职 Agent 协作 | 微服务拆分：按职责划分，靠消息/调用协作 |
| Supervisor | 一个总控 Agent 分派任务 | 编排服务 / Saga 协调器 |
| HITL | Human-in-the-loop，关键动作人工确认 | 审批流：高危操作必须有人点确认 |
| Harness | 包裹 Agent 的运行时管控层（超时/熔断/权限/审计） | 就是 Spring 容器本身对你的 Bean 做的事 |
4.6 工程治理
| 术语 | 白话解释 | Java 类比 |
|---|---|---|
| 评测集（Eval Set） | 一组「问题 + 期望答案」用于回归验证 | 自动化测试集：没有它就无法证明改动变好了 |
| 精确率 / 召回率 | 找回来的里有多少是对的 / 该找回来的是否都找到了 | 查准率与查全率，语义一致 |
| LLM-as-Judge | 用一个模型给另一个模型的输出打分 | 自动化断言无法覆盖时用 AI 做近似判分 |
| Token 用量/成本观测 | 记录每次调用的 token 并核算成本 | APM 里的调用次数与耗时统计 |
| 熔断 / 降级 | 下游不可用时切断或走备选 | Resilience4j 那一套，完全一样 |
| 数据脱敏 | 送出去之前把敏感信息处理掉 | 日志脱敏，同一件事 |
5. 操作步骤：怎么用这张表
- 看任意章节前，先在本页 Ctrl+F 搜一下出现的陌生名词。
- 遇到「厂商叫法」和本表不一致时，以本表的白话解释为准理解，再对应到具体 API。
- 术语会持续补充，发现看不懂的词记下来，这就是下一版的更新来源。
6. 验证清单
随机抽 5 个术语，不看本页能否用一句话向同事讲清楚？讲得清就够用了：
- [ ] Embedding 和普通的哈希有什么区别？
- [ ] Advisor 和你写的拦截器是什么关系？
- [ ] Harness 到底管什么？
- [ ] 为什么有了向量检索还要混合关键词检索？
- [ ] 幻觉和普通的程序 bug，哪个更危险？
7. 生产避坑
- 术语混用会毁掉团队沟通。在你们的项目文档里固定一套叫法（建议直接用本表），避免「RAG 检索」和「向量查询」在需求里指的是两件事。
- 别拿采样某个厂商的术语当通用概念。比如某家的「工作流」可能特指它的产品功能，不是通用名词。
- 幻觉比 bug 更可怕的原因是可信度高。所以引用溯源不是加分项，是企业场景的准入门槛。
8. 延伸与锚点
- 下一站：01-01 LLM 基础概念与选型（待编写）
- 概念深化：本页只给直觉，每篇的「核心原理」段会展开成图。