为什么我们需要记录人工智能系统的每个调用？
当一个人工智能系统进入生产阶段时，第一个严峻的问题不是它如何工作，而是“为什么”它这样说。客户会质疑报价，审计人员会询问决策依据，团队成员可能会发现本月的摘要质量变差，但无法确定从何时开始。
此时，你要么拥有记录，要么没有，而且之后再重建是不可能的。今天再次提出相同问题，只会得到今日模型、今日提示和今日数据当下的答案，这并不能证明任何事情。
日志记录是一个从一开始就做好的决定。如果晚加，它只覆盖后续发生的事情。
影响回答结果的六大因素
人工智能的响应是多种输入的产物。在每次调用中，记录所有输入：
- 请求：一个唯一的ID、时间戳、提出请求的人或系统以及提交的文本或数据。
- 上下文：系统检索并展示给模型的所有文档、记录或行，每个都带有标识号和版本号。
- 提示：提示模板加上运行时组装的内容和模板的版本。
- 模型：精确的模型标识符（而非家族名称），以及使用的设置：温度、令牌限制，以及它能调用的工具。
- 输出：原始响应（在任何清理前）和如果两者不同的处理后的版本。
- 后果：后续发生的事情：显示给用户、发送给客户、用于审批索赔，以及是否有人接受、编辑或拒绝了它。
删除上下文和提示，你将只剩下半个对话。你可以看到系统回答了什么，但无法确定为什么这个答案是合理的。
版本号是常被忽略的部分
三个因素在人工智能系统中会悄然改变，而没有人提交任何更改请求。有人编辑一个提示模板；供应商更新了同一API名称下的模型；知识库重新索引，系统开始检索不同问题相同的文档。
每种情况都会影响质量，但它们不会出现在输出日志中。在每次调用中记录提示、模型和数据索引的版本标识符，这样“好周与坏周之间发生了什么变化”这个问题就能轻松回答。没有这些记录，你可能需要一周的时间猜测，而一位高级成员正在等待。
人为纠正是最佳信号
当一个人编辑一个AI草稿在发送前，他们已经用最具体的语言告诉了你错误所在。将原始版本和修改后的版本存储在一起。
这样做会带来两个结果。编辑率成为质量指标，比投诉来得早。纠正累积成一组示例，用于改进系统，这些示例来自你的实际工作，而不是购买或发明的。
漂移是比较，而非警报
没有什么能通知你输出变差了。退化是渐进的，每条单独的回答看起来都是合理的。
实际方法是保留一组固定真实请求（足够100个，来自实际流量，覆盖你的棘手案例），每个月重新运行它们。比较新答案和存储的答案。在两者不同时，一个人阅读两者并判断哪一个更好。这一方法只有在你保存了输入时才能有效（这是记录所有调用讨论的核心）。
结合你已经拥有的数据：编辑率、拒绝率、是否需要人工干预、系统找到相关文档的比例。通常，后者上升意味着你的数据过期了，而不是模型出了问题。
首先确定保留和红行动作
这些日志包含用户输入的所有内容，这意味着它们也承担着与任何其他个人数据相同的义务。根据输入内容进行分类，对不需要可读性的部分进行掩码或标记化，并将日志存储在应用程序之外，以防一个故障导致记录丢失。
明确设置保留时间。对于具有合同或监管重要性的决策，在相关风险持续存在期间保留记录，并确保存储是只写模式的，这样就不可能修改历史记录。对于日常流量，更短的时间更便宜。指定一个人来负责政策。
存储成本较低。昂贵的部分是在一个正在运行系统中回装所有这些记录（而你已经被问到无法解释一个你无法说明的输出）。我们从一开始就建立这些记录，因为它们是将一个人工智能系统从你信任的系统转变为你可以证明的系统的关键。