在使用AI大模型进行日志诊断时，如何有效管理上下文窗口是一个关键挑战。最近，一个名为HiyokoLogcat的项目通过实际测试，分享了向Gemini模型发送日志行进行故障诊断的最佳实践，旨在平衡上下文丰富性与令牌限制、响应速度及信噪比。
在初期尝试中，项目团队简单地抓取了最近的500行日志发送给Gemini 1.5 Flash。尽管Gemini拥有庞大的上下文窗口，但500行冗长的logcat日志产生了大量的令牌，导致响应延迟显著增加，并且模型有时会过度关注无关噪声而非实际的错误信息。
经过多轮测试，HiyokoLogcat发现了一个“甜点区”：即围绕目标错误前后各发送50行日志，总计约100行。这种方法能够：
- 捕获导致崩溃的事件序列。
- 记录任何后续错误和恢复尝试。
这种窗口大小通常产生3,000至6,000个令牌，能够带来快速响应和相关的诊断结果。代码实现上，可以通过一个函数（如`get_diagnosis_context`）来截取错误索引前后指定行数的上下文，并将日志格式化为更简洁的字符串。
然而，某些复杂情况，例如持续数分钟的内存泄漏或涉及长时间设置链的线程问题，需要更宽泛的上下文。为此，HiyokoLogcat引入了“深度诊断”模式，发送围绕错误点前后各200行日志。默认采用快速诊断（±50行），深度诊断则作为可选功能，满足特定需求。
除了上下文窗口大小，日志的格式也至关重要。原始的logcat输出通常包含大量重复结构。在发送给模型之前对其进行重新格式化，可以显著减少令牌数量，同时不损失任何关键信息。例如，将冗长的原始日志条目（如`04-20 10:23:45.123 1234 5678 E AndroidRuntime: FATAL EXCEPTION: main`）压缩成更简洁的格式（如`[10:23:45] E/AndroidRuntime: FATAL EXCEPTION: main`），在处理大量日志时能有效节省令牌。
最终，HiyokoLogcat通过结合±50行的上下文、重新格式化日志以及对PII（个人身份信息）进行脱敏处理，使得Gemini能够在2-3秒内（使用免费层级）提供具体、可操作的诊断结果。这一配置已被集成到HiyokoLogcat项目中，并已上线。