大模型应用开发常见坑点
一、把大模型当数据库用
问题：
- 期望大模型"记住"所有企业内部知识
- 直接让模型回答它没见过的私有数据
结果： 幻觉严重，答案看似合理但完全编造
原则：
- 大模型的知识有截止日期
- 私有知识必须通过 RAG 或微调注入
- 永远不要盲目信任模型输出
二、Prompt 写得像散文
问题：
- Prompt 没有结构
- 指令模糊
- 没有输出格式约束
结果： 输出不稳定，格式不可控
原则：
- Prompt 要结构化：角色 + 任务 + 格式 + 约束 + 示例
- 越具体越好
- 用 Few-shot 示例锚定输出格式
三、RAG 系统"检索了但没用好"
问题：
- 文档切分粒度不对
- 没有做重排序
- 检索结果直接塞给模型
结果： 检索结果相关但回答不相关
原则：
- 切分策略要根据文档类型调优
- 一定要做重排序
- Prompt 要引导模型"基于以下信息回答"
四、Agent 无限循环不收敛
问题：
- 没有最大步数限制
- 工具描述不清晰
- 没有终止条件
结果： Token 消耗爆炸，响应时间极长
原则：
- 设置最大推理步数
- 工具描述要精确
- 设计明确的终止条件
五、忽视流式输出体验
问题：
- 用户等待 10 秒才看到完整回答
- 没有实现 SSE 流式输出
结果： 用户体验极差
原则：
- 必须实现流式输出
- 前端展示打字机效果
- 长时间无输出要有超时处理
六、没有做敏感内容过滤
问题：
- 用户输入攻击性内容
- 模型输出不当内容
结果： 合规风险，品牌风险
原则：
- 输入和输出都要做内容审核
- 建立敏感词库 + 模型审核双重机制
- 高风险场景加人工审核
七、Token 成本不控制
问题：
- 每次都把完整对话历史发给模型
- RAG 检索结果不截断
结果： 成本飙升
原则：
- 对话历史要做压缩和摘要
- RAG 结果做截断
- 相似问题做语义缓存
- 建立 Token 用量监控和预算告警
八、把所有问题都交给一个大模型
问题：
- 简单任务也用最贵的模型
- 不做模型路由
结果： 成本高、延迟高
原则：
- 简单任务用小模型或规则
- 复杂任务用大模型
- 建立模型路由策略
九、没有评估体系就上线
问题：
- 不知道模型回答的准确率
- 上线后靠用户反馈发现问题
结果： 线上翻车
原则：
- 建立评估数据集
- 自动化评估 + 人工评估结合
- 上线前做充分测试
十、架构一开始就设计成单体
问题：
- 模型调用、RAG、对话管理全部耦合
结果： 无法独立扩展，排查问题困难
原则：
- 模块化设计：模型调用层、RAG 层、对话管理层、安全审核层分离
- 用消息队列解耦
- 每个模块可独立部署和扩展