Обновить

Цифровой аудит против галлюцинаций по ГОСТу. Как понять, когда ответу ИИ нельзя верить?

Уровень сложностиСредний
Время на прочтение8 мин
Охват и читатели11K
Всего голосов 4: ↑3 и ↓1+2
Комментарии28

Комментарии 28

Сам принцип работы нейросетей подразумевает, что они будут давать наиболее удобный, а не наиболее честный ответ. Буквально “предсказатель наиболее вероятного следующего слова”.

Поэтому к ИИ всегда стоит относиться критически и всегда все по 7 раз уточнять и переспрашивать. И конечно сверяться с другими источниками.

LLM очень хорошо умеют создавать ощущение, что мыслительный процесс уже состоялся за тебя)

У меня был забавный стресс-тест, где 4 нейронки за 20 минут решили задачу Лежандра, которую математики уже 200 лет решить не могут😂. Это как раз хорошо показывает проблему. Они способны быстро собрать убедительное рассуждение, и пользователь ведь может поверить?

Не совсем так. Нейронки по сути дают наиболее удовлетворяющий человека ответ - это часть обучения с механизмами поощрения. Очевидно, что наиболее честный и удовлетворяющий/полезный - не одно и тоже.
Зачастую честный ответ не несет пользы и пользователь остается недовольным взаимодействием с llm
Поэтому, как ни странно, то, что мы наблюдаем это некая попытка найти баланс между пользой и фактологичностью/чесностью.

По открытым публикациям история с Palantir и ракетным ударом по школе в Минабе как раз попадает в слабое место ИИ-систем, где они оптимизированы под полезный ответ.

Если версия с устаревшими данными верна, то информация о том, что в школе в Минабе раньше находилась база КСИР, могла пройти по цепочке принятия решений как актуальная. В таких случаях ошибка уже не остаётся ошибкой ответа, а становится физическим последствием.

Я думала об этой ситуации. Скорее всего я бы ввела еще отдельный слой валидации вывода.

Триангуляцию минимум 3 независимых моделей, сверку координат и временной актуальности данных; проверку объекта совпадений анализа; поиск конфликтных источников; проверку достраивания данных как подтвержденных; сигнал, если вывод выглядит уверенным при слабом основании.

Ну это мои размышления, не претендующие на истину, что в таких ИИ нужен отдельный слой проверок допустимости вывода, а не только поиск убедительного ответа

Методы дистилляции - штука не новая. Спрошу здесь, раз уж пост профильный - как считаете, у агента для проверки документов без ошибок - есть коммерческий потенциал?

Я думаю, что есть. Мне кажется, что польза не в идеально проверяющем, а в системе, которая помогает отделять содержательную проверку, имитацию проверки, отказ и ситуации, где вывод вообще нельзя считать надежным. Пользователь этого сейчас часто не понимает, а компании могут нести репутационные и управленческие риски

Не хочется вот так разочаровывать... И все же

А) Модель вообще ответила или аккуратно ушла от ответа, отказалась или налила «воды»

Б) Ответ действительно про тот же вопрос или модель сместилась в сторону и рассуждает уже о другом?

В) Ответ устойчив?

Главное заблуждение, что "модель ответила". Вспоминаем, что модель предсказывает следующий токен. И, конкретно в этом приере, вся проблема сокрыта в том, какую задачу ей поставили. А точнее в том, что задачу ей, по факту, не поставили.

«прочитай документ от начала и до конца, найди логические дыры, проверь корректность отображения формул и переменных»

Эта задача изначально составлена не как «делегирование работы» (что сделать, как читать, как проверять), а как «делегирование ответственности» (хочу красиво). Ты ждешь от ЛЛМ не исполнительности (что она, в целом, умеет), а разумности и внимательности, а этих свойств в ней не только не заложено, даже все попытки провайдеров надрессировать модели на эти качества постоянно терпят фиаско.

Может ли ЛЛМ в действтительности "вычитать и выловить ошибки"? Да, но только если ты предварительно ей классифицируешь, какие ошибки ищешь и детально опишешь, как их выловить, а потом еще не забудешь напоминать правила после каждого проверенно подраздела документа и внимательно будешь вычитывать все, что она тебе лишнего пришлет.

Например, вот прям сейчас у меня ЛЛМ вычитывает и находит несоответствия в онтологии. И вот такой промпт у нее на входе:

По каждому блоку (определение / аксиома / гипотеза / вывод) — 4 параметра:

  1. Правильно ли выбран тип записи?

  2. Правильно ли сформулирована запись?

  3. Правильно ли указаны ссылки?

  4. Полнота ссылок — все ли указаны, нет ли лишних?

Общая рамка:

  • Последовательность внутри главы строгая: определения → аксиомы → гипотезы → выводы → резюме.

  • Определения не ссылаются на аксиомы/гипотезы/выводы текущей главы — самостоятельны по смыслу.

  • Аксиомы — фундаментальные точки опоры, каждая обоснована во внешнем домене и не требует доказательств в текущей работе (физика, биология, теория систем и т.д.).

  • Гипотезы — наблюдения текущей сборки, незавершённые по своей природе, могут быть пересмотрены.

  • Выводы — структурные узлы; не расширяют смысл предположениями, только перемножают введённое, опираются на аксиомы / гипотезы / прошлые выводы.

  • Ссылки только на введённое выше по тексту. Никаких forward-ссылок ни внутри главы, ни на будущие главы.

Порядок работы:

  1. Прочитать главу целиком.

  2. Пройти по каждому блоку, заполнить таблицу с оценками корректности. Отметить проблемы; 

  3. Структурные нарушения (forward-ссылки, нарушение порядка) — маркировать как критические.

P.S. Бородатый анекдот как раз в тему:

— Вот за это я и не люблю кошек.
— Ты просто не умеешь их готовить!

Судя по форматированию у вас промпт тоже написан с помощью LLM, или как минимум постобработан.

Отсюда и ожидания, что эти требования сами собой "родятся" при запросе "сделай хорошо". Если моделька может написать требования, а потом выполнить все по требованиям, то почему бы не сделать это за раз?

В данном случае требования к методу обработки уже детерменированы, не меняются от запуска к запуску и их формулирование не дается на откуп модели в инференсе.

То, что промпт написан с применением LLM, в данном случае не играет сильной роли. Это малая автоматизация, почему бы и нет, если результат проверен. Важнее то, что на входе есть стабильный фиксированный перечень требований.

Разумеется, это не даёт 101% гарантии, но минимум иллюзия управляемости уже есть

этот промпт я добыл из памяти внутри ллм. составлял я сам его, но запомнила и сейчас "вспомнила" конечно ЛЛМ. И потому он пришел к вам в таком виде. я же его не у себя в голове держу, его ЛЛМ исполняет

Каждую формулировку своего запроса к ЛЛМ я формулировал и объяснял отдельно, обосновывал и что и как делать. Сейчас это уже рабочий вариант, так как в истории нашего диалога есть 100-500 примеров, как она отработала с этим промптом. И все равно его нужно обновлять ей (заставлять вспоминать и выписывать) перед каждой новой главой, иначе она сбоит и начинает пропускать виды ошибок, которые в предыдущей главе не встречались.


отдельно про ожидания

Отсюда и ожидания, что эти требования сами собой "родятся" при запросе "сделай хорошо". Если моделька может написать требования, а потом выполнить все по требованиям, то почему бы не сделать это за раз?

У меня абсолютно нет таких ожиданий. Составить критерии проверки сейчас может только человек. Полные, обращу внимания. Набросать вариантов проверок может ЛЛМ, но это будут "средние по больнице".

Если же хочется добыть из ЛЛМ адекватные критерии проверки, то необходимо сначала с ней вывести "цель документа", далее разложить ее на "структуру документа" и "требования к повествованию", далее каждое требование инвертировать в набор критериев, далее посмотреть на структуру и составить потенциальный список проблем, далее все это спроецировать на особенности мышления ЛЛМ, и отсюда собрать список проверок. После этот список опять спроецировать на мышление ЛЛМ и составить методику проверки. Это многосоставной процесс, и собирать текую методику силами ЛЛМ замучаешься. Мне проще это сделать самостоятельно в голове, выдавая на ЛЛМ по несколько критериев за раз, причем обязательно однотипных по природе и способу вычитки.

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

не давай ей простора на собственную интерпретацию задачи и будешь получать желанный результат =)

Всё по полочкам! Этому надо учиться! Молодец!

Согласен, что с И И надо точно работать. Формулировки в статье про партбилет из СССР не уместны.

Ещё очень важно кто создает ИИ и кто курирует политику у него. Сам ИИ на вопросы почему разница глубоких смыслов ответит, что разное мировоззрение.

Спасибо😊.  Рамка, в которой обучалась модель важна не меньше ее «интеллекта»). И на демонстрационных кейсах это особенно видно. Они действительно могут интерпретировать по разному один и тот же вопрос. Внешне вроде согласованный, а внутри они пришли к ответу разными путями. А если еще глубже копать в пайплайн обучения и разметки данных, там вообще отдельный мир. Но туда глубоко я не копала😅 пока

Copilot - не модель, и уж тем более не “топовая”. Автору бы хоть ознакомиться с инструментами, что он применяет.

Я понимаю, что это AI инструмент поверх модели, формулировка была грубой, замечание принимается. Но я смотрю с позиции социолога, работаю именно с конечным пользовательским продуктом. Меня интересует именно опыт пользователя, что происходит, когда человек отдает документ в такой инструмент и какой результат получает

трём топовым моделям — Copilot, Gemini и GPT.

Как правильно сказали выше, copilot не модель.

И не бывает просто «топовой модели GPT», GPT-5.5 (Instant, Thinking) и GPT-5.5 Pro радикально отличаются по качеству работы в сложных задачах. Вы про какую?

Алеметрия

Такого слова нет. Если что-то придумываете, объясняйте этимологию, а то сейчас звучит как «сепульки».

Алеметрия, это авторский термин, Вы правы, надо было в статье ввести термин раньше. Этимологически это алетейя» / ἀλήθεια, то есть раскрытие или несокрытость. , и «метрия» как измерение. Замечание принято😊

Когда в чат зашел Python, то сразу стало ясно кто филонил, кто истеричка, а кто графоманка. Против кода магия вранья бессильна.

О чем речь вообще? Для чего питон?

Python нужен был для проверки фактического выполнения операции, например прочитала ли модель действительно страницы, извлекла ли формулы. Код не решает интерпретационную проблему, но вскрывает различие между заявленным и пррверяемым результатом.

Вот тут начинается веселье с привкусом производственного аудита

Это очень плохой текст, тк ИИ придумывает новые выражения на русском, которые не имеют никакого смысла, а точнее выглядят как нелепый, аляповатый, абсурдный стиль.

В общем вы очень спешите, вместо того, что сделать серию публикаций с:

  1. Постановкой проблемы

  2. Обзором вариантов решений

  3. Обзором источников

  4. Описанием принципов своего подхода

  5. Описанием исследовательских экспериментов по применению своего подхода

вы сразу лепите сумбурную статью-кадавр, как будто у вас «ограничение на число токенов на Хабре».

Главное заблуждение, что "модель ответила". Вспоминаем, что модель предсказывает следующий токен. И, конкретно в этом примере, вся проблема сокрыта в том, какую задачу ей поставили. А точнее в том, что задачу ей, по факту, не поставили.

Золотые слова, но людей, понимающих их смысл как-то исчезающе мало, судя по текстам статей, заполонивших Хабр, количеству вайб-кодинга, попыток ревью силами моделей и разных комментариев.

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

В социологии похожая давняя проблема, формулировка вопроса может менять получаемый ответ, и это очень отражается на результатах исследования. Но алеметрия не изучает «вопросы», она исследует можно ли на основании полученного ответа делать вывод или принимать решение.

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

Как вы это реализуете? Примеры кода по текущему проекту будут? Потому что препринт открылся один раз, не скачался и совсем замолчал сайт

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

Но это уже следующий этап. Сейчас проект скорее находится в исследовательской стадии. Надо проверить переносимость метода на другие дисциплины, не только социологию. Отдельно хочу протестировать алеметрию как мета метод для оценки существующих подходов к аудиту ИИ. Например «ИИ как судья». Примеры кода буду выкладывать по мере развития проекта. Вот ссылка. https://zenodo.org/records/19674164

Мы можем дать вам полностью детерминистический, воспроизводимый и масштабируемый evaluation framework для Алеметрии.

nano-vm берёт на себя всю оркестрацию, трассировку, параллелизм, A/B-тестирование и мокинг, а вы сосредотачиваетесь на научной части (кодбук, правила B1, интерпретация результатов).

Это позволит вам:

Значительно увеличить размер корпуса (с 10 кейсов до сотен).

Проводить систематические эксперименты по снижению зависимости от судьи.

Публиковать не только методику, но и полностью воспроизводимые трейсы экспериментов.

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации