Java 工程师 AI 智能体学习路线 · 阶段 1：AI / LLM 基础认知 详解

Java 工程师 AI 智能体学习路线 · 阶段 1：AI / LLM 基础认知 详解

本阶段目标：建立对大模型（LLM）能力与边界的正确直觉，理解 Token、上下文、参数、成本等核心概念，为后续提示词工程与智能体开发打地基。

---

注：

博客：

https://blog.csdn.net/badao_liumang_qizhi

1.1 核心术语

1.1.1 Token（词元）

讲解

Token 是模型处理文本的最小单位。模型并不直接"读字"，而是先把文本切分成 Token，再转换成向量进行计算。不同语言的切分粒度不同：

• 英文：通常 1 Token ≈ 4 个字符（如 "hello" 是 1 个 Token，"unhappy" 可能被拆成 un + happy）。
• 中文：通常 1 Token ≈ 1～2 个汉字（标点、空格也单独计 Token）。
• 代码/公式：按子词（subword）切分，特殊符号往往占更多 Token。

示例

• 文本 "你好，世界" 在 GPT 类 tokenizer 中通常约 5～7 个 Token。
• 文本 "The quick brown fox" 约 4～5 个 Token。

常见场景

• 计费按 Token 数（输入 + 输出）计算，长文本问答成本更高。
• 上下文窗口以 Token 数为上限，超长会截断。
• 估算成本：可先用官方 tokenizer 工具（如 OpenAI Tokenizer、tiktoken）统计。

面试知识点

• Q：为什么中文比英文"更费 Token"？
  A：中文无空格分词，单个汉字语义密度高，tokenizer 常以字或词根切分，整体 Token 数通常多于同等语义的英文。
• Q：Token 数量如何影响模型表现与成本？
  A：Token 越多，计算量与显存占用越大、延迟越高、成本越高；同时过长上下文会稀释注意力，可能降低回答质量。

---

1.1.2 上下文窗口（Context Window）

讲解

上下文窗口是模型单次处理所能"看到"的最大 Token 数，包含输入提示 + 历史对话 + 模型输出三者的总和。超出部分会被截断（或采用滑动窗口/摘要压缩）。

示例

• 某模型上下文窗口为 128K Token，约等于 10 万汉字。
• 若一次输入占了 120K，则模型输出最多只剩 8K。

常见场景

• 长文档问答（如整本 PDF 投喂）需配合 RAG 或摘要，而非全量塞入。
• 多轮对话需管理历史长度，避免溢出。

面试知识点

• Q：上下文窗口越大越好吗？
  A：不一定。窗口大能容纳更多信息，但会带来注意力分散（"Lost in the middle" 现象）、延迟与成本上升；工程上常用 RAG/摘要控制有效上下文。

---

1.1.3 Embedding（向量嵌入）

讲解

Embedding 是将文本映射为稠密向量（一串浮点数）的技术，语义相近的文本向量距离更近。它是 RAG、相似检索、聚类的基础。

示例（伪代码）

// 使用 Embedding 模型将文本转向量（以 Spring AI 风格示意）
float[] vector = embeddingClient.embed("人工智能是计算机科学的分支");
// vector.length 通常为 1536 / 768 / 1024 等

常见场景

• 知识库检索：把文档切块 Embedding 后存向量库，用户提问时检索最相近的块。
• 去重、聚类、推荐。

面试知识点

• Q：Embedding 模型与生成模型的区别？
  A：Embedding 模型输出固定维度向量用于表征语义；生成模型输出文本用于对话/创作。两者常配合使用（RAG）。

---

1.1.4 微调（Fine-tuning） vs 推理（Inference）

讲解

• 预训练/微调：用特定领域数据继续训练模型，改变模型"权重"，使其掌握新知识或风格（成本高、周期长）。
• 推理（Inference）：用已训练好的模型处理请求、生成结果（日常调用 API 即推理）。

常见场景

• 一般业务直接用推理 + Prompt/RAG 即可，性价比最高。
• 仅在通用模型无法满足特定格式/领域术语时考虑微调（如医疗、法律垂直领域）。

面试知识点

• Q：什么情况下该用 RAG 而不是微调？
  A：知识频繁更新、需可溯源、数据私有且易变时优先 RAG；微调适合固化风格/任务模式，但知识更新慢、成本高。

---

1.1.5 幻觉（Hallucination）

讲解

模型在缺乏依据时"自信地编造"看似合理但错误的内容，是 LLM 最典型的风险。

示例

• 让模型列出"某不存在的产品参数"，它可能生成一套逼真但虚构的规格。

常见场景

• 事实问答、数据引用、代码 API 名称易产生幻觉。
• 缓解手段：RAG 注入真实资料、要求"不知就说不知"、输出引用溯源、后校验。

面试知识点

• Q：如何降低幻觉？
  A：①RAG 提供证据；②明确约束"无依据则拒答"；③要求给出引用来源；④多模型交叉验证；⑤关键结论人工复核。

---

1.1.6 知识截止日期（Knowledge Cutoff）

讲解

模型训练数据截止到某一时间点，之后发生的事件、新发布的库/API 它并不知道。

常见场景

• 问"2025 年发布的新框架用法"可能答错或编造。
• 解决：通过工具调用/联网搜索/RAG 注入实时信息。

面试知识点

• Q：用户问最新资讯，模型答非所问，你作为工程师怎么处理？
  A：接入搜索/数据库工具实时获取，或用 RAG 注入最新文档，而非依赖模型记忆。

---

1.2 模型分类

类型	说明	典型用途	示例
对话/生成模型	通用文本生成与对话	客服、写作、问答	GPT-4o、通义千问、Claude
推理模型	强化慢思考、擅长复杂推理	数学、代码、规划	o1 / o3、DeepSeek-R1
多模态模型	支持文本+图像/语音/视频	图文理解、视觉问答	GPT-4V、Gemini
Embedding 模型	输出文本向量	检索、聚类	text-embedding-3
重排模型（Rerank）	对候选结果再排序	RAG 精排	BGE-Reranker

面试知识点

• Q：推理模型（如 o1/R1）与普通对话模型的区别及取舍？
  A：推理模型在回答前做更多内部思考（Chain-of-Thought 内化），擅长数学/代码/复杂规划，但延迟高、成本高；简单闲聊用普通模型更划算。

---

1.3 采样参数

这些参数控制模型"如何生成下一个 Token"，决定输出的随机性与多样性。

temperature（温度）

• 范围：0～2，默认约 0.7～1.0。
• 作用：值越低输出越确定/保守；值越高越随机/有创意。
• 场景：代码/事实问答用 0～0.3；头脑风暴用 0.8～1.0。

top_p（核采样 Nucleus Sampling）

• 作用 ：只从累计概率达 top_p 的最小词集中采样（如 0.9 表示保留概率总和 90% 的候选）。
• 与 temperature 关系：两者都控制随机性，通常二选一调，不叠加乱调。

top_k

• 作用：仅从概率最高的 k 个词中采样。k 越小越保守。

max_tokens

• 作用：限制单次输出最大 Token 数，防止无限生成、控制成本。

stop（停止序列）

• 作用 ：遇到指定字符串即停止生成（如 \n\n、###）。

frequency / presence penalty

• frequency penalty：惩罚重复出现的 Token，降低复读。
• presence penalty：惩罚已经出现过的词，鼓励引入新话题。

示例（API 调用参数示意）

{
  "model": "gpt-4o",
  "messages": [{"role": "user", "content": "用一句话解释 Token"}],
  "temperature": 0.2,
  "top_p": 0.9,
  "max_tokens": 200,
  "stop": ["\n\n"]
}

面试知识点

• Q：temperature=0 是否一定输出完全相同？
  A：基本可复现，但部分推理模型含随机性/批处理差异，且不同后端实现可能略有不同；不能 100% 保证逐字节一致。
• Q：temperature 和 top_p 同时调会怎样？
  A：会叠加影响随机性，难以预测，通常只调其一。

---

1.4 能力边界

常见短板

• 知识时效：训练截止后的事不知道。
• 精确计算：大数运算、复杂算术易错（应交给代码/计算器工具）。
• 因果与常识：可能混淆时间线、人物关系。
• 不可复现：同 Prompt 多次结果不同。
• 幻觉：见 1.1.5。

工程启示

• 让模型"想"和"说"，把"算"和"查"交给工具（代码执行、数据库、搜索）。
• 关键结果必须校验与人工确认。

面试知识点

• Q：为什么不应让 LLM 直接做精确数学计算？
  A：自回归生成本质是概率预测，不保证算术正确；应借助工具调用（如 Python 解释器）执行计算。

---

1.5 推理成本

组成

• 输入 Token 费用 + 输出 Token 费用（通常输出更贵）。
• 缓存命中（如 prompt cache）可大幅降本。
• 高级/推理模型单价显著高于普通模型。

优化手段

• 压缩 System Prompt，复用前缀以命中缓存。
• 模型分级路由：简单任务用便宜模型。
• 控制 max_tokens，避免冗余输出。
• 批量（batch）调用享折扣。

面试知识点

• Q：如何降低一个高频问答系统的 Token 成本？
  A：①Prompt 缓存复用系统提示；②RAG 只取相关片段而非整库；③小模型路由；④限制输出长度；⑤批量调用。

---

1.6 生态认知

主流模型厂商与 API 形态

• OpenAI：Chat Completions API，生态最成熟。
• Anthropic：Claude，长上下文、强安全。
• Google：Gemini，多模态强。
• 国产：通义千问（DashScope）、智谱 GLM、DeepSeek、文心一言，对中文/本地合规友好。

注意点

• 各厂商参数名/默认值略有差异，但核心概念一致（temperature、max_tokens 等通用）。
• 国内调用需关注合规、数据出境与密钥安全。

面试知识点

• Q：不同厂商 API 不兼容，工程上如何解耦？
  A：使用抽象层（如 Spring AI 的 ChatClient、LangChain4j 的 ChatLanguageModel），以统一接口屏蔽厂商差异，便于切换与灰度。

---

1.7 阶段 1 自测清单

• 能解释 Token 与上下文窗口的关系
• 能说明 temperature / top_p 的作用与取舍
• 能列举 LLM 至少 3 个典型失败场景
• 能区分微调与推理的适用场景
• 能说出降低幻觉与成本的常用手段

---

1.8 阶段 1 面试题与参考答案

1. 什么是 Token？中英文 Token 消耗差异的原因是什么？

Token 是模型处理文本的最小单位，文本先被切分为 Token 再转向量计算。差异原因：英文按子词切分、有空格天然分词，约 1 Token ≈ 4 字符；中文无空格、语义密度高，常以字/词根切分，约 1 Token ≈ 1～2 汉字，因此同等语义下中文 Token 数通常更多。

2. 上下文窗口包含哪些部分？超长会怎样？

包含"输入提示 + 历史对话 + 模型输出"三者之和。超长时超出部分会被截断（或经滑动窗口/摘要压缩），导致信息丢失、回答质量下降。

3. 什么是 Embedding？它在 RAG 中起什么作用？

Embedding 把文本映射为稠密向量，语义相近则向量距离近。在 RAG 中：文档切块后 Embedding 存入向量库，用户提问时检索语义最相近的块，作为证据注入 Prompt，从而提升回答准确性与可溯源。

4. 微调与 RAG 怎么选？

知识频繁更新、需可溯源、数据私有且易变 → 优先 RAG；需要固化特定风格/任务模式、且数据稳定 → 可考虑微调。实际中多数业务先用 RAG，性价比更高。

5. 什么是幻觉？工程上如何缓解？

幻觉指模型在无依据时"自信编造"看似合理但错误的内容。缓解：①RAG 提供真实证据；②约束"无依据则拒答"；③要求给出引用来源；④多模型交叉验证；⑤关键结论人工复核。

6. temperature=0 是否完全可复现？为什么？

基本可复现，但不保证 100% 逐字节一致。原因：部分推理模型内部含随机性/搜索过程；批处理、服务端实现差异也会影响；此外硬件浮点精度也可能带来微小差异。

7. 为什么不让 LLM 直接做精确计算？

自回归生成本质是概率预测下一个 Token，不保证算术正确（尤其大数、多位小数）。正确做法：通过工具调用（如 Python 解释器、计算器 API）执行计算，再把结果回灌给模型。

8. 如何降低高频问答系统的 Token 成本？

①System Prompt 缓存复用前缀；②RAG 只取相关片段而非整库；③按任务难度做模型分级路由（简单用小模型）；④限制 max_tokens；⑤批量调用享折扣；⑥压缩冗余提示。

9. 推理模型与普通模型的区别及取舍？

推理模型（如 o1/R1）在回答前做更多内部"慢思考"（CoT 内化），擅长数学/代码/复杂规划，但延迟高、成本高；普通模型响应快、便宜，适合闲聊、摘要、简单问答。取舍原则：按任务复杂度与成本预算选择。

10. 多厂商 API 不兼容时如何在工程中解耦？

引入抽象层统一接口，例如 Spring AI 的 ChatClient、LangChain4j 的 ChatLanguageModel，业务代码只依赖抽象；具体厂商通过配置/适配器注入，便于切换、灰度与多模型路由。

---