В РГС локальные LLM сократили разбор 500 задач с пяти рабочих дней до двух

Перед каждым циклом планирования в РГС команды разработки приносят сотни задач, и каждую нужно оценить по нескольким критериям приоритизации. Один из них — ИТ-комплаенс: помогает ли реализация задачи соблюдать требования законодательства. Руководитель направления ИТ-комплаенса Анастасия рассказала на Хабре, как сократила разбор около 500 задач с пяти рабочих дней до двух. Бюджета на разработку у неё не было, программировать она не умеет: весь конвейер собран на бесплатных инструментах и работает на ноутбуке.

Почему фильтр по ключевым словам не подошёл

В пилоте участвовали два «поезда», то есть два крупных направления разработки. Уже первый цикл дал около 500 задач, и их разбор занял неделю единственного эксперта. Всё это время стояла работа, ради которой комплаенс существует: анализ новых требований и сопровождение сложных проектов. Подключение остальных поездов съело бы большую часть квартала, а расширять команду под пиковую нагрузку было нельзя.

Поиск по словам не работал: у разных команд формулировки отличаются, а нужно оценивать смысл. Поэтому Анастасия решила проверить гипотезу максимально дёшево. Она сделала обезличенную выгрузку задач и отдала её нескольким внешним моделям вместе с инструкцией по критериям. После нескольких итераций промпта результат стабилизировался, но совпадение с экспертными оценками составило около 60%, причём ошибки в основном шли в сторону завышения. Для старта этого хватило: модель-перестраховщик надёжно отсеивает то, что эксперту смотреть не нужно.

Локальная сборка: n8n, Ollama и база проверенных оценок

У первого варианта было три слабых места: ручная подготовка выгрузок, потеря смысла при обезличивании и зависимость от внешних сервисов, которые в России могут перестать работать. Корпоративное решение сразу не получилось, и Анастасия выбрала локальную модель. Данные не покидают компьютер, а внешние сервисы не нужны. Платить приходится ограничениями ноутбука: задачи подаются порциями, а слишком тяжёлые модели вешали машину намертво.

Оркестратором стал n8n, визуальный конструктор процессов. Модели запускались через LM Studio и Ollama, в итоге остановились на Ollama. Конвейер выглядит так: выгрузка задач, очистка текста от технического мусора, передача модели вместе с инструкцией, ответ в строгом формате (уровень по шкале и короткое обоснование), сохранение результата.

Главный элемент — база уже проверенных оценок с RAG. Получив задачу, модель находит похожие, которые оценил эксперт, и опирается на них. Без этой базы первые сборки показывали всего 20% точности. После доработки подбора примеров, промпта и набора моделей (Qwen и GPT-oss) сборка достигла 70–80% на тестовой выборке и обрабатывала 500 задач примерно за 12 часов. Это около 1,5 минуты на задачу.

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

От 55–60% на живом потоке до 78–82%

Тестовая выборка оказалась оптимистичной. На реальных задачах первая хорошая сборка давала лишь 55–60%: в живом потоке больше новых формулировок и систем, а часть задач приходит от поездов, которые только подключаются к приоритизации. Дальше Анастасия пробовала несколько оценок от разных моделей или от одной модели с разными параметрами, дополнительные знания и обогащённый контекст, в том числе через MCP. Критерий отбора был простым: если точность варианта проседала при подключении новых поездов, его отбрасывали.

Выжившие сборки работают дольше стартовой, 12–24 часа на 500 задач, но дают 78–82% на реальных данных, а ошибки завышения и занижения теперь уравновешены. Вместо фильтра для эксперта получился алгоритм, который сам проставляет значения, а эксперт проверяет их по необходимости. Логика экономики здесь простая: время компьютера дешевле времени эксперта, и чем точнее алгоритм, тем меньше ручной проверки.

Процесс изменился и по охвату. Раньше вручную оценивались только новые задачи, а изменённые повторно не проверялись из-за нехватки времени. Теперь алгоритм сам выгружает новые задачи и задачи с изменённым описанием до начала реализации, проставляет оценки, отдаёт файл на проверку и записывает значение критерия в поле для расчёта приоритета. Записать можно сразу или после проверки. Вместо двух поездов процесс обслуживает девять.

Ограничения и что дальше

У решения есть слабые места, и автор их называет. Оно привязано к одному ноутбуку и одному эксперту, а 80% точности хороши для локальной модели, но не отменяют выборочной проверки. Анастасия собирается периодически перепроверять, не снижается ли точность. Корпоративный экземпляр алгоритма уже работает в ограниченном режиме и даёт сопоставимую точность в шесть раз быстрее. По оценке Анастасии, остаётся снять ограничения.

Для практиков вывод такой. Схема «прочитать, сопоставить с правилами, оценить» подходит многим операционным процессам. Рабочий минимум для неё: накопленная база экспертных оценок для RAG, метрики с учётом направления ошибок и тестирование на живом потоке, а не только на выборке. В РГС похожий процесс уже запускается в тестовом режиме. Роль эксперта при этом смещается: он управляет процессом и принимает решения там, где они действительно нужны.