LLM生成的说明可能包含数值或对象的混淆，也可能添加没有依据的内容。用于运维时，不仅要看是否易读，还要明确可以根据什么证据进行核实。

本文介绍BASTION重视的输出验证思路，不说明具体的内部处理步骤，也不保证能够防止所有错误。

1. 核查说明的依据 #

监控报告中的数量、对象和时间范围会影响运维人员的判断。需要区分AI文字中的描述，与能够从观测记录中确认的内容。

即使数字相同，只要对象或统计时段不同，含义就会改变。不能仅凭表达自然或数字看起来合理，就认定说明正确。

2. 原始观测也有局限 #

日志和汇总结果同样会受到数据缺失、延迟、重复和采集范围差异的影响。有记录，并不一定意味着记录完整反映了实际发生的全部情况。

处理信息时，应注意能够确认哪些对象和时段的信息，以及哪些内容未被观测到。LLM输出与记录一致，只是在该范围内确认了相互一致性，并不保证整体情况都被正确反映。

3. 区分无法确认的内容 #

依据不足、记录与说明不一致，或处理尚未完成时，重要的是不将这些状态当作已经确认的事实。

核查数字是否一致，与判断对原因或意图的解释是否合理，也是不同的工作。应区分可自动比对的范围与需要进一步调查的范围。

4. 区分输出核查与实际操作 #

BASTION的自动防御依据既定的判断条件和保护条件处理，并不以直接将LLM生成的说明用于拦截正常用户或更改配置为前提。

实际应用改进建议时，也需要确认授权范围与应用条件。核查说明、检查建议和应用后观测，分别具有不同的核查目的。

5. 区分验证范围与实际效果 #

不能将此前公开说明中的内部处理示例，视为能够完整审计所有输出的现行规格。我们分别说明已经实现的检查范围、实际运行记录和效果评估。

即使设置了检查，也不一定能消除漏查或错误提示。当使用的模型、输入或观测条件发生变化时，也需要在相应条件下重新确认。

6. 部署时需要确认的事项 #

在使用环境中，应明确使用哪些输出、用于什么目的，以及能够核实到什么程度。使用外部服务时，也需要确认发送内容、连接目标，以及客户信息和认证信息的处理方式。

部署设计、集成与评估将在确认目标范围和工作内容后单独报价。公开文章介绍基本思路，不刊载内部验证步骤或实际客户日志。