要将用户反馈或真实查询纳入 RAG 评估数据集，首先从与您的应用程序的实际交互中收集数据。例如，如果您有客户支持聊天机器人，请记录用户问题、系统提供的回复以及明确的反馈（例如，赞/踩评级）。 隐式反馈（如用户在收到不令人满意的答案后重新措辞查询）也可以表明模型性能方面的差距。 会话记录或 API 日志等工具可以自动执行此收集。 收集完毕后，匿名化数据以删除个人身份信息 (PII) 并过滤掉不相关或低质量的条目（例如，垃圾邮件）。 按意图或主题对查询进行分类，以确保平衡覆盖范围——例如，将医疗 FAQ 查询与技术故障排除请求分开分组。 此原始数据将成为测试您的 RAG 系统处理真实世界场景效果的基础。
真实世界查询的主要挑战是噪声、歧义和隐私。 真实的客户输入通常包含拼写错误、俚语或含糊不清的措辞（例如，没有上下文的“它不起作用”），这会混淆为干净数据设计的评估指标。 例如，像“修复错误 404”这样的查询可能缺乏关于特定应用程序或环境的详细信息，使得很难评估 RAG 系统的答案是否充分。 隐私是另一个问题：即使是匿名化日志也可能无意中暴露敏感模式，尤其是在医疗保健或金融等领域。 此外，用户行为会随着时间而变化——季节性趋势或新产品功能可能会使旧查询过时。 例如，旅行应用程序可能会在疫情期间看到“COVID 旅行限制”查询激增，但一旦政策发生变化，这些查询就不再相关，需要不断更新数据集。
为了应对这些挑战，请将真实数据与合成示例进行平衡。 例如，使用澄清意图的变体来扩充不明确的真实查询（例如，将“修复错误”扩展为“修复 Android 应用程序上的登录错误”）。 对敏感领域使用差分隐私技术或合成数据生成。 为了处理不断变化的用户需求，定期使用新的日志重新测试您的 RAG 系统并弃用过时的测试用例。 通过不仅衡量答案的正确性，还衡量相关性和清晰度，使评估指标与用户满意度保持一致。 例如，如果用户在某些答案后经常跟进“您能换一种方式解释吗？”，请标记这些响应以进行改进。 通过将精心策划的真实世界数据与有针对性的合成示例和自适应评估实践相结合，您可以构建一个强大的 RAG 测试框架，该框架可以反映实际用户需求，同时减轻隐私和噪声问题。
