产品内集成LLM：实用现场指南

构建基于LLM的产品让我学到了一个清晰的教训：最好的AI特性往往是隐形的。

当它正常工作时，用户不会停下来思考“这是AI”。他们只是点击按钮，快速获得答案，然后继续他们的任务。而当它失败时，你会立即注意到：加载时间过长，或者答案听起来很自信但实际是错误的。我多次遇到这两种情况。每一次，解决方案都更多地来自精心的工程选择，而不是“更智能的AI”。只使用你需要的上下文。要求结构化输出。在准确性重要时保持低随机性。允许系统说“我不知道”。

本指南并非关于大型研究想法。它涵盖的是任何工程师都可以遵循的实际步骤，以将开源LLM引入真实产品。可以把它看作一本现场指南，包含简单模式、可直接复制的代码以及使AI特性可靠、稳定和快速的习惯。

工作原理——四步循环

每个可靠的AI特性都遵循相同的循环。保持一致性。枯燥是好的。

1) 读取：获取用户输入和最小部分的应用程序上下文。更多上下文意味着更高的成本、更慢的响应以及模型漂移的更大空间。示例：支持场景中，仅传递用户ID和最后订单摘要，而不是整个订单历史。

2) 约束：设定规则，使模型保持在期望的约束内。包括：将系统提示视为合同，声明助手是什么和不是什么；要求符合模式的合法JSON；信息缺失时询问用户简短后续或回答“我不知道”；保持隐私规则明确；对提示进行版本控制并测试；将temperature与任务匹配（低用于提取、分类等，高用于头脑风暴）。

3) 执行：目标是生成可直接用作工作流下一步输入的LLM输出。使用结构化输出（如Pydantic）用于程序化步骤；使用函数调用（工具）用于实时数据或操作；对于仅叙述性的结果使用纯文本。文中提供了使用Groq API的代码示例。

4) 解释：向用户展示步骤、工具和引用，以增强对AI输出的信心。例如，在答案后附加“我使用了什么”的注释，显示来源标题或ID；在提取中显示匹配文本的预览；在工具流中显示哪些工具运行及其顺序。

核心模式

文章介绍了可重用的模式：路由器（分类并路由到正确处理器）、提取器（将混乱文本转为整洁字段）、翻译器（将意图转换为安全的DSL）、摘要器（缩短或调整语气）、带工具的模式（模型提议，应用执行）、编排器（链式步骤，应用保持控制）。

安全发布

发布前：编写提示单元测试；从小型评估集开始；在影子模式或功能标志后运行并记录所有内容。生产跟踪指标：延迟p50和p95、输入输出令牌、模型和提示版本、工具调用成功/失败、非法JSON率、拒绝率、用户编辑率、引用正确性。可使用Groq Console仪表板监控。

回退策略：如果任务无法回答，返回“我不知道”并给出下一步；结果太长或太慢时流式传输部分结果；使用小模型优先路由，必要时升级到大模型。

常见陷阱与快速修复

上下文过多：只获取所需并重新排序。让模型直接接触生产数据：始终使用工具和安全层。对一切使用聊天：许多任务更适合作为简单提取器或路由器。冗长答案推高成本：偏爱简洁风格和结构化字段。无版本控制：在每次日志中存储提示ID和模型版本。

文章最后提供了一个简短清单和核心原则：可靠的AI特性是无聊的、隐形的——它们只是工作。只读取所需内容。用清晰规则约束。用结构化输出和安全工具执行。解释发生了什么。从最小可用特性开始。使用适合用例的模式。监控一切。基于真实用户行为改进。目标不是构建令人印象深刻的AI演示，而是发布用户每天依赖的特性。