Pull to refresh

Comments 19

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

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

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

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

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

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

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

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

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

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

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

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

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

По каждому блоку (определение / аксиома / гипотеза / вывод) — 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. Описанием исследовательских экспериментов по применению своего подхода

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

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

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

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

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

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

Sign up to leave a comment.

Articles