【无标题】

kaico20182026-06-12 10:05

1.3 大语言模型（LLM） --- 详细学习文档

目录

一、什么是大语言模型

1.1 定义

大语言模型（Large Language Model, LLM）是基于Transformer架构、在海量文本数据上预训练的超大规模语言模型，具备理解和生成自然语言的能力。

LLM的核心能力公式：

LLM = Transformer架构 + 海量预训练数据 + 指令微调 + 人类对齐

  • 输入：一段文本（Prompt）
  • 输出：预测的下一个Token → 逐Token生成完整回答
  • 本质：一个超大规模的"下一个Token预测器"，但通过规模效应，涌现出推理、规划、代码等高级能力

1.2 LLM的关键属性

属性 说明 开发者关注点
参数量 模型的"大脑容量"，决定能力上限 影响推理成本和部署方式
上下文窗口 单次能处理的最大Token数 影响RAG文档量和对话长度
训练数据截止 模型知识的时效边界 决定是否需要RAG补充新知识
输出速度 每秒生成的Token数（TPS） 影响用户体验
并发能力 同时处理的请求数 影响系统吞吐量

1.3 LLM的"涌现能力"

复制代码 
涌现能力（Emergent Abilities）：
当模型规模超过某个阈值后，突然出现小模型不具备的能力。

已观察到的涌现能力：
├── 上下文学习（In-Context Learning）: 通过Prompt中的示例学习新任务
├── 思维链推理（Chain-of-Thought）: 逐步推理解决复杂问题
├── 指令遵循（Instruction Following）: 准确理解和执行指令
└── 代码生成（Code Generation）: 理解需求并生成可运行代码

涌现的规模阈值：
- 上下文学习：~10B参数开始显现
- 思维链推理：~60B参数开始显现
- 复杂推理：~100B参数开始显现

对开发者的意义：
1. 模型选型时，参数量不是越大越好，要看任务需求
2. 7B-13B模型适合简单任务（分类、提取、摘要）
3. 70B+模型适合复杂任务（推理、代码、多步规划）
4. 模型能力随规模提升不是线性的，存在"质变"点

二、主流模型全景

2.1 模型分类

LLM分类维度：

维度 分类 代表模型
按开放程度 闭源模型（API调用） GPT-4o, Claude, Gemini
开源模型（可本地部署） LLaMA, Qwen, DeepSeek, Mistral
半开放（权重开放但限制商用） 部分模型
按架构 Dense模型（全参数激活） GPT-4o, Qwen2.5, LLaMA-3
MoE模型（部分参数激活） DeepSeek-V3, Mixtral, Qwen-MoE
按规模 小模型（<10B） Qwen2.5-7B, LLaMA-3-8B, Mistral-7B
中模型（10B-70B） Qwen2.5-32B/72B, LLaMA-3-70B
大模型（70B-500B） GPT-4o, Claude 3.5, DeepSeek-V3
超大模型（500B+） GPT-4, Gemini Ultra（估计）

2.2 主流模型详细对比

闭源模型（API服务）
模型 出品方 上下文窗口 核心优势 适用场景 价格（每百万Token）
GPT-4o OpenAI 128K 综合能力最强，生态最完善 通用、复杂推理 输入2.5/输出10
GPT-4o-mini OpenAI 128K 性价比极高 日常任务、分类提取 输入0.15/输出0.6
o1/o3 OpenAI 200K 深度推理，思维链 数学、代码、复杂推理 较高
Claude 3.5 Sonnet Anthropic 200K 长文本理解好，代码强 代码、长文档分析 输入3/输出15
Claude 3.5 Haiku Anthropic 200K 速度快，成本低 快速响应场景 输入0.8/输出4
Gemini 2.5 Pro Google 1M+ 超长上下文，多模态 长文档、视频理解 输入1.25/输出10
Gemini 2.5 Flash Google 1M+ 速度快，长上下文 高并发、长文本 输入0.15/输出0.6
开源模型（可本地部署）
模型 出品方 参数量 上下文窗口 核心优势 许可证
Qwen2.5-72B 阿里 72B 128K 中文最强，数学代码好 Apache 2.0
Qwen2.5-7B 阿里 7B 128K 小模型中文最强 Apache 2.0
DeepSeek-V3 DeepSeek 671B(MoE) 128K 推理能力强，开源最强 MIT
DeepSeek-R1 DeepSeek 671B(MoE) 128K 推理专精，思维链 MIT
LLaMA-3-70B Meta 70B 128K 英文生态最好 LLaMA许可
LLaMA-3-8B Meta 8B 128K 小模型英文最强 LLaMA许可
Mistral-Large Mistral 123B 128K 欧洲代表，效率高 Apache 2.0
GLM-4 智谱 130B 128K 中文好，工具调用强 Apache 2.0
Yi-Lightning 零一万物 - 16K 极快推理速度 Apache 2.0

2.3 多模态能力

现代LLM已不限于文本，多模态是重要趋势：

模型 文本 图片输入 图片生成 音频 视频 代码
GPT-4o ✅ ✅ ✅ ✅ ✅ ✅
Claude 3.5 ✅ ✅ ❌ ❌ ❌ ✅
Gemini 2.5 Pro ✅ ✅ ✅ ✅ ✅ ✅
Qwen-VL ✅ ✅ ✅ ❌ ✅ ✅
DeepSeek-V3 ✅ ❌ ❌ ❌ ❌ ✅

对开发者的意义：

  1. 图片理解：OCR、图表分析、UI截图→代码
  2. 图片生成：DALL-E/Stable Diffusion集成
  3. 音频：语音对话（GPT-4o Realtime API）
  4. 视频：长视频理解（Gemini 1.5 Pro）
  5. 代码：代码生成/解释/调试

Java调用示例（Spring AI + GPT-4o Vision）：

java 复制代码 
var userMessage = new UserMessage(
    "描述这张图片的内容",
    List.of(new Media(MimeTypeUtils.IMAGE_PNG, new URL("https://example.com/image.png")))
);
String response = chatClient.prompt().messages(userMessage).call().content();

2.4 模型部署方式

企业级LLM部署的三种方式：

方式 优点 缺点 代表
云API调用（最简单） 零运维，按量付费，模型最新 数据外传，网络延迟，成本不可控 OpenAI API / 通义千问API / 百炼平台
私有化部署（最安全） 数据不出域，无Token费，可定制 需GPU硬件，运维成本高，模型更新慢 Ollama + Qwen2.5 / vLLM + LLaMA-3
混合部署（推荐） 兼顾成本和能力 架构复杂 Spring AI Alibaba + Higress AI网关路由

混合部署架构：

  • 简单任务 → 小模型本地处理（低成本、低延迟）
  • 复杂任务 → 大模型API处理（高能力、高成本）

部署方式选型：

  • 数据合规要求高（金融/医疗/政务）→ 私有化部署
  • 成本敏感 + 并发高 → 私有化部署（长期更省）
  • 快速验证 / MVP → 云API调用
  • 生产环境 → 混合部署

2.5 推理加速与量化

LLM推理性能优化的核心技术：

1. 量化（Quantization） --- 降低精度，减少显存和计算量

精度 说明 效果
FP16（16位浮点） 模型原始精度 基准
INT8（8位整型） 精度损失极小 速度2x
INT4（4位整型） 精度损失可接受 速度3-4x
GPTQ 训练后量化，4bit最优 效果好
AWQ 激活感知量化 效果更好
GGUF CPU/GPU混合推理格式 灵活

量化对模型大小的影响（LLaMA-3-70B示例）：

精度 显存需求 硬件需求
FP16 ~140GB 需4×A100(80GB)
INT8 ~70GB 需2×A100(80GB)
INT4 ~35GB 需1×A100(80GB)

2. 推理引擎

引擎 特点 适用场景
Ollama 本地开发首选，简单易用 开发/测试
vLLM 生产部署首选，高吞吐 生产环境
TensorRT-LLM NVIDIA官方，极致性能 NVIDIA GPU
LMDeploy 智谱出品，支持量化部署 国产模型
SGLang 新兴框架，结构化生成快 结构化输出

3. 关键性能指标

指标 说明 影响
TTFT（首Token延迟） 用户感知的响应速度 用户体验
TPS（每秒Token数） 生成速度 响应速度
并发数 同时处理的请求数 系统吞吐量
显存占用 决定硬件成本 硬件选型

典型性能参考（A100 80GB）：

模型 TPS（单请求） 并发 显存
Qwen2.5-72B (GPTQ-INT4) ~30 tokens/s ~10-20 ~40GB
Qwen2.5-7B (FP16) ~100+ tokens/s ~50+ ~15GB

对Java开发者的意义：Spring AI + Ollama用于本地开发调试，Spring AI Alibaba + vLLM用于生产部署，量化模型是降低硬件成本的关键手段。

2.6 模型选型决策

选型决策树：

问题 选项 推荐
1. 数据合规要求？ 必须本地部署 开源模型（Qwen/DeepSeek/LLaMA）
可以用云API 继续判断
2. 主要语言？ 中文为主 Qwen2.5 / DeepSeek / GLM-4
英文为主 GPT-4o / Claude / LLaMA
3. 任务复杂度？ 简单（分类/提取/摘要） 小模型（7B-13B / GPT-4o-mini）
中等（对话/翻译/代码） 中模型（32B-72B / Claude Sonnet）
复杂（推理/规划/数学） 大模型（70B+ / GPT-4o / o1）
4. 成本敏感度？ 高 开源模型自部署 / GPT-4o-mini
低 GPT-4o / Claude 3.5 Sonnet
5. 上下文长度需求？ <32K 大多数模型都满足
32K-128K GPT-4o / Qwen2.5 / DeepSeek
>128K Gemini 2.5 Pro（1M+）/ Claude 3.5（200K）

三、模型能力与边界

3.1 LLM擅长的任务

能力 说明 典型应用
文本理解 阅读理解、信息提取、情感分析 文档分析、知识提取
文本生成 写作、翻译、摘要、改写 内容创作、报告生成
代码生成 多语言代码编写、调试、解释 编程助手、代码审查
推理分析 逻辑推理、因果分析、对比 决策支持、数据分析
格式转换 非结构化→结构化、格式变换 数据清洗、表单提取
角色扮演 扮演专家角色、模拟对话 客服、培训、咨询
工具调用 根据需求选择和调用外部工具 Agent、自动化流程

3.2 LLM的局限性

LLM的六大核心局限：

局限 问题 原因 应对策略
1. 幻觉（Hallucination） 自信地生成看似合理但实际错误的内容 模型基于统计概率生成，不保证事实正确 RAG注入事实文档、降低Temperature、要求引用来源、事实核查、约束输出
2. 知识时效性 训练数据有截止日期，不知道最新信息 预训练完成后知识就"冻结"了 RAG接入实时数据源、Function Calling调用搜索API、选择知识截止日期较新的模型
3. 数学计算 复杂计算容易出错 LLM是语言模型，不是计算器 Function Calling调用计算器/代码执行器、思维链（CoT）引导逐步计算、代码解释器
4. 长文本一致性 长文本中前后矛盾 注意力机制对长距离依赖的衰减 分段处理+汇总、结构化输出（表格/JSON）、多轮校验
5. 精确指令遵循 对复杂指令的遵循不够精确 指令理解有偏差，或被训练偏好覆盖 Structured Output / JSON Mode、简化指令、Few-shot示例明确格式
6. 安全与偏见 可能生成有害、偏见内容 训练数据中包含偏见信息 System Prompt约束、输出过滤和审核、使用经过对齐的Chat/Instruct版本

3.3 幻觉问题深度解析

幻觉的三种类型：

类型 说明 示例 特征
事实性幻觉 事实错误，但语气自信 输入"李白是哪个朝代的诗人？"，输出"李白是宋朝诗人"（实际是唐朝） 事实错误
忠实性幻觉 与提供的上下文不一致 基于给定文档回答问题，编造文档中没有的信息 与上下文不一致
推理幻觉 推理步骤看似合理但逻辑错误 复杂推理问题，中间步骤出错导致结论错误 中间步骤出错

幻觉的根因：训练数据噪声、知识冲突、长尾知识不足、生成策略随机性（Temperature > 0）、上下文干扰。

Java AI框架中的幻觉应对：

  • Spring AI Alibaba：RAG模块注入事实性文档、评估模块自动评估输出质量、Graph模式多Agent交叉验证
  • LangChain4j：RAG Pipeline检索增强、AiServices + @Tool调用外部工具验证

四、Token计费模型

4.1 计费原理

LLM API计费公式：总费用 = 输入Token数 × 输入单价 + 输出Token数 × 输出单价

关键规则：

  1. 输入和输出价格不同（输出通常是输入的3-5倍）
  2. System Prompt计入输入Token
  3. 历史对话计入输入Token
  4. Function定义计入输入Token
  5. RAG检索的文档计入输入Token

Token消耗公式：

  • 总输入Token = System Prompt + 历史对话 + 用户消息 + 工具定义 + RAG文档
  • 总输出Token = 模型生成的回答 + 工具调用参数

4.2 主流模型价格对比

模型 输入价格（/百万Token） 输出价格（/百万Token） 输入/输出比
GPT-4o $2.50 $10.00 1:4
GPT-4o-mini $0.15 $0.60 1:4
Claude 3.5 Sonnet $3.00 $15.00 1:5
Claude 3.5 Haiku $0.80 $4.00 1:5
Gemini 2.5 Pro $1.25 $10.00 1:8
Gemini 2.5 Flash $0.15 $0.60 1:4
通义千问-Max ¥4.00 ¥12.00 1:3
通义千问-Plus ¥0.80 ¥2.00 1:2.5
通义千问-Turbo ¥0.30 ¥0.60 1:2
DeepSeek-V3 ¥1.00 ¥2.00 1:2
DeepSeek-R1 ¥4.00 ¥16.00 1:4

4.3 成本估算实战

场景：企业知识库问答系统

假设：

  • System Prompt: 500 Token
  • 平均用户问题: 100 Token
  • RAG检索文档: 2000 Token（5篇×400 Token）
  • 历史对话（5轮）: 3000 Token
  • 平均回答: 500 Token

单次请求Token消耗：

  • 输入 = 500 + 100 + 2000 + 3000 = 5600 Token
  • 输出 = 500 Token

使用GPT-4o的单次成本：

  • 输入: 5600 / 1,000,000 × 2.50 = 0.014
  • 输出: 500 / 1,000,000 × 10.00 = 0.005
  • 单次总成本: $0.019 ≈ ¥0.14

月度成本估算（1万次/天）：

模型 日成本 月成本
GPT-4o ¥1,400 ¥42,000
通义千问-Plus ¥54.8 ¥1,644

成本差异：GPT-4o vs 通义千问-Plus ≈ 25倍

4.4 成本优化策略

策略 说明 节省幅度
模型分级 简单任务用小模型，复杂任务用大模型 50-80%
Prompt精简 压缩System Prompt和RAG文档 20-40%
缓存 相同请求缓存结果 视重复率
批量处理 Batch API批量调用（半价） 50%
本地部署 开源模型自部署（无Token费） 100%（但有硬件成本）
对话截断 合理管理ChatMemory 30-50%
Streaming 流式输出减少超时重试 间接节省

五、采样策略与参数调优

5.1 Temperature（温度）

Temperature控制输出的随机性：

值 行为 效果
T = 0 总是选概率最高的Token 确定性输出（贪心解码）
T = 0.5 偏向高概率Token，偶尔选低概率 略有变化
T = 1.0 按原始概率分布采样 正常随机
T = 2.0 趋向均匀分布 高度随机，可能不连贯

数学原理：P(xᵢ) = exp(logitᵢ / T) / Σ exp(logitⱼ / T)

  • T → 0: 最大概率的Token概率趋近1
  • T → ∞: 所有Token概率趋近相同

不同场景的Temperature选择：

场景 推荐Temperature 原因
代码生成 0 - 0.2 需要精确、确定性输出
数据提取/JSON输出 0 必须严格遵循格式
翻译 0.1 - 0.3 需要准确但允许合理变通
问答/知识库 0.1 - 0.3 需要事实准确
摘要 0.3 - 0.5 允许一定表达自由度
对话/聊天 0.5 - 0.8 需要自然、多样的回复
创意写作 0.8 - 1.2 需要创新和多样性
头脑风暴 1.0 - 1.5 需要最大程度的创意

5.2 Top-P（核采样 / Nucleus Sampling）

Top-P的原理：从概率最高的Token开始累加，直到累计概率达到P，只在这个范围内采样。

值 行为 效果
P = 0.1 只从概率最高的前10%的Token中选 非常确定
P = 0.5 从概率最高的前50%的Token中选 较确定
P = 0.9 从概率最高的前90%的Token中选 较多样
P = 1.0 从所有Token中选 完全随机

示例（词汇预测） ：

Token概率分布：{"的": 0.4, "了": 0.2, "在": 0.15, "是": 0.1, "有": 0.05, ...}

  • Top-P = 0.7: 累计"的"(0.4) + "了"(0.2) + "在"(0.15) = 0.75 ≥ 0.7 → 只在 {"的", "了", "在"} 中采样
  • Top-P = 0.9: 累计"的"(0.4) + "了"(0.2) + "在"(0.15) + "是"(0.1) + "有"(0.05) = 0.9 → 在 {"的", "了", "在", "是", "有"} 中采样

Top-P vs Temperature：

维度 Temperature Top-P
作用 调整整体概率分布的"陡峭度" 截断低概率Token
效果 平滑地改变随机性 硬性地排除尾部Token
精细度 全局调整 动态调整（根据分布自适应）

最佳实践：通常只调一个，不要同时大幅调整两者。

  • 确定性任务：Temperature=0, Top-P=1（Top-P不生效）
  • 一般任务：Temperature=0.7, Top-P=1
  • 精确控制：Temperature=1, Top-P=0.9（用Top-P控制）

5.3 Top-K

Top-K的原理：只从概率最高的K个Token中采样。

值 行为 说明
K = 1 只选概率最高的1个Token 贪心解码
K = 10 从前10个Token中选 较确定
K = 50 从前50个Token中选 较多样

Top-K vs Top-P：

维度 Top-K Top-P
候选数量 固定，不管概率分布 动态，根据概率分布自适应
集中分布 可能浪费（如"的"占80%，但仍选5个） 高效（可能只需2-3个Token就达到90%）
均匀分布 合理 合理

结论：Top-P通常优于Top-K，因为能自适应概率分布。大多数API已默认使用Top-P而非Top-K。

5.4 其他生成参数

参数 说明 推荐值
max_tokens 最大生成Token数 按需设置，避免浪费
presence_penalty 存在惩罚（-2~2），正值降低重复话题 0（默认）
frequency_penalty 频率惩罚（-2~2），正值降低重复用词 0（默认）
seed 随机种子，相同seed+Temperature=0可复现 需要复现时设置
logprobs 返回Token的对数概率 调试/评估时开启
response_format 输出格式（text/json） 需要JSON时设置

5.5 参数调优速查表

场景 Temperature Top-P max_tokens 其他
代码生成 0 1 2048 -
JSON输出 0 1 1024 response_format=json
事实问答 0.1 0.9 512 -
文本摘要 0.3 0.9 300 -
翻译 0.2 0.9 1024 -
客服对话 0.6 0.9 512 -
创意写作 1.0 0.95 2048 -
头脑风暴 1.2 0.95 1024 -

六、系统提示（System Prompt）

6.1 System Prompt的作用

System Prompt = LLM的"人设"和"行为规范"

三层消息结构：

层级 说明 生效范围
System Message 定义角色和行为约束 全局生效
User Message 用户的输入/问题 当前请求
Assistant Message 模型的回答 模型输出

System Prompt的核心作用：

  1. 角色定义：你是谁？你的专业领域是什么？
  2. 行为约束：你应该怎么做？不应该怎么做？
  3. 输出格式：回答的格式要求（JSON/Markdown/表格）
  4. 知识边界：什么情况下应该承认不知道
  5. 安全约束：拒绝哪些类型的请求

6.2 System Prompt设计模式

模式1：角色扮演型

你是一位资深的Java架构师，拥有15年企业级应用开发经验。你擅长Spring Boot、微服务架构和AI应用集成。请用专业但易懂的语言回答问题，必要时给出代码示例。

模式2：任务指令型

你是一个文档摘要助手。你的任务是将用户提供的长文档总结为简洁的摘要。规则：1. 摘要不超过200字；2. 保留关键数据和结论；3. 使用要点列表格式；4. 如果文档内容不足，直接返回原文要点。

模式3：格式约束型

你是一个数据提取助手。从用户提供的文本中提取结构化信息。输出格式（严格JSON）：{"name": "姓名", "age": 年龄, "skills": "技能1", "技能2", "summary": "一句话总结"}。规则：1. 只输出JSON，不要任何解释；2. 缺失字段填null；3. 数值类型不要加引号。

模式4：安全防护型

你是一个企业知识库助手。安全规则：1. 只回答基于提供文档的问题；2. 如果文档中没有相关信息，回答"根据现有资料无法回答"；3. 不要编造数据或引用；4. 不讨论与文档无关的话题；5. 对敏感信息（密码、密钥）不输出原文。

模式5：复合型（推荐）

你是一位企业级AI应用开发专家助手。角色：你是精通Spring AI、LangChain4j和RAG架构的Java开发专家。能力范围：Java AI框架选型和使用、RAG系统设计和优化、Prompt工程和模型调优、Agent和工作流编排。行为规则：1. 回答要结合实际开发经验，给出可落地的建议；2. 代码示例使用Java，优先使用Spring AI或LangChain4j；3. 如果问题超出你的能力范围，明确说明；4. 不确定的信息要标注"需要验证"。输出格式：代码用java代码块，配置用yaml代码块，架构说明用ASCII图。

6.3 System Prompt最佳实践

原则 说明 反面示例 正面示例
具体明确 避免模糊指令 "好好回答" "回答不超过200字，用要点列表"
正面表述 说"要做什么"而非"不要做什么" "不要啰嗦" "回答简洁，直接给出结论"
分层组织 用标题/分段组织复杂指令 一大段文字 用##分节，用编号列表
给出示例 Few-shot比纯描述更有效 "输出JSON格式" 给出完整的JSON示例
设定边界 明确什么不该做 无边界约束 "只基于提供文档回答"
保持精简 System Prompt也消耗Token 冗长描述 精准关键词

6.4 Spring AI中的System Prompt实现

java 复制代码 
// 方式1：ChatClient Builder
@Service
public class ChatService {
    private final ChatClient chatClient;

    public ChatService(ChatClient.Builder builder) {
        this.chatClient = builder
            .defaultSystem("""
                你是一位企业级Java开发专家。
                回答要简洁、专业，给出代码示例。
                """)
            .build();
    }
}

// 方式2：Prompt Template
@SpringAIChatModel
public interface ExpertAssistant {
    @SystemMessage("""
        你是{domain}领域的专家。
        请用{style}的风格回答问题。
        """)
    String chat(@UserMessage String question,
                @Value("domain") String domain,
                @Value("style") String style);
}

// 方式3：外部文件管理（推荐生产环境）
// src/main/resources/prompts/system.st
// 你是{company}的AI助手，专精于{domain}...

// Java加载
PromptTemplate template = new PromptTemplate(
    new ClassPathResource("prompts/system.st")
);
Prompt prompt = template.create(Map.of(
    "company", "某某科技",
    "domain", "企业AI应用"
));

七、停止序列与输出控制

7.1 停止序列（Stop Sequence）

复制代码 
停止序列：当模型生成指定的字符串时，立即停止生成

用途：
1. 控制输出边界：防止模型生成多余内容
2. 多轮对话分隔：在特定标记处停止
3. 格式控制：在格式结束处停止

示例：
Prompt: "列出三种编程语言：\n1."
Stop Sequence: ["\n4", "\n\n"]

模型输出：
1. Java
2. Python
3. JavaScript
（在"4."之前停止，避免继续列举）

API调用示例（OpenAI格式）：
{
  "model": "gpt-4o",
  "messages": [...],
  "stop": ["\n\n", "END"]
}

7.2 输出控制策略

策略 说明 适用场景
max_tokens 限制最大输出Token数 控制回答长度
stop序列 在指定字符串处停止 格式化输出
response_format 指定输出格式（JSON/Text） 结构化数据
Structured Output 强制输出符合JSON Schema API集成
Function Calling 引导模型调用函数而非直接回答 Agent/工具使用

7.3 Structured Output详解

复制代码 
Structured Output = 让模型输出严格符合预定义的JSON Schema

三种实现方式：

1. JSON Mode（基础）
   - 只保证输出合法JSON，不保证Schema
   - 设置 response_format: { type: "json_object" }

2. JSON Schema约束（推荐）
   - 输出严格符合指定的JSON Schema
   - Spring AI / LangChain4j 都支持

3. BeanOutputConverter（Java友好）
   - 定义Java POJO → 自动生成Schema → 自动解析输出
java 复制代码 
// Spring AI Structured Output示例
public record PersonInfo(
    String name,
    int age,
    List<String> skills,
    String summary
) {}

@Bean
ChatClient chatClient(ChatClient.Builder builder) {
    return builder.build();
}

// 自动将LLM输出解析为PersonInfo对象
PersonInfo info = chatClient.prompt()
    .user("提取这个人的信息：张三，28岁，精通Java和Python，5年开发经验")
    .call()
    .entity(PersonInfo.class);
// info.name() → "张三"
// info.age() → 28
// info.skills() → ["Java", "Python"]

八、模型API调用模式

8.1 同步调用 vs 流式调用

复制代码 
同步调用（Synchronous）：
客户端发送请求 → 等待模型完整生成 → 一次性返回全部结果

优点：简单，结果完整
缺点：等待时间长（长回答可能10-30秒），用户体验差
适用：后台任务、短回答、批量处理

流式调用（Streaming）：
客户端发送请求 → 模型逐Token生成 → 每生成一个Token立即返回

优点：首Token延迟低（1-2秒），用户看到"打字效果"
缺点：实现复杂，需要处理部分结果
适用：对话、长文本生成、实时交互
java 复制代码 
// Spring AI 同步调用
String response = chatClient.prompt()
    .user("解释什么是RAG")
    .call()
    .content();

// Spring AI 流式调用
Flux<String> stream = chatClient.prompt()
    .user("解释什么是RAG")
    .stream()
    .content();

// Spring WebFlux返回流式响应
@GetMapping(value = "/chat", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
public Flux<String> chat(@RequestParam String message) {
    return chatClient.prompt()
        .user(message)
        .stream()
        .content();
}

8.2 多轮对话管理

复制代码 
多轮对话的核心问题：模型本身是无状态的，每次请求需要发送完整对话历史

请求1：
messages: [
  {role: "system", content: "你是助手"},
  {role: "user", content: "什么是Java？"}
]

请求2（需要带上历史）：
messages: [
  {role: "system", content: "你是助手"},
  {role: "user", content: "什么是Java？"},
  {role: "assistant", content: "Java是一种..."},
  {role: "user", content: "它有什么优点？"}  ← 新问题
]

Token消耗随对话轮次线性增长！

对话管理策略：

1. 滑动窗口：保留最近N轮对话
2. Token窗口：保留最近M个Token的对话
3. 摘要压缩：对早期对话做摘要，保留摘要+最近几轮
4. 向量化检索：将历史对话存入向量库，按需检索相关片段
java 复制代码 
// Spring AI 对话记忆
@Service
public class ChatService {
    private final ChatClient chatClient;
    private final ChatMemory chatMemory;

    public ChatService(ChatClient.Builder builder, ChatMemory chatMemory) {
        this.chatMemory = chatMemory;
        this.chatClient = builder
            .defaultAdvisors(MessageChatMemoryAdvisor.builder(chatMemory).build())
            .build();
    }

    public String chat(String conversationId, String message) {
        return chatClient.prompt()
            .user(message)
            .advisors(a -> a.param("chat_memory_conversation_id", conversationId))
            .call()
            .content();
    }
}

8.3 Function Calling（函数调用）

复制代码 
Function Calling = 让LLM在需要时调用预定义的外部函数

工作流程：
1. 开发者注册可用函数（名称、描述、参数Schema）
2. 用户提问
3. LLM判断是否需要调用函数
4. 如果需要，返回函数调用请求（函数名+参数）
5. 开发者执行函数，将结果返回给LLM
6. LLM基于函数结果生成最终回答

示例：
用户: "北京今天天气怎么样？"
LLM: 需要调用get_weather函数 → {city: "北京"}
开发者: 调用天气API → {temp: 25°C, weather: "晴"}
LLM: "北京今天天气晴朗，气温25°C，适合外出。"
java 复制代码 
// Spring AI Function Calling
@Description("获取指定城市的天气信息")
public class WeatherFunction implements Function<WeatherRequest, WeatherResponse> {
    @Override
    public WeatherResponse apply(WeatherRequest request) {
        // 调用天气API
        return weatherService.getWeather(request.city());
    }
}

public record WeatherRequest(
    @Description("城市名称") String city
) {}

public record WeatherResponse(
    String city, double temperature, String weather
) {}

// 注册并使用
@Bean
public ChatClient chatClient(ChatClient.Builder builder) {
    return builder
        .defaultFunctions("weatherFunction")
        .build();
}

九、与AI应用开发的关联

9.1 LLM知识→开发实践映射

LLM知识 开发中的实践 Java框架实现
模型选型 根据任务选择合适的模型和规模 Spring AI多模型切换
Token计费 成本估算和优化 监控Token消耗
Temperature 不同场景的参数配置 ChatClient参数设置
System Prompt 角色设定和行为约束 @SystemMessage / defaultSystem
停止序列 控制输出边界 stop参数
Structured Output 输出格式约束 BeanOutputConverter / entity()
流式调用 实时响应 stream().content() → Flux
对话记忆 多轮对话管理 ChatMemory / Advisor
Function Calling 工具调用 @Description + Function
幻觉应对 RAG + 事实核查 VectorStore + RAG Pipeline

9.2 关键概念速查表

概念 一句话理解 开发中的体现
LLM 大规模预训练语言模型，预测下一个Token AI应用的核心引擎
涌现能力 规模超过阈值后突然出现的新能力 决定模型选型的参数量下限
幻觉 自信地生成错误内容 RAG/Function Calling/验证机制
多模态 文本+图片+音频+视频的统一理解 Vision API / 语音对话
量化 降低模型精度以减少显存和加速推理 INT4/INT8部署选择
Token计费 输入+输出Token分别计费 成本控制和Prompt优化
Temperature 控制输出随机性 不同场景不同参数
Top-P 截断低概率Token的采样 精确控制输出多样性
System Prompt 定义LLM角色和行为规范 @SystemMessage注解
Structured Output 强制输出符合Schema entity()自动解析
Function Calling LLM调用外部函数 @Description函数注册
流式输出 逐Token返回结果 Flux流式响应

9.3 推荐学习资源

资源 类型 说明
OpenAI API文档 文档 API参数说明最全
Anthropic Prompt Engineering 文档 Prompt设计最佳实践
Spring AI官方文档 文档 Java AI开发参考
LangChain4j Examples 代码 实战示例丰富
DeepSeek API文档 文档 国产模型API参考
阿里云百炼文档 文档 通义千问API参考
相关推荐
器灵科技2 小时前
DeepSeek V4 Pro宣称：超GPT-5.5+永久降价75%
大数据·人工智能·gpt·阿里云·ai·语言模型
我认不到你2 小时前
【开源、教程】RAG全流程实现（java+完整代码）：第一弹
java·开发语言·人工智能·深度学习·ai·语言模型·开源
羊羊小栈2 小时前
基于GraphRAG的地质矿产知识管理系统(Neo4j_大语言模型)
人工智能·语言模型·自然语言处理·毕业设计·neo4j·大作业
Kobebryant-Manba3 小时前
学习语言模型
人工智能·学习·语言模型
谷歌玩家16 小时前
如何让大模型稳定输出JSON格式数据
语言模型
清辞85319 小时前
Coze从入门到实战---第一、二章
大数据·人工智能·学习·语言模型
Samooyou19 小时前
大模型微调(Fine Tuning)
人工智能·python·ai·语言模型
东方佑1 天前
分形递归状态机 (FRSM) 实验报告-或将实现llm无限上下文
人工智能·语言模型·自然语言处理
MartinYeung51 天前
[论文学习]透过增强式 Few-Shot Learning 实现高效 PII 从大型语言模型中提取
人工智能·学习·语言模型
热门推荐
01《置身钉内》原文-可播放阅读02Claude Code、Codex、Cursor三分天下：2026年AI编程Agent生态全景剖析03【AI】2026 年具身智能模型和世界模型总结04AI科技热点日报 | 2026年6月1日052026 AI 编程工具终极实战指南：Cursor vs Claude Code vs Copilot，开发者该怎么选？06GitHub 镜像站点072026 年 AI 编程工具终极横评：Cursor vs Claude Code vs Copilot vs Windsurf082026年6月AI行业全景：从百模大战到Agent元年，这30天发生了什么？09Codex 下载安装指南：Windows 和 macOS 官方版下载10【踩坑记录 | 第一篇】微软商店无法使用时，如何手动安装 OpenAI Codex？附`.msix`文件系统错误解决方法