Обновить
16K+
10
Андрей@aak204

Пользователь

14
Рейтинг
5
Подписчики
Отправить сообщение

Я проверял в отдельном тесте (в исходниках это режим prompt_debias_baseline).

Добавил соло-агенту жесткий промпт: "Обязательно сомневайся и ищи опровержения". И это реально сработало!

Смотрите на цифры (Байесовская ошибка):

  • Обычный агент: 1.47

  • Агент, которого заставили сомневаться: 0.67 (в 2 раза лучше)

  • Слепой судья: 0.09 (в 15 раз лучше)

То есть метод 100% работает. Но есть нюанс. Даже когда мы заставляем агента сомневаться, он всё равно помнит свои прошлые выводы. Он начинает генерировать сомнения "для галочки", чтобы угодить промпту, но в итоге часто всё равно притягивает ответ к изначальной гипотезе.

Вывод: просить сомневаться - это отличный «пластырь», если у вас всего один агент.

Спасибо за развернутый комментарий и отдельный респект за то, что заглянули в исходники! Вы поднимаете абсолютно правильные вопросы методологии. Давайте проясню моменты, которые в статье могли показаться мутными:

1. Про сравнение «теплого с мягким» (разная логика vs размышления)

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

В разделе «Инсайт 2» есть график Thinking vs Non-Thinking, на котором четко видно:

  • Мы взяли same_model_locked_agent и запустили его с размышлениями (регрет 0.15) и БЕЗ размышлений (регрет улетел в 2.26).

  • Затем мы взяли blind_checker и тоже запустили его с размышлениями (регрет 0.16) и БЕЗ размышлений (регрет 0.10).

    То есть мы сравнивали агентов самих с собой. Вывод именно в том, что включение CoT помогает генератору, но вредит верификатору.

2. Про кросс-модельный тест и GPT-5.4

Результаты скрипта run_cross_model_compact.py как раз подробно описаны в предпоследнем разделе статьи - «Фронтир-модели не спасают». Там же есть график Compact Cross-Model Regret. Мы протестировали GPT-5.4 в режимах thinking и non-thinking (это gpt 5.3 instant так как 5.4 без ризонинга нет) и получили ровно тот же паттерн удваивания ошибки при включении размышлений. Про Gemini 3.1 Pro в статье не упоминали, так как на момент тестов ее strict-json endpoint в OpenRouter работал нестабильно (падает с ошибкой схемы при отключении reasoning), поэтому в финальный чарт пошли только модели OpenAI.

3. Про дисперсию, рандом и количество запусков

Вы абсолютно правы про влияние temperature, но здесь архитектура стенда страхует от сильного разброса:

  • Во-первых, сама среда (ответы тулзов и улики) полностью детерминирована.

  • Во-вторых, режим non-thinking запускается с temperature = 0.0, то есть он детерминирован на стороне генерации.

  • В-третьих, R_mean (Байесовский регрет) - это уже усредненная метрика. Стенд прогоняет агента не через одну задачу, а через набор эпизодов (в шоукейсе это 5 прогонов, в полном frozen_harness_v1 - прогон по всему корпусу событий). Мы усредняем ошибку распределения вероятностей на всем датасете, что сглаживает локальные флуктуации от temperature = 0.6 в режиме thinking.

Спасибо за отличный комм! Вы ударили в самую точку. Именно классическая теория синтеза надежных систем из ненадежных элементов стала для нас главным ориентиром.

Ваша «новая задачка» уже в активной разработке у меня :) Мы собрали измерительный стенд и прямо сейчас краш-тестируем разные топологии (Star, Tree, Chain) под атаками на фронтир-моделях. Могу дать небольшой спойлер: результаты оказались весьма контринтуитивными, особенно когда мы включили моделям internal reasoning. Плоские графы рассыпаются совсем не так, как ожидалось. Будет 2 часть и обновленный репо!

Я выше писал, что всё через vllm и докер было запущено. Насчёт Тессеракта: возьмите большую таблицу и текст и посмотрите, что вернёт Тессеракт и в каком формате, а также что вернёт PaddleVL.

Время покажет. На таблицах paddle, всё остальное — VL-модели какие-то, с хорошими промтами. Если задача чисто OCR без проверки и всего остального, можно и что-то попроще. Qwen8b VL отлично справлялся.

Тестировали, конечно. Просто в данной статье это не было указано :)

Да, знаем об этом решении, но нам нужны были решения с открытым исходным кодом)

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

Это да, но мощности были ограничены на нашей серверной машине, и не все могут запустить 235 кВ локально. Тут рассмотрены модели, которые используются у нас.

Верно, это был инференс, все модели были на vLLM развёрнуты)

Я думаю, что qwen3 VL большой, например, 235Б, либо же, если касаться только таблиц, paddle VL умеет их отлично распознавать. Там есть настройки, чтобы он понимал ориентацию их, да и вообще довольно гибок в этом плане.

Я думаю, либо лучшие модели, которые сейчас есть, как, например, Квен 235Б или Gemini. Ну, либо какие-то коммерческие решения.

Сейчас вышла версия GGUF формата для квена, поэтому да, может. Мы запускали всё на ГПУ. У нас серверная машина, 3xA4000, 256 ОЗУ плюс Xeon. Высокая скорость у нас - это меньше секунды на изображение, квенчик сильно дольше, лайтоср из-за этого выигрывает, конечно.

Хорошее уточнение ! Обязательно его рассмотрим в будущем)

Информация

В рейтинге
642-й
Зарегистрирован
Активность

Специализация

ML разработчик
Средний
Git
SQL
PostgreSQL
Docker
Python
ООП
Английский язык
C++
Visual Studio