LLM应用工程最佳实践

- 将提示词视为代码：将其保存在带名称、版本和负责人的版本控制文件中，而不是散落在各处的内联字符串。 - 在调整提示词之前，从真实用户输入构建评估集，并在每次提示词或模型变更时重新运行它。 - 要求使用JSON模式或工具调用进行结构化输出，并在使用前用模式库验证它。 - 在模型提供商周围放置一个轻量级网关或包装器，以便切换模型或添加回退只需配置变更。 - 在生产环境中固定确切的模型版本，并在评估通过后谨慎升级它们。 - 当输出超过一两句话时，向用户流式传输响应。 - 从简单的混合搜索（关键词加嵌入）开始检索，并在使用复杂RAG管道之前添加重排序。 - 按文档的自然结构（标题、章节）分块，并保留源元数据，以便答案可以引用它们。 - 保持上下文小而相关；检索到的文本越多，往往会使答案更差，而不是更好。 - 给代理一个简短、狭窄且描述清晰的工具列表，并带有严格的输入模式，而不是一个万能工具。 - 对代理循环设置硬限制：最大步骤数、最大令牌数和墙钟超时。 - 在应用外部发送、删除、支付或更改数据的任何工具调用之前，要求人工确认。 - 将所有检索到的文档、网页和工具结果视为不可信输入，可能包含提示注入。 - 记录每次模型调用，包括提示词版本、模型、延迟、令牌数和成本，并删除用户数据。 - 缓存确定性调用，并对长而稳定的系统提示词使用提示词缓存。 - 使用通过评估的最小模型，只将困难案例路由到昂贵模型。 - 对速率限制和瞬时错误使用指数退避和抖动重试，绝不在紧密循环中对验证失败重试。 - 对提取和分类保持低温度，仅对创意生成使用更高温度。 - 向用户展示答案来源，并使其易于报告不良响应。 - 收集点赞和点踩反馈，并将不良案例反馈到评估集中。 - 在提示词、检索和评估明确达到其极限之前，不要进行微调。