https://pbuff07.github.io/tags/%E6%8E%92%E6%9F%A5/Recent content in 排查 on 嘴强黑客 /pbuff07Hugozh-cnFri, 29 May 2026 16:00:00 +0800https://pbuff07.github.io/posts/2026-05-29-%E6%97%A5%E5%BF%97%E5%88%86%E6%9E%90-%E6%88%91%E5%A4%AA%E5%AE%B3%E6%80%95ai%E7%9A%84%E5%B9%BB%E8%A7%89%E4%BA%86/Fri, 29 May 2026 16:00:00 +0800https://pbuff07.github.io/posts/2026-05-29-%E6%97%A5%E5%BF%97%E5%88%86%E6%9E%90-%E6%88%91%E5%A4%AA%E5%AE%B3%E6%80%95ai%E7%9A%84%E5%B9%BB%E8%A7%89%E4%BA%86/<p>工作中80%的时间都要接触日志分析（溯源分析、反爬分析、威胁分析等等），现在有AI加持了之后之前想做的日志分析平台也可以快速实现了，但日志分析出来的结果是否可靠是否有幻觉就非常值得担心了，毕竟日志分析不像漏洞挖掘属于大概率、试一试的工作，需要严谨的数据依据做支撑。</p> <p>本次记录的问题就是VB出来的日志分析平台在AI分析过程中与数据库数据不一致的问题。</p> <h1 id="开始">开始</h1> <p>起因源于审计某次执行过程中，突然想着验证下思考过程中的SQL是否符合预期。</p> <p><img src="https://pbuff-blogs-1257793641.cos.ap-chengdu.myqcloud.com//blogs202605291603098.png" alt="image-20260529160229013"></p> <p>AI在此时间段的日志总量查询结果是81360条。</p> <p><img src="https://pbuff-blogs-1257793641.cos.ap-chengdu.myqcloud.com//blogsblogsimage-20260529160508720.png" alt="image-20260529160508720"></p> <p>我手动执行SQL确认AI分析结束后传递数据过程是否存在幻觉，发现数据完全不对啊（卧槽了），心里直接凉凉了。进一步看最终通知的消息也是81360条，这下完蛋了，不会每次分析都漏了一半的日志吧&hellip;&hellip;那分析了个寂寞。</p> <p><img src="https://pbuff-blogs-1257793641.cos.ap-chengdu.myqcloud.com//blogsimage-20260529160628028.png" alt="image-20260529160628028"></p> <p><img src="https://pbuff-blogs-1257793641.cos.ap-chengdu.myqcloud.com//blogs%E4%BC%81%E4%B8%9A%E5%BE%AE%E4%BF%A1%E6%88%AA%E5%9B%BE_aea1317e-998f-4e26-b28d-bac8646c86bf.png" alt="企业微信截图_aea1317e-998f-4e26-b28d-bac8646c86bf"></p> <h1 id="问题排查">问题排查</h1> <p>首先检查了执行的SQL，确认没有问题。</p> <p>其次因为模型用的是内部网关，确认中间有没有添油加醋，确认没有问题（我应该相信公司的）</p> <p><img src="https://pbuff-blogs-1257793641.cos.ap-chengdu.myqcloud.com//blogsimage-20260529161206499.png" alt="image-20260529161206499"></p> <p>然后我在9点前后切换过定时任务分析用的模型，9点前用的模型是kimi-2.5，9点后用的模型是glm-5.1。就是这么巧，9点之后的数据查询起来都和我直接执行SQL语句差了一半，我很怀疑是glm-5.1给我产生幻觉了，但是！我单独使用glm-5.1执行仍然没有发现问题！</p> <p><img src="https://pbuff-blogs-1257793641.cos.ap-chengdu.myqcloud.com//blogsimage-20260529161556189.png" alt="image-20260529161556189"></p> <p>最后我懵了，SQL没问题、模型没问题、网关没问题，但就是数据有问题&hellip;&hellip;</p> <p>无奈，我将现象和项目信息、执行时间、执行历史给DeepSeek-v4-pro（我还是担心模型问题，换了一个），让其帮我分析问题的根本原因是什么，经过长达15分析各种二分法、模型关联、看日志、看执行记录，最终得出结论：两个定时任务冲突了（定时任务导出还没完全导出数据的时候，AI自动分析就开始了（AI自动分析的时候日志还没有完全导入进来，导致数据量远少于我后来手动执行SQL））</p> <p><img src="https://pbuff-blogs-1257793641.cos.ap-chengdu.myqcloud.com//blogsimage-20260529161921023.png" alt="image-20260529161921023"></p> <p><img src="https://pbuff-blogs-1257793641.cos.ap-chengdu.myqcloud.com//blogsimage-20260529161958312.png" alt="image-20260529161958312"></p> <h1 id="回顾">回顾</h1> <p>说来也巧，前一天晚上的时候我是验证过AI查询的数据量和手动执行SQL的数据量是不是一致的，那时候确实是一致（这也是导致我一开始怀疑是我切换模型的原因）。实际上应该是夜间Clickhouse查询压力小，查询速度快，定时任务很快就完成了，AI分析开始的时候日志已经导入完成了。但到了白天，大家都在Clickhouse查询，导致查询负载大，查询速度慢，定时任务执行的周期就变长了，AI分析的时候日志量并不完整。</p> <p>最后重新修改了执行逻辑，执行分析前先查询实际数据范围：</p> <ol> <li>查询 ClickHouse 获取 max(start_datetime)</li> <li>传入 compute_analysis_window 作为 window_end</li> <li>AI 分析的时间窗口精确匹配实际可用数据</li> </ol>