第二篇 大模型应用基础通识

第二篇 大模型应用基础通识

本篇定位：所有AI应用开发岗位的通用前置基础，是RAG、Agent开发的底层必修课，属于必拿分的基础题，面试占比约15%。侧重应用层理解，不深挖算法推导，重点掌握落地能用的核心知识。

2.1 大模型基础原理（应用层必备）

核心题1：必须掌握的5个核心基础概念

背诵要点

1. Token（令牌）

   • 大模型处理文本的最小单位，不是字也不是词，是分词后的子词片段
   • 1个中文汉字约等于1.3-1.5个Token，英文1个单词约1.3个Token
   • 所有计费、上下文长度、输出限制都以Token为单位

2. 上下文窗口（Context Window）

   • 模型单次能处理的最大Token长度，包含输入+输出
   • 窗口越大，能承载的历史对话、参考资料越多，但推理成本越高、速度越慢
   • 不是越长越好，长上下文会稀释关键信息，增加幻觉概率

3. 采样参数：温度（Temperature）、TopP、TopK

   • 控制输出随机性的三个核心参数，共同决定模型创造性
   • 温度：0-2之间，值越低输出越确定、越保守；值越高越随机、越有创意
   • TopP：核采样，只从累计概率达到P的候选词里选，值越小越保守
   • 落地经验：问答/工具调用场景设0.1-0.3，创意写作设0.7-1.0

4. Embedding（向量嵌入）

   • 把文本转换成固定维度的数值向量，让计算机可以计算语义相似度
   • 语义相近的文本，向量距离更近；语义不同的文本，向量距离更远
   • 是向量检索、语义匹配、聚类、分类等场景的基础

5. 幻觉（Hallucination）

   • 模型生成看似合理但实际虚假、错误的信息，是大模型的固有特性
   • 表现形式：编造事实、虚构数据、错误引用、无中生有
   • 无法彻底消除，只能通过RAG、Prompt约束、事实校验等手段降低概率

核心题2：从应用视角理解Transformer的核心思想

背诵要点

• Transformer是当前所有大模型的基础架构，核心机制是自注意力机制
• 自注意力的作用：让模型在处理每个词时，都能关注到上下文中其他相关的词，理解上下文关联和语义依赖
• 应用层三个关键结论：
  1. 并行计算能力强，训练和推理效率远超之前的循环神经网络
  2. 长距离语义理解能力强，能很好地捕捉长文本中的逻辑关联
  3. 上下文长度是核心指标，注意力计算量随长度平方增长，越长成本越高
• 应用开发无需深入推导反向传播，理解能力边界和成本特性即可

核心题3：大模型的能力边界与常见局限性

背诵要点
擅长的事：

• 语义理解、内容生成、逻辑推理、信息总结、格式转换、代码生成
• 基于已有信息做整合、重组、润色
• 遵循指令完成结构化、标准化任务

不擅长/做不到的事：

1. 无法获取实时、私有、最新的信息，内置知识有截止日期
2. 无法直接操作外部系统，必须通过工具调用间接实现
3. 事实准确性不可靠，存在幻觉，不能直接作为高风险场景的唯一依据
4. 复杂数学计算、精确数值运算能力弱，需要借助计算器工具
5. 无法感知真实世界，没有真正的主观意识和情感

落地启示：不要让模型做它不擅长的事，信息获取靠检索、精确计算靠工具、高风险场景加人工校验，用工程手段弥补模型短板。

高频追问

1. 温度和TopP有什么区别？一般怎么搭配使用？

   • 温度调整整体随机度，TopP控制候选词范围
   • 两者共同作用，一般不同时调极端值
   • 生产常用方案：固定TopP=0.9，只调整温度来控制输出风格

2. 上下文窗口越大越好吗？

   • 不是。窗口越大成本越高、速度越慢
   • 长上下文存在「Lost in the Middle」现象，中间信息召回率低
   • 够用即可，优先通过检索、摘要等方式提升信息密度，而不是盲目堆长窗口

3. Embedding模型和生成大模型是什么关系？

   • 两者是独立的两类模型：生成模型负责输出内容，Embedding模型负责把文本转向量
   • 一般搭配使用，但不强制绑定，可以用不同厂商的模型组合
   • 同一语义空间的模型搭配，检索效果更好

2.2 Prompt工程核心体系

核心题1：Prompt四大核心基础技巧

背诵要点

1. 角色设定

   • 开头明确给模型分配专业角色，限定身份和领域
   • 作用：锚定模型的知识边界和表达风格，提升输出专业度
   • 示例：你是一名资深Java后端开发工程师，只回答技术相关问题。

2. 结构化指令

   • 用清晰的结构说明任务要求、输出规则、约束条件
   • 核心三要素：任务目标、输出要求、禁止事项
   • 多用序号、分隔符、标题划分模块，比大段文字效果好

3. 少样本示例（Few-shot）

   • 给模型2-3个输入输出的完整例子，比纯文字描述更易对齐预期
   • 适用场景：格式要求严格、输出标准统一、规则复杂的任务
   • 注意：示例要覆盖典型场景和边界情况，质量比数量重要

4. 思维链引导（CoT）

   • 要求模型一步步思考，先推理再给结论
   • 作用：显著提升逻辑推理、数学计算、复杂分析的准确率
   • 常用话术：请一步步分析，先给出思考过程，再输出最终答案。

核心题2：系统提示（System Prompt）设计原则

背诵要点
系统提示是全局约束，决定Agent的行为边界，设计遵循5个原则：

1. 角色清晰：明确定位、能力范围、服务对象
2. 边界明确：说清楚能做什么、不能做什么，超出范围怎么处理
3. 规则前置：核心规则放在最前面，优先级最高的规则重点强调
4. 格式统一：规定输出结构、引用规范、拒答话术
5. 安全兜底：加入防注入、防越权、幻觉防控的基础约束

生产级系统提示标配结构：
角色定位 → 核心能力 → 输出规范 → 安全约束 → 拒答规则

核心题3：输出格式控制的常用方法

背诵要点
按稳定程度从低到高排序：

1. Prompt指令约束：文字描述输出格式，最简单但稳定性一般，适合非严格场景
2. 少样本示例：给出格式样例，效果优于纯文字描述
3. 结构化输出参数：调用模型API时指定JSON模式、函数调用格式，模型强制按Schema输出，稳定性高
4. 后置正则校验：输出后用规则校验、修正格式，作为兜底
5. Function Calling复用：把输出封装成工具返回的格式，利用工具调用的强约束性

落地经验：严格结构化场景，优先用模型原生的结构化输出能力，配合后置校验兜底，不要只靠Prompt。

核心题4：生产级Prompt怎么管理？

背诵要点
不能硬编码在代码里，要做体系化管理：

1. 版本化管理

   • 每次修改生成新版本，保留变更记录，支持一键回滚
   • 每个版本配套效果评估数据，可对比优劣

2. 配置化托管

   • 存在配置中心或Prompt管理平台，支持热更新，不用发版就能生效
   • 按场景、业务线拆分，避免互相干扰

3. 灰度发布

   • 新版本Prompt先切小流量验证，指标达标后再全量
   • 配套A/B测试，用数据验证优化效果

4. 配套用例

   • 每个Prompt版本绑定对应的测试用例集，修改后自动跑回归

高频追问

1. Prompt写得越长效果越好吗？

   • 不是。过长的Prompt会稀释关键信息，增加模型忽略规则的概率
   • 核心规则前置、简洁明确，比冗长堆砌效果好
   • 复杂规则配合少样本，比纯文字描述高效

2. 思维链是不是所有场景都能用？

   • 不是。简单问答、分类、提取类任务不需要，反而会增加输出长度和成本
   • 适合：数学推理、逻辑分析、复杂问题拆解、故障排查等需要深度思考的场景

3. 怎么快速判断是Prompt问题还是模型能力问题？

   • 换更强的模型测试，如果效果变好，大概率是模型能力不足
   • 换更详细的Prompt、加示例后效果变好，大概率是Prompt问题
   • 模型能理解规则但做不对，是能力问题；根本没遵守规则，大概率是Prompt没写清楚

2.3 LLM调用工程

核心题1：一次完整的LLM API调用闭环是什么

背诵要点
从请求到返回的完整7步流程：

1. 输入预处理：用户输入清洗、敏感词校验、Prompt组装
2. 鉴权限流：校验API Key、检查调用频次、配额校验
3. 请求封装：拼装模型参数（温度、max_tokens、上下文等），调用模型接口
4. 模型推理：大模型服务端执行推理，生成结果
5. 结果接收：接收模型返回，处理流式/同步响应
6. 后置校验：内容安全审核、格式校验、事实性校验
7. 日志埋点：记录输入输出、Token消耗、耗时、错误码，用于计费、监控、排查

核心题2：流式输出（SSE）的实现原理与价值

背诵要点

1. 定义：基于SSE（服务器推送事件）协议，服务端逐Token推送结果给前端，实现打字机效果
2. 原理：HTTP长连接，服务端持续推送数据块，前端逐段渲染，无需轮询
3. 核心价值：大幅降低用户感知等待时长，首字返回即可开始阅读，体验远好于同步等待完整结果
4. 适用场景：对话、写作、长内容生成等用户实时等待的场景
5. 注意点：需要处理连接中断、异常重连、最终结果落库等问题

核心题3：为什么需要多模型统一封装？常用方案有哪些？

背诵要点
核心原因：

1. 屏蔽不同厂商的接口差异，业务代码不用适配多套API
2. 灵活切换模型，同一份业务逻辑可以快速更换底层模型
3. 统一管控鉴权、限流、缓存、日志、计费，降低重复开发
4. 方便做降级容灾，主模型故障自动切备用模型

常用方案：

• LiteLLM：轻量开源库，支持上百种模型，Python生态友好，入门首选
• OneAPI：开源API网关，支持管理多渠道密钥、配额分发，适合团队使用
• 自研封装：大型团队基于自身需求定制，灵活度最高

核心题4：LLM调用的成本优化手段有哪些？

背诵要点
按性价比从高到低排序：

1. 分级模型路由

   • 简单任务（分类、提取、润色）用小模型，复杂任务（推理、长文生成）用大模型
   • 收益：成本降低40%-60%，是性价比最高的优化手段

2. 结果缓存

   • 高频重复问题直接返回缓存结果，不调用大模型
   • 适用：FAQ、标准问答、固定格式生成等场景

3. Token裁剪

   • 合理设置max_tokens，避免无意义的长输出
   • 上下文去重、压缩，剔除无关信息，减少输入Token

4. Prompt精简

   • 去掉冗余话术，保留核心规则，减少系统提示长度

5. 批量处理

   • 非实时任务批量调用，提升吞吐，降低单位成本

核心题5：怎么做LLM调用的容灾降级？

背诵要点
五层兜底机制，保障服务可用性：

1. 备用模型降级

   • 配置主备模型，主模型调用失败、超时、限流时，自动切换备用模型
   • 建议至少配置1个国产+1个不同厂商的备用

2. 超时熔断

   • 设置合理的超时时间，避免长时间阻塞业务线程
   • 连续失败触发熔断，快速返回失败，避免雪崩

3. 降级策略

   • 高并发时，非核心场景降级为简化版回答、关闭长文本生成
   • 极端情况返回预设兜底话术，保证服务不挂

4. 重试机制

   • 网络波动、偶发错误自动重试，配合指数退避
   • 注意：只对幂等的生成类请求重试，有副作用的操作不能乱重试

5. 流量削峰

   • 突发流量进入队列排队，避免瞬间打满模型配额

高频追问

1. LLM缓存怎么设计？有什么注意事项？

   • 缓存Key：对问题做归一化（去标点、转小写、同义词替换）后生成哈希
   • 缓存粒度：完整答案缓存、Embedding结果缓存、召回结果缓存
   • 注意事项：权限隔离，不同租户、不同权限的缓存不能互通；设置合理TTL，避免知识过期
   • 风险：缓存污染，错误答案被缓存后持续扩散，要有更新和失效机制

2. 怎么选择超时时间？设置多久合适？

   • 没有固定值，按场景定：简单问答3-5秒，长文本生成15-30秒
   • 原则：99分位的正常请求能完成，同时避免异常请求长时间占用资源
   • 配合流式输出，首字超时和整体超时分开设置，体验更好

3. 多模型网关会不会成为性能瓶颈？

   • 网关只做转发和协议转换，计算量很小，一般不会成为瓶颈
   • 高并发场景注意做好连接池、异步处理，避免单点故障
   • 生产部署多实例，保证高可用

2.4 主流模型选型指南

核心题1：海外模型与国产模型的核心对比与选型

背诵要点
从四个核心维度对比：

选型原则：

• 面向国内用户、企业内部系统、数据敏感场景：优先选国产模型
• 复杂推理、国际化业务、无数据合规风险：可选择海外模型
• 生产级建议至少兼容2家以上厂商，避免单一依赖

核心题2：大小模型怎么选型？

背诵要点
大模型（百亿参数以上）适用场景：

• 复杂推理、深度分析、长文生成、多轮规划、代码开发
• 作为调度大脑，负责Agent的规划、决策、整合
• 对输出质量要求高、容错率低的场景

小模型（7B-34B参数）适用场景：

• 分类、提取、摘要、润色、简单问答等标准化任务
• 作为执行层，处理单一简单任务，降低成本
• 高并发、低延迟要求的场景
• 本地化、私有化部署，算力有限的场景

落地最佳实践：分层架构

• 上层用1个强推理大模型做全局规划和最终整合
• 下层用多个小模型执行具体子任务
• 系统自动判断任务复杂度，路由到对应模型
• 在保证效果的前提下，最大程度降低成本

核心题3：典型业务场景的模型选型建议

背诵要点

1. 企业知识库问答

   • 优先选中文能力好、长上下文稳定的国产模型
   • 搭配轻量Embedding模型，检索+生成分离

2. 智能客服

   • 简单咨询用小模型降本，复杂问题升级大模型
   • 重点关注可控性、拒答能力、格式稳定性

3. Agent/工具调用

   • 优先选Function Calling能力稳定的模型
   • 规划能力强的模型更适合做Agent大脑

4. 代码开发助手

   • 优先选代码能力强的模型，海外模型整体有优势
   • 国产DeepSeek、通义千问代码版也能满足大部分场景

5. 内容创作、文案生成

   • 创意要求高选大模型，批量标准化生成立用小模型
   • 重点关注风格可控性、输出稳定性

高频追问

1. 效果不好时，先优化Prompt还是换更大的模型？

   • 优先优化Prompt、检索、工程侧，成本低、见效快
   • 工程优化到瓶颈后，再考虑换更大的模型
   • 很多时候效果差不是模型能力不够，是Prompt、上下文、检索没做好

2. 开源模型和闭源API怎么选？

   • 闭源API：开箱即用、无需运维、能力上限高，适合快速落地、中小团队
   • 开源模型：数据不出域、可定制、长期成本低，适合数据敏感、大规模、有运维能力的团队
   • 选型核心：有没有私有化部署需求、有没有定制微调需求、有没有足够的运维算力

3. 怎么评估一款模型适不适合自己的业务？

   • 不要只看排行榜分数，用自己的业务场景数据做实测
   • 核心指标：业务任务准确率、输出稳定性、速度、成本
   • 选3-5款候选模型，用同一批测试用例跑对比，用数据说话