大模型应用开发看起来门槛不高（调个 API 就行），但要做好需要理解几个关键决策点。本文按实际开发顺序梳理。
第一步：明确你的场景属于哪一类
不同场景的技术路线差异很大：
| 场景类型 | 技术路线 | 复杂度 | 典型应用 |
|---|---|---|---|
| 单轮生成 | 直接调 API + Prompt | 低 | 文案生成、翻译、摘要 |
| 信息抽取 | API + JSON 模式输出 | 低 | 简历解析、票据信息提取 |
| 知识问答 | RAG（检索增强生成） | 中 | 企业知识库、客服 |
| 多步任务 | Agent + 工具调用 | 高 | 数据分析助手、自动化流程 |
| 定制能力 | 微调（SFT/LoRA） | 高 | 特定领域风格、专业任务 |
建议：从最简单的路线开始。很多需求用「Prompt + JSON 输出」就能解决，不需要上 RAG 或 Agent。
第二步：模型选型——够用就好
成本差异主要来自模型选型。核心原则是「按任务复杂度分层」：
- 简单任务（分类、抽取、改写、翻译）：用 Flash 或 Turbo 级模型。成本可低至旗舰模型的 1/20。
- 中等任务（客服问答、内容生成、摘要）：用 Plus 级模型。
- 复杂任务（深度推理、代码生成、长文档分析）：用 Max 级模型。
实践建议：先用中档模型做验证，评估效果。如果效果不够再升级到旗舰；如果效果够用但成本高，尝试降级到小模型看是否能保持可接受的质量。很多任务在降级后效果差异很小，但成本差异巨大。
第三步：Prompt 工程的实用技巧
结构化你的 Prompt
把 Prompt 分为四部分，能让模型输出更稳定：
- 角色定义：你是谁（如「你是一名专业的客服助手」）
- 任务描述：要做什么（明确、具体）
- 约束条件：不能做什么（如「不知道就说不确定，不要编造」）
- 输出格式：期望的结构（如 JSON Schema 或示例）
Few-shot 示例
对于格式要求严格的输出（如结构化抽取），给 2–3 个输入输出示例的效果远好于长篇描述。这是提升准确率最有效的手段之一。
要求模型「先思考再回答」
对推理类任务，让模型先列出分析步骤再给结论，通常能显著提升准确率。这也是为什么推理型模型的输出包含思考过程。
明确边界
明确告诉模型「如果信息不足，请回答不确定，不要编造」。这能显著降低幻觉——尤其是在没有 RAG 的场景下。
第四步：RAG 架构（知识问答的核心）
RAG 的本质是「先把相关资料找出来，再让模型基于资料回答」。完整链路：
- 文档解析：把 PDF、Word、HTML 等转成纯文本。
- 文档切片：切成合适大小的块（通常 300–800 字符，重叠 10%–20%）。
- 向量化：用 Embedding 模型把每块文本转成向量。
- 存储：向量存入向量数据库（如 DashVector）。
- 检索：用户提问时，把问题向量化并检索最相似的 Top-K 块。
- 生成：把检索到的文本块作为上下文，连同问题一起送给模型生成回答。
RAG 的常见优化点
- 切片策略：按语义边界（段落、标题）切分优于按固定长度切分。表格与列表需要特殊处理。
- 混合检索：向量检索 + 关键词检索（BM25）组合，能覆盖语义相似与精确匹配两类需求。
- 重排序（Rerank）：检索出较多候选（如 20 个）后用 Rerank 模型精排取 Top-5，能显著提升相关性。
- 查询改写：多轮对话中，用户问题常含指代（「它」「这个」）。用模型先改写为独立完整的问题再检索。
- 上下文压缩：只把检索结果中最相关的部分送入模型，减少 tokens 消耗。
RAG vs 微调怎么选
| 需求 | RAG | 微调 |
|---|---|---|
| 知识频繁更新 | ✅ 改文档即可 | ❌ 需重新训练 |
| 需要溯源引用 | ✅ 可标注来源 | ❌ 无法溯源 |
| 改变输出风格/格式 | ⚠️ 效果有限 | ✅ 效果好 |
| 掌握专业任务能力 | ⚠️ 依赖检索质量 | ✅ 效果好 |
| 实施成本 | 低 | 高（需数据与算力） |
多数企业场景应先用 RAG，因为它成本低、更新快、可溯源。只有当 RAG 无法满足（如需要模型掌握特定输出风格或专业推理模式）时才考虑微调。两者也可结合。
第五步：成本控制
LLM 应用的成本主要是 tokens 消耗。控制手段：
- 模型分层：不同任务用不同规格模型（效果最显著）。
- Prompt 精简：去掉冗余说明，用示例代替长描述。
- 缓存：相同或相似的问题缓存结果，避免重复调用。
- 上下文裁剪：只传必要的上下文，不要把所有历史对话都塞进去。
- 批量调用：离线任务使用 Batch API，通常有 5 折优惠。
- 输出限制：设置 max_tokens，避免模型输出过长。
- 流式输出：改善体验的同时也让用户可提前中断，减少无效生成。
第六步：效果评估与迭代
没有评估就没有优化。建议建立最小可行的评估体系：
- 构建测试集：准备 50–200 个「问题 + 标准答案」的测试样本，覆盖典型场景与边界情况。
- 定期跑评估：每次修改 Prompt 或模型后跑一遍测试集，对比准确率。
- 线上记录：把线上的问题与回答记录到日志服务 SLS，定期人工抽检，发现真实场景中的失败案例。
- 失败案例回流：把线上失败的案例加入测试集，避免同样的问题反复出现。
一个可复用的最小架构
对于多数企业知识问答场景，推荐的最小架构是：
- 前端：Web 应用或集成到钉钉/企业微信
- 后端：函数计算 FC（免运维，按调用付费）或 ECS 上的轻量服务
- 模型：百炼平台调用千问 Plus/Flash（按 tokens 付费）
- 知识库：百炼内置知识库（快速起步）或 DashVector 自建（需定制时）
- 可观测：SLS 记录调用日志与问答记录
这套架构没有 GPU 成本，起步几乎零投入，且能支撑相当规模的业务量。等业务量增长后再考虑模型私有化或推理优化。