Если задуматься, то в задачах с ллмками самое это понять что мы вообще хотим ей скормить и какого результата планируем добиться.
Сегодня хочу немного поразгонять об этом в формате заметки. Всплыла задачка в разговоре со знакомым еще из моего инженерного прошлого. Он спросил, сталкивался ли я с анализом больших логов, в частности сетевых, через локальную модель и можно ли там придумать какое-то более-менее универсальное решение.

Сценарий понятный: есть чат-бот или какая-то морда, пользователь загружает лог, а дальше хочет получить человеческий ответ. Что нашли, какие ошибки повторяются, на какой класс инцидента это похоже и куда в первую очередь смотреть.

На первый взгляд задача хорошо ложится на LLM. Модель большая, железо локальное, данные никуда не уходят, да и контекста должно по идее хватить. Но по факту команда уперлась во вполне очевидные болячки: логи прям Большие, Open WebUI не всегда нормально работает с крупными файлами (чанкинг тот еще квест), а контекст у модели всё равно конечный. И оказывается, что его может не хватить)

Команда уже пошла по довольно логичному пути: перед моделью стоит пайплайн, который пытается сократить лог. Берет нужный период, выкидывает старое, схлопывает одинаковые строки, оставляет то, что кажется важным. Нормальный MVP, который где-то свернул не туда. А свернула его, кажется, сама идея “ужать лог до промпта”.
В логах повторы могут быть не мусором. Место появления ошибки может показать закономерность или ранний сигнал. И там еще куча разных неочевидных edge cases, о которых привычно думать продуктовой команде, но не всегда привычно думать чисто технической.

Поэтому тут напрашивается не просто сокращение или парсинг, а нормальная предварительная обработка данных. Парсинг, регулярки, группировка похожих ошибок, счетчики, скоринг аномалий, поисковый слой или временный индекс по файлу.
Выглядит, конечно, менее волшебно, чем “я кинул файлик в ллмку, и она всё порешала”. Зато уже больше похоже на место, где можно построить продуктовую логику с контролем над тем, что именно и как мы обнаружим.

После этого, уже подготовленный слой данных можно отдавать в модель, чтобы она собрала из фактов нормальный ответ для DevOps/SRE или саппорта. И не пыталась героически прочитать весь файл, а объясняла то, что до нее уже нашли более подходящие инструменты.

Если пытаться прийти к какому-то выводу, то мой тейк в том, что слишком часто сейчас хочется всё порешать за счет более сильной модели, большего контекста или более хитрого промпта. А по факту оказывается, что ИИ такой же инструмент, и не на всех этапах он самый лучший и применимый.
Сильная модель тут всё еще естественно полезна. Просто иногда ее лучше ставить не в начало пайплайна, а ближе к концу, где уже есть факты, статистика и несколько хороших примеров. Тогда она занимается не угадыванием смысла в огромном потоке... технического шума, а нормальной интерпретацией уже собранной картины.