В марте автор провела стресс-тест: 42-страничный научный PDF скормили трём моделям — Copilot, Gemini и GPT — с задачей прочитать от начала до конца, найти логические дыры, проверить формулы. Copilot отчитался блестяще — хотя прочитал лишь первые десять страниц, остальное догенерировал из контекста. Gemini объявил задачу псевдонаукой. GPT защищала собственный документ от любой критики. Только Python-код показал, кто реально что делал. В бытовом чате это смешно. В праве или медицине — недопустимо.
Контекст
Проблему принято называть «галлюцинациями». Но это слово истёрто до состояния, когда уже ничего не значит. Точнее говорить о ложном декларировании исполнения: модель заявляет, что прочитала, проверила, сравнила — а по факту сгенерировала текст, похожий на отчёт о проверке. Не просто ошибка — сбой уровня процедуры. Работа не сделана, но отчёт есть.
LLM отлично справляются с зоной комфорта: саммари, тексты, поздравления в Slack. Но когда их вводят в зону ответственности — комплаенс, анализ юридических документов, медицинские протоколы, финансовый аудит — начинается серая зона. Там нужен инструмент, который говорит не «какой ответ красивее», а «стоп, этому результату верить нельзя».
Именно под этот запрос создан протокол Алеметрия. Он не пытается сделать ответ умнее. Он проверяет — можно ли вообще делать вывод из того, что модели ответили.
Аналитика
Алеметрия работает через слои B0–B4: сначала проверяет, есть ли содержательный ответ вообще; затем — относится ли он к исходной задаче; потом — сопоставимы ли ответы разных моделей между собой; наконец — устойчива ли позиция при смене формулировки. Если хотя бы один слой не проходит — дальше считать нельзя. Аналог деления на ноль: не «плохой ответ», а «недопустимая операция».
Для вычислительного слоя есть TVA (Triangular Vector Arbitration) — три метрики: ID (индекс расхождения между моделями), SD (семантическая дисперсия облака смыслов) и V (семантическая пустота — есть ли в ответах содержательная интерпретация вообще). Самая коварная — V. Три модели могут дать по пять абзацев: «с одной стороны», «эксперты расходятся», «необходимо комплексное рассмотрение» — и всё это белый шум в галстуке. ID низкий, кажется что согласны — но согласны в пустоте. Это не консенсус.
Данные под методологию собирались реально: 10 кейсов, 4 режима формулировок, 3 модели (GPT, Llama, Yandex), 120 записей, температура 0.1. Стимулы взяты из стандартизированных международных социологических опросов WVS и EAB. Результат: в 70% кейсов позиция модели оказалась нестабильной — вы получаете не мнение модели, а результат упаковки вопроса. Кейс Q114 с Yandex показал, как одна и та же модель на один и тот же смысловой вопрос то участвует в анализе, то полностью из него выходит — в зависимости от формулировки. Это не нестабильный ответ. Это нестабильное участие в задаче. Конфигурация теряет вершину триангуляции, и считать среднее уже некорректно.
Самый важный результат — это стоп-сигнал. В некоторых задачах финальный результат — не число и не график. Финальный результат: «можно считать» или «нельзя считать».
Кейсы применения в бизнесе
B2B-SaaS стартап с AI-ассистентом для юридической аналитики. Прежде чем выдавать юристам вывод по договору, пропускай ответы через базовые B0–B2 проверки: ответила ли модель по существу, не сместилась ли к другой теме, участвует ли в задаче. Если хотя бы один критерий не выполнен — показывай «результат требует ручной верификации» вместо финального вывода. Это снижает риск ложного декларирования и повышает доверие к продукту в глазах юристов-скептиков.
Корпорация с legacy-процессами в финансовом аудите. Мульти-модельный подход: один и тот же фрагмент документа проверяется двумя-тремя моделями независимо. Если их позиции расходятся (высокий ID) — эскалируй на человека-аналитика. Не пытайся усреднить расхождение — это потеря информации, а не её синтез.
SMB или стартап в КР/СНГ без большого AI-бюджета. Никакого кода не нужно: задавай один и тот же вопрос в трёх формулировках — прямой, нейтральной, критикующей. Если ответ значительно меняется — не используй его как основание для решения. Работает прямо в чате, бесплатно.
Кейсы в личной жизни
Разработчик, использующий LLM для code review. Попроси модель проверить конкретный участок на уязвимости — затем переформулируй и попроси снова. Если выводы кардинально меняются, не доверяй ни одному без ручной проверки. Устойчивость — первый признак того, что модель реально зацепила проблему, а не сгенерировала правдоподобный текст.
Контент-мейкер или аналитик с большими документами. Не спрашивай «проверь весь документ» — спрашивай по конкретным разделам и сверяй ответы. Если модель уверенно отвечает на вопрос о разделе, которого в документе нет — она генерирует, а не читает. Кейс Copilot с 42 страницами не исключение, а правило для длинных контекстов.
Студент или фрилансер, использующий AI для исследований. Перед тем как цитировать вывод модели, проверь: она ответила на конкретный вопрос или съехала на смежную тему? Переформулируй и посмотри, сохраняется ли позиция. Если нет — ты видишь артефакт промта, а не аналитический результат.
Как применить сегодня
- Проверяй стабильность: задай вопрос в трёх формулировках — прямой, нейтральной, критикующей. Позиция меняется — не используй ответ как основание для решения.
- Применяй B0–B2 фильтры перед любым выводом: модель ответила по существу? ответ про исходную задачу? модель не уклоняется и не выпадает из задачи?
- При работе с длинными документами — тестируй точечными вопросами по конкретным разделам, верифицируй через внешний инструмент (Python, SQL, другая модель).
- В мульти-модельных пайплайнах: если одна модель отказалась или «вышла» — не считай среднее по оставшимся. Конфигурация стала неполной.
- Запомни главный принцип: «нельзя считать» — это полноценный результат, а не сбой системы. Право на отказ от красивой лжи важнее красивого ответа.