大模型让自然语言交互、知识问答、代码生成、内容创作和智能 Agent 变得更容易。但从工程角度看，大模型并没有替代机器学习的基本问题：数据、评估、部署、监控、成本和风险仍然存在。
大模型应用的核心，不是“把问题丢给模型”，而是围绕模型构建可靠的上下文、工具、评估和反馈系统。
一、大模型适合什么任务
大模型擅长：
- 文本理解和生成。
- 多轮对话。
- 总结、改写、分类和抽取。
- 基于上下文的问答。
- 代码辅助和工具调用。
- 多模态理解和生成。
但它也有局限：
- 可能产生幻觉。
- 对私有知识不了解。
- 输出不稳定。
- 成本和延迟较高。
- 对严格数值和状态一致性任务不天然可靠。
工程设计要承认这些边界。
二、RAG 的基本思想
RAG 是 Retrieval-Augmented Generation，即检索增强生成。它先从知识库中检索相关内容，再把内容作为上下文交给大模型生成答案。
基本流程：
- 文档清洗和切分。
- 生成文档块 Embedding。
- 存入向量索引。
- 用户问题生成 Embedding。
- 检索相关文档块。
- 组合提示词。
- 大模型生成答案。
- 返回引用和结果。
RAG 适合知识更新频繁、需要引用来源、知识不适合直接训练进模型的场景。
三、RAG 的关键不是向量库
很多项目以为接入向量数据库就完成了 RAG。真正影响效果的因素包括：
- 文档质量。
- 切分粒度。
- Embedding 模型选择。
- 检索召回率。
- 重排策略。
- 提示词约束。
- 答案引用。
- 无答案时的拒答策略。
如果检索不到正确上下文，再强的生成模型也只能猜。
四、什么时候需要微调
微调适合让模型学习稳定格式、领域表达、分类边界或特定任务模式。它不适合频繁更新知识，也不适合把大量实时文档塞进模型参数。
可考虑微调的场景：
- 固定格式输出。
- 大量高质量标注样本。
- 领域术语和风格稳定。
- 任务边界清晰。
- 需要降低提示词复杂度。
如果问题主要是“模型不知道最新知识”，优先考虑 RAG。如果问题是“模型知道但总是不按格式做”，可以考虑微调。
五、评估大模型应用
大模型应用不能只靠人工随便问几句。需要建立评估集，覆盖常见问题、边界问题、错误问题和高风险问题。
评估维度包括：
- 正确性。
- 完整性。
- 引用是否准确。
- 是否遵守格式。
- 是否拒绝无依据回答。
- 延迟和成本。
- 安全与合规。
对 RAG 系统，还要分开评估检索和生成：检索是否找到了正确材料，生成是否忠实使用材料。
六、与传统机器学习协同
大模型不是所有问题的最佳选择。很多结构化预测、排序、风控、推荐和实时决策，传统机器学习模型仍然更便宜、更稳定、更可控。
常见协同方式：
- 传统模型做召回和排序，大模型做解释和交互。
- 大模型做数据标注或特征生成，传统模型做在线预测。
- RAG 提供知识问答，规则系统提供权限和安全边界。
- 小模型处理高频任务，大模型处理复杂长尾任务。
七、上线后的监控
大模型应用要监控：
- 调用成功率。
- 延迟和 token 成本。
- 检索命中率。
- 用户反馈。
- 无答案比例。
- 格式错误率。
- 安全拦截率。
- 版本变化影响。
模型、提示词、知识库和工具链任何一环变化，都可能影响输出。
八、实践建议
从最小可验证系统开始：一批高质量文档、一个可解释的检索流程、一个明确提示词、一个小型评估集。先证明系统能稳定回答核心问题，再扩展知识范围和能力边界。
大模型工程的关键，是把不确定的生成能力放进确定的工程框架里。