日志分析：我太害怕AI的幻觉了
工作中80%的时间都要接触日志分析（溯源分析、反爬分析、威胁分析等等），现在有AI加持了之后之前想做的日志分析平台也可以快速实现了，但日志分析出来的结果是否可靠是否有幻觉就非常值得担心了，毕竟日志分析不像漏洞挖掘属于大概率、试一试的工作，需要严谨的数据依据做支撑。
本次记录的问题就是VB出来的日志分析平台在AI分析过程中与数据库数据不一致的问题。
开始
起因源于审计某次执行过程中，突然想着验证下思考过程中的SQL是否符合预期。
AI在此时间段的日志总量查询结果是81360条。
我手动执行SQL确认AI分析结束后传递数据过程是否存在幻觉，发现数据完全不对啊（卧槽了），心里直接凉凉了。进一步看最终通知的消息也是81360条，这下完蛋了，不会每次分析都漏了一半的日志吧……那分析了个寂寞。
问题排查
首先检查了执行的SQL，确认没有问题。
其次因为模型用的是内部网关，确认中间有没有添油加醋，确认没有问题（我应该相信公司的）
然后我在9点前后切换过定时任务分析用的模型，9点前用的模型是kimi-2.5，9点后用的模型是glm-5.1。就是这么巧，9点之后的数据查询起来都和我直接执行SQL语句差了一半，我很怀疑是glm-5.1给我产生幻觉了，但是！我单独使用glm-5.1执行仍然没有发现问题！
最后我懵了，SQL没问题、模型没问题、网关没问题，但就是数据有问题……
无奈，我将现象和项目信息、执行时间、执行历史给DeepSeek-v4-pro（我还是担心模型问题，换了一个），让其帮我分析问题的根本原因是什么，经过长达15分析各种二分法、模型关联、看日志、看执行记录，最终得出结论：两个定时任务冲突了（定时任务导出还没完全导出数据的时候，AI自动分析就开始了（AI自动分析的时候日志还没有完全导入进来，导致数据量远少于我后来手动执行SQL））
回顾
说来也巧，前一天晚上的时候我是验证过AI查询的数据量和手动执行SQL的数据量是不是一致的，那时候确实是一致（这也是导致我一开始怀疑是我切换模型的原因）。实际上应该是夜间Clickhouse查询压力小，查询速度快，定时任务很快就完成了，AI分析开始的时候日志已经导入完成了。但到了白天，大家都在Clickhouse查询，导致查询负载大，查询速度慢，定时任务执行的周期就变长了，AI分析的时候日志量并不完整。
最后重新修改了执行逻辑，执行分析前先查询实际数据范围：
- 查询 ClickHouse 获取 max(start_datetime)
- 传入 compute_analysis_window 作为 window_end
- AI 分析的时间窗口精确匹配实际可用数据