Три маленькие модели и один судья

В начале 2026 года в Trend Radar я упёрся в проблему: автоматические отчёты, собранные из сотен источников, выглядели красиво, но при ближайшем рассмотрении напоминали галлюцинацию. Система собирала сигналы, но не умела их «сшивать». Я тратил часы на ручную чистку дублей, пока не понял, что бороться надо не с качеством генерации, а с логикой приёма данных.

Началось всё с квартальных отчётов. Q1-обзор Радара собирается из сотен сигналов за три месяца, и первые сборки показали неприятное: чем больше источников, тем увереннее звучит текст — и тем труднее поймать, где он опирается на один слабый пост, пересказанный пятью сайтами. Качество сводного отчёта упиралось не в модель, а в гигиену данных под ним.

Весной 2026-го я переписал пайплайн верификации: битые ссылки, дубли под разными датами и — главное — жёсткие полы вместо предупреждений. Полный разбор того инцидента — в кейсе про конвейер, который тихо умирал; здесь важен вывод: системе, которой можно верить, сначала нужна гигиена данных. С тех пор пайплайн молчит, если не уверен.

Фиаско 60/100 и рождение Anti-Drift Review

Когда я собирал Anti-Drift Review, я был уверен в успехе. Идея проста: несколько независимых моделей рецензируют документ, затем мы сводим расхождения и нормализуем формулировки. После первого прогона стало ясно, что система «сломана» — ни один документ не набрал выше 60 баллов из 100. Я искал баги в промптах и архитектуре, пока не осознал очевидное: документы пишут люди в режиме дедлайна, и 60/100 — это не провал ИИ, а реальное состояние корпоративной документации.

Ценность инструмента оказалась не в выставлении оценки, а в составлении карты «минных полей». Система теперь помечает, где именно она сомневается, а не делает вид, что знает истину. Я перестал выжимать из модели «идеальный вердикт» и стал использовать её как сканер расхождений, который подсвечивает места, требующие человеческого внимания.

Локальный консилиум: архитектура недоверия

К июлю 2026 года стало понятно, что отправлять чувствительные данные во внешние API — это стратегия не для всех. Я собрал контур, где данные не покидают периметр, используя панель из трёх малых моделей разных семейств: qwen3:4b, gemma3:4b и phi4-mini. Они занимают около 8 ГБ видеопамяти в 4-битной квантизации (без учёта контекста) и помещаются на одну потребительскую карту.

Так выглядит единица результата — не «оценка документа», а конкретная пара с цитатами обеих сторон:

Роль судьи выполняет модель покрупнее, gpt-oss:20b, которая работает только с результатами «тройки». Каждый вердикт обязан опираться на дословную цитату из текста, иначе он отбрасывается. На знакомом эталоне я получил 10/10 без ложных срабатываний, а на 42 специально спроектированных ловушках — полноту 0,88 при 4 % ложных.

Это научило меня главному: промпт — это тоже модель. Любое изменение в нём проходит через автоматический замер. В один из дней я решил «улучшить» систему, добавив в промпт судьи примеры для точности. Система выглядела безупречно, но автоматический гейт завернул обновление: полнота рухнула с 0,88 до 0,53. Оказалось, модель начала переобучаться на моих примерах и перестала видеть контекст. Разметку эталона, которую делала одна модель, я отдал на аудит модели другого семейства — она нашла три однотипные ошибки направления строгости, которые «коллеги» пропустили. Разнообразие семейств моделей спасает от «туннельного зрения» одной архитектуры.

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

Из того, что сломалось по дороге и осталось в конструкции: судья между прогонами менял мнение на спорных парах — недетерминизм малых моделей, лечится несколькими прогонами и кворумом. А для больших корпусов работает двухступенчатый поиск: сначала кандидаты по смыслу, потом дорогая проверка только по ним — те же находки при 60% проверенных пар.

Про цифры честно: эталон — это 61 размеченная пара «требование ↔ пункт» в шести доменах, от ИБ до пожарной безопасности. Примерно половина — ловушки, собранные по мотивам реальных промахов: пункты, где нормы в разных единицах («не позднее 15 календарных дней» против «в течение 10 рабочих»), где внутренняя норма строже требования — и это не противоречие, где тексты тематически похожи, но регулируют разные предметы. Цифры в тексте выше — замер на первой версии эталона из 42 ловушек: полнота 0,88 при 4 % ложных. С тех пор эталон вырос, и на 61 паре последний замер — полнота 0,84 без единой ложной тревоги: набор стал жёстче, и это честнее. Разметку эталона аудировала модель другого семейства, чем та, что генерировала кейсы.

Где это работает сегодня

Роевая верификация — это не про замену человека, а про экономию его ресурса на чтении мусора. Этот подход применим в нескольких сценариях:

1. Нормативное соответствие. Когда выходит новый приказ, его нужно проверить против сотен внутренних регламентов. Человек пропустит противоречие на 40-й странице; рой снижает эту вероятность кратно и выдаёт готовый список кандидатов на проверку.
2. Подрядная документация. Сверка проекта с фактическим исполнением. Если в документах подрядчика есть расхождение с проектной сметой, система выводит цитаты обоих документов рядом.
3. Финансовый контроль. Автоматическая проверка отчётов аналитиков и агентств перед оплатой. Здесь не ищется «правильный ответ» — ищутся места, где данные не бьются.
4. Приёмка ИИ-контуров. Если компания внедряет свои модели, их нужно проверять по «золотому стандарту». Система выступает как независимый аудитор, который сверяет выводы новой модели с эталонными ответами.

Интеграция выглядит так: документ попадает в контур, панель размечает кандидатов на ошибку, судья фильтрует шум, и эксперт получает на стол короткий список цитат. Это меняет работу с документами: вместо того чтобы читать всё, ты читаешь только то, где ИИ не смог прийти к консенсусу.

Принципы, на которых строится такой контур, — в статье «ИИ-инфра: тренды». В конечном счёте, доверие к автоматизации начинается там, где заканчивается слепая вера в один «умный» ответ. Если система не может доказать свою правоту цитатой, значит, она не работает. Всё остальное — просто шум.