完整题目
当前大语言模型在工业界应用中的主流技术范式有哪些（如提示工程、上下文学习、微调、RAG、Agent系统等）？请系统性地比较它们的技术原理、适用场景、优缺点及典型应用案例，并分析在实际落地中如何根据业务需求选择合适的技术路径。
本文目录
五大技术范式对比
| 范式 | 核心原理 | 适用场景 | 优缺点 | 典型案例 |
|---|---|---|---|---|
| 提示工程 | 通过指令设计激活模型能力 | 通用问答、格式转换 | 零成本、易迭代；受模型能力上限约束 | 客服话术生成 |
| 上下文学习(ICL) | 示例驱动，无需参数更新 | 小样本分类、风格迁移 | 灵活快速；受上下文长度限制 | 工单分类、情感分析 |
| 微调(SFT/PEFT) | 领域数据适配模型参数 | 垂直领域、稳定需求 | 效果深度定制；数据/算力成本高 | 滴滴司机调度策略模型 |
| RAG | 检索+生成，外挂知识库 | 知识密集型、需可解释 | 解决幻觉、实时更新；检索质量决定上限 | 智能客服、合规审查 |
| Agent | 工具调用+规划+记忆，自主决策 | 复杂任务、多步推理 | 能力边界扩展；稳定性、安全难控 | 自动派单、行程规划 |
选型决策框架
第一步：需求拆解
- 任务复杂度：单步问答 → ICL/提示工程；多步推理 → Agent
- 知识时效性：静态知识 → 微调；动态更新 → RAG
- 可控性要求：高合规场景优先RAG（可追溯来源）
第二步：成本权衡
数据成本：微调 > RAG > ICL > 提示工程
推理成本：Agent > RAG > 微调 > 提示工程
维护成本：Agent > RAG > 微调 > 提示工程第三步：滴滴场景示例
- 实时定价：微调（历史订单数据训练，延迟敏感）
- 司机答疑：RAG（政策文档频繁更新+需准确引用）
- 异常处理工单：Agent（需调用订单系统+地图服务+规则引擎）
关键认知
工业落地的核心是分层架构：基座模型+轻量适配层。多数场景组合使用，如"RAG+微调"（检索增强的微调模型）或"Agent+RAG"（工具链中包含知识检索）。避免过度工程，能用提示工程解决的不用Agent。
学习建议
建议从基础概念入手，结合真实案例理解各范式的应用场景，多阅读论文与开源项目，强化对RAG和Agent架构的实践认知。
换一种问法，检查是否真正理解
场景切入
假设你现在做客服系统，用户问了一个复杂问题，比如退款流程，你是直接让大模型回答，还是先去知识库查一下再回答？这两种方案各有什么优劣，实际中你怎么选？
层层追问
大模型落地一般有哪些主流技术路径？……提示工程、微调、RAG这些你了解吧？……那如果需求是实时更新知识，你选哪个？为什么？
直球架构
请系统比较提示工程、上下文学习、微调、RAG和Agent这几种技术范式，从原理、适用场景、优缺点到典型应用，再给一个选型决策框架。
练习口述回答 · 约4分钟
- 一句话点明本质：选型不是比谁好，是看场景和成本
- 五大范式按原理和边界拆开讲，重点对比RAG和微调
- 落地选型三步走：需求拆解、成本权衡、组合使用
- 给出可延伸点：Agent的稳定性问题
这道题我觉得本质不是在问你知道多少种技术，而是在考察你面对一个真实业务场景时，能不能做出合理的选型决策。我理解目前主流的有提示工程、[[上下文学习]]、微调、[[RAG]]和[[Agent]]这五条路，但它们不是互相替代，更多是互补。落地的时候，经常是两三个一起上，关键看场景和成本。
先说提示工程和上下文学习。这两个其实都是零成本或者接近零成本的方式，不更新模型参数。提示工程就是靠写指令，让模型按你的要求输出，比如客服话术生成，改改prompt就能迭代。上下文学习呢，给几个例子，模型就能照猫画虎，比如工单分类、情感分析，扔几条样本进去就能跑。它们最大的好处是快、便宜，但受模型本身能力上限和上下文长度限制。所以如果任务简单、数据量小、对效果要求不高，优先考虑这两个。
再来说微调和RAG，这两条路是我在实际项目中纠结最多的。微调，尤其是 [[LoRA]] 这种 PEFT，能让模型深度适配你的领域，比如滴滴的司机调度策略，用历史订单数据微调后，模型能学到非常精细的定价逻辑。但微调成本高，数据要清洗标注，算力也要钱，而且模型知识是静态的，政策文档一更新就得重训。RAG 正好补这个短板，它外挂知识库，检索加生成，知识可以实时更新，回答还能溯源。比如智能客服，政策文档三天两头改，用RAG就能保证回答永远是最新版本，而且用户问为什么这么赔，你可以直接翻到原文。但RAG也有坑，检索质量决定了效果上限，如果 [[Embedding]] 做不好、[[Chunk]] 切得不合理，模型拿到一堆噪音，生成的结果反而更差。所以我的经验是，如果知识更新频繁或者需要可解释性，优先RAG；如果知识稳定、对延迟和深度定制要求高，优先微调。但更常见的是两者结合，比如用微调后的模型做底座，再在关键环节接入RAG，既保留了领域能力，又解决了实时性问题。
最后是Agent系统。这个范式是把模型当成大脑，配合工具调用、记忆和规划，去完成复杂多步任务。比如订单异常处理，模型可能需要先查订单系统、再调地图服务、最后发通知，每一步都要自主决策。Agent的上限很高，但稳定性是个大问题，工具调用失败、规划不合理、安全风险，都是常见失败场景。所以我的判断是，Agent适合那些流程确定但步骤多的任务，而且上线前一定要做好异常兜底和人工复核。
说到Agent，我最近比较关注它的自我反思能力，比如 [[Reflexion]] 这类机制，模型执行完任务后能回顾自己的错误并修正，这在一定程度上缓解了稳定性问题。但代价是推理成本会翻倍，而且反思的质量本身也不可控。我觉得这块还有很大的优化空间。
所以总的来说，我会把选型看成三层：简单任务先用提示工程和上下文学习试水；知识密集型场景上RAG；深度定制需求上微调。真正落地时，组合才是常态，比如微调加RAG，或者Agent加RAG。但一定要避免过度工程，能用提示工程解决的，别急着上Agent。