Как дообучают без разметки и почему это важно для AI-инструментов
В свежей работе показали подход Cross-Model Entropy, или CME — схему награды для дообучения модели без ручной разметки. Идея простая: ответ одной модели оценивает другая, более «строгая» модель-верификатор. На выходе получается сигнал, который можно встроить в RL-посттренинг, не переписывая сам цикл обучения.
Авторы протестировали метод на задачах открытых инструкций и прогнали несколько семейств моделей: Qwen, Llama, Gemma и OLMo. На сравнении «один на один» против базовой версии выигрыш по tie-adjusted win rate оказался в диапазоне от 52,5% до 71,4%. Для области, где качество ответа часто измеряется не абсолютной метрикой, а предпочтением судьи, это заметный разрыв.
Почему это интересно не только ML-командам, но и тем, кто работает с no-code и MarTech-инструментами? Потому что такие схемы дообучения постепенно влияют на то, как ведут себя AI-ассистенты, поисковые ответы и встроенные помощники в продуктах. Один и тот же запрос в разных системах может давать разный результат не только из-за промпта, но и из-за того, как модель была посттренирована.
Для тех, кто строит процессы на базе AI-сервисов, это важный сигнал: качество ответа — это уже не просто вопрос интерфейса или промпт-шаблона. За ним всё чаще стоит архитектура дообучения, которая влияет на стабильность, полезность и предсказуемость результата.
В свежей работе показали подход Cross-Model Entropy, или CME — схему награды для дообучения модели без ручной разметки. Идея простая: ответ одной модели оценивает другая, более «строгая» модель-верификатор. На выходе получается сигнал, который можно встроить в RL-посттренинг, не переписывая сам цикл обучения.
Авторы протестировали метод на задачах открытых инструкций и прогнали несколько семейств моделей: Qwen, Llama, Gemma и OLMo. На сравнении «один на один» против базовой версии выигрыш по tie-adjusted win rate оказался в диапазоне от 52,5% до 71,4%. Для области, где качество ответа часто измеряется не абсолютной метрикой, а предпочтением судьи, это заметный разрыв.
Почему это интересно не только ML-командам, но и тем, кто работает с no-code и MarTech-инструментами? Потому что такие схемы дообучения постепенно влияют на то, как ведут себя AI-ассистенты, поисковые ответы и встроенные помощники в продуктах. Один и тот же запрос в разных системах может давать разный результат не только из-за промпта, но и из-за того, как модель была посттренирована.
Для тех, кто строит процессы на базе AI-сервисов, это важный сигнал: качество ответа — это уже не просто вопрос интерфейса или промпт-шаблона. За ним всё чаще стоит архитектура дообучения, которая влияет на стабильность, полезность и предсказуемость результата.
Как снижать «галлюцинации» в AI-генерации: не только промптом, но и проверкой фактов
В arXiv вышла работа про клиническое суммаризирование: Hallucination Detection-Guided Preference Optimization for Clinical Summarization. Суть не в медицине как таковой, а в подходе к качеству текста.
Авторы предложили два уровня контроля. Первый — во время генерации модель не просто пишет сводку, а получает сигнал от детектора фактических ошибок и по ходу правит проблемные места. Второй — такие цепочки правок превращают в пары предпочтений для дообучения, чтобы модель чаще выбирала более точные формулировки.
На тестах с Llama-3.1-8B-Instruct это дало заметный эффект: один вариант сократил галлюцинации на 24%, другой — на 48%. При этом текст не просел по читабельности, связности и релевантности, а качество подтверждали и эксперты, и LLM-Jury.
Почему это важно для no-code ops и маркетинга. Если вы собираете отчёты, карточки товаров, резюме встреч, CRM-заметки или черновики статей через AI, одного «хорошего промпта» уже мало. Нужна вторая линия защиты: проверка фактов, сравнение с источником, подсветка сомнительных фрагментов, ручное подтверждение критичных полей.
Особенно это полезно там, где ошибка стоит дорого: финансы, legal, медицина, B2B-аналитика, YMYL-контент, а также любые автоматизированные пайплайны, где текст потом уходит в публикацию или в CRM без редактора.
Практический вывод для no-code команд простой: качество AI-сценария растёт не от длины промпта, а от того, как вы встроили контроль фактов в сам процесс.
В arXiv вышла работа про клиническое суммаризирование: Hallucination Detection-Guided Preference Optimization for Clinical Summarization. Суть не в медицине как таковой, а в подходе к качеству текста.
Авторы предложили два уровня контроля. Первый — во время генерации модель не просто пишет сводку, а получает сигнал от детектора фактических ошибок и по ходу правит проблемные места. Второй — такие цепочки правок превращают в пары предпочтений для дообучения, чтобы модель чаще выбирала более точные формулировки.
На тестах с Llama-3.1-8B-Instruct это дало заметный эффект: один вариант сократил галлюцинации на 24%, другой — на 48%. При этом текст не просел по читабельности, связности и релевантности, а качество подтверждали и эксперты, и LLM-Jury.
Почему это важно для no-code ops и маркетинга. Если вы собираете отчёты, карточки товаров, резюме встреч, CRM-заметки или черновики статей через AI, одного «хорошего промпта» уже мало. Нужна вторая линия защиты: проверка фактов, сравнение с источником, подсветка сомнительных фрагментов, ручное подтверждение критичных полей.
Особенно это полезно там, где ошибка стоит дорого: финансы, legal, медицина, B2B-аналитика, YMYL-контент, а также любые автоматизированные пайплайны, где текст потом уходит в публикацию или в CRM без редактора.
Практический вывод для no-code команд простой: качество AI-сценария растёт не от длины промпта, а от того, как вы встроили контроль фактов в сам процесс.
Как проверить, что LLM понимает задачу не только на полном контексте, но и по обрывкам данных
Проект ProjectionBench показал полезную для no-code и MarTech идею: модель стоит тестировать не только на финальном ответе, но и на том, как она собирает вывод по мере поступления информации.
В эксперименте сравнили GPT-5, GPT-5.4, Gemini 2.5 Pro и Gemini 3.1 Pro Preview на 45 научных статьях из областей bioactive materials, mechanical materials и nanomaterials. Схема была не совсем обычной: сначала модели получали только тему и исследовательский вопрос, а затем контекст раскрывали по частям. После каждого шага ответы сопоставляли с оригинальными выводами статей через семантическое сравнение атомарных утверждений.
Что важно для операционной работы с AI-инструментами: у GPT-5.4 даже при минимуме вводных сохранялось около 0.7 F1 alignment с выводами источника. То есть модель не просто «угадывала», а довольно стабильно строила рабочую гипотезу на неполной информации.
Для практики это полезно в нескольких сценариях:
- подбор и сравнение LLM для внутренних помощников;
- оценка качества ответов в AI Search;
- проверка, как модель ведёт себя, когда контент подгружается поэтапно;
- тестирование систем, где важно не красивое резюме, а совпадение с источником.
Если смотреть шире, такой подход помогает понять, какой инструмент лучше подходит для процессов с урезанным контекстом: саппорт-боты, ассистенты для аналитики, генерация summary, поиск по базе знаний. Не у всех моделей сильный финальный ответ означает сильную работу на промежуточных шагах. Именно это и показывает подобный бенчмарк.
Проект ProjectionBench показал полезную для no-code и MarTech идею: модель стоит тестировать не только на финальном ответе, но и на том, как она собирает вывод по мере поступления информации.
В эксперименте сравнили GPT-5, GPT-5.4, Gemini 2.5 Pro и Gemini 3.1 Pro Preview на 45 научных статьях из областей bioactive materials, mechanical materials и nanomaterials. Схема была не совсем обычной: сначала модели получали только тему и исследовательский вопрос, а затем контекст раскрывали по частям. После каждого шага ответы сопоставляли с оригинальными выводами статей через семантическое сравнение атомарных утверждений.
Что важно для операционной работы с AI-инструментами: у GPT-5.4 даже при минимуме вводных сохранялось около 0.7 F1 alignment с выводами источника. То есть модель не просто «угадывала», а довольно стабильно строила рабочую гипотезу на неполной информации.
Для практики это полезно в нескольких сценариях:
- подбор и сравнение LLM для внутренних помощников;
- оценка качества ответов в AI Search;
- проверка, как модель ведёт себя, когда контент подгружается поэтапно;
- тестирование систем, где важно не красивое резюме, а совпадение с источником.
Если смотреть шире, такой подход помогает понять, какой инструмент лучше подходит для процессов с урезанным контекстом: саппорт-боты, ассистенты для аналитики, генерация summary, поиск по базе знаний. Не у всех моделей сильный финальный ответ означает сильную работу на промежуточных шагах. Именно это и показывает подобный бенчмарк.
Ярлык «человек» меняет не только доверие, но и внимательность к тексту
В исследовании на 505 участниках сравнили, как люди и LLM оценивают комментарии с логическими ошибками. Текст показывали в пяти вариантах: без указания автора, как написанный человеком, как созданный ИИ, а также в смешанных сценариях, где человеку помогал ИИ или наоборот.
Что вышло любопытного: когда комментарий был помечен как «человеческий» или «человеческий с ИИ-помощью», участники чаще закрывали глаза на слабую логику. Те же тексты получали и более высокие оценки доверия. Если же источник выглядел как ИИ, люди были строже, хотя сами ошибки в содержании оставались теми же.
У моделей картина оказалась стабильнее. LLM в меньшей степени реагировали на подпись источника и оценивали один и тот же текст довольно ровно, хотя между разными моделями были отличия. При этом уверенность в своих оценках оставалась высокой и у людей, и у ИИ — даже когда аргумент был явно хромающим.
Для no-code ops и маркетинга здесь прямой вывод: маркировка контента влияет не только на репутацию, но и на качество проверки материала. Если у вас есть витрины статей, базы знаний, рассылки или лендинги с AI-generated блоками, важно думать не только о тексте, но и о том, как он подписан.
Иногда один и тот же абзац читают по-разному только потому, что рядом стоит метка «человек» или «ИИ». И это уже вопрос не стиля, а операционной дисциплины в контент-процессах.
В исследовании на 505 участниках сравнили, как люди и LLM оценивают комментарии с логическими ошибками. Текст показывали в пяти вариантах: без указания автора, как написанный человеком, как созданный ИИ, а также в смешанных сценариях, где человеку помогал ИИ или наоборот.
Что вышло любопытного: когда комментарий был помечен как «человеческий» или «человеческий с ИИ-помощью», участники чаще закрывали глаза на слабую логику. Те же тексты получали и более высокие оценки доверия. Если же источник выглядел как ИИ, люди были строже, хотя сами ошибки в содержании оставались теми же.
У моделей картина оказалась стабильнее. LLM в меньшей степени реагировали на подпись источника и оценивали один и тот же текст довольно ровно, хотя между разными моделями были отличия. При этом уверенность в своих оценках оставалась высокой и у людей, и у ИИ — даже когда аргумент был явно хромающим.
Для no-code ops и маркетинга здесь прямой вывод: маркировка контента влияет не только на репутацию, но и на качество проверки материала. Если у вас есть витрины статей, базы знаний, рассылки или лендинги с AI-generated блоками, важно думать не только о тексте, но и о том, как он подписан.
Иногда один и тот же абзац читают по-разному только потому, что рядом стоит метка «человек» или «ИИ». И это уже вопрос не стиля, а операционной дисциплины в контент-процессах.
Новый сигнал для ИИ-маркетинга: как оценивать контент без ручной разметки
В исследовании предложили Cross-Model Entropy, или CME — метрику, где ответ одной модели оценивает другая модель-верификатор. По сути, это способ дать reward-сигнал для дообучения без классической разметки людей. Для no-code и маркетинговых команд здесь важна не сама академическая формула, а то, что качество текста начинает измеряться не только по кликам, но и по тому, насколько он «понятен» для другой модели.
Авторы встроили CME в GRPO, не меняя сам цикл обучения, и проверили подход на нескольких семействах моделей: Qwen, Llama, Gemma и OLMo. В сравнении с базовыми версиями новый сигнал показал tie-adjusted win rate от 52,5% до 71,4% в задачах open-ended instruction following. Это уже не теоретическая экзотика, а довольно практичный намёк: модели можно подталкивать к лучшим ответам не только через разметку, но и через перекрёстную оценку между системами.
Для тех, кто строит контент-процессы без тяжёлой разработки, вывод такой: тексты всё чаще стоит проверять не только на «читается человеком», но и на «удобен для ИИ-переупаковки». Это особенно важно для страниц, которые живут в AI Overviews, Perplexity, поисковых ответах и других сценариях, где модель не просто находит материал, а пересобирает его в новый ответ.
Иначе говоря, контент теперь конкурирует не только за место в выдаче, но и за шанс стать сырьём для чужого ответа.
В исследовании предложили Cross-Model Entropy, или CME — метрику, где ответ одной модели оценивает другая модель-верификатор. По сути, это способ дать reward-сигнал для дообучения без классической разметки людей. Для no-code и маркетинговых команд здесь важна не сама академическая формула, а то, что качество текста начинает измеряться не только по кликам, но и по тому, насколько он «понятен» для другой модели.
Авторы встроили CME в GRPO, не меняя сам цикл обучения, и проверили подход на нескольких семействах моделей: Qwen, Llama, Gemma и OLMo. В сравнении с базовыми версиями новый сигнал показал tie-adjusted win rate от 52,5% до 71,4% в задачах open-ended instruction following. Это уже не теоретическая экзотика, а довольно практичный намёк: модели можно подталкивать к лучшим ответам не только через разметку, но и через перекрёстную оценку между системами.
Для тех, кто строит контент-процессы без тяжёлой разработки, вывод такой: тексты всё чаще стоит проверять не только на «читается человеком», но и на «удобен для ИИ-переупаковки». Это особенно важно для страниц, которые живут в AI Overviews, Perplexity, поисковых ответах и других сценариях, где модель не просто находит материал, а пересобирает его в новый ответ.
Иначе говоря, контент теперь конкурирует не только за место в выдаче, но и за шанс стать сырьём для чужого ответа.
Модель-оценщик вместо ручной разметки: куда движется посттренинг
В свежей работе показали подход Cross-Model Entropy (CME): награду для RL-посттренинга считают не по ручной оценке, а через отдельную verifier-модель. Идея простая: одна модель генерирует ответ, другая — смотрит на него как на кандидат на качество.
Авторы встроили CME в GRPO без правок в сам цикл обучения. На наборах UltraFeedback и AlpacaEval 2.0 метод сравнили с базовой моделью без дообучения. Результат оказался заметным: в парных сравнениях CME обошёл baseline у нескольких семейств моделей, включая Qwen, Llama, Gemma и OLMo. Преимущество было не символическим, а в диапазоне примерно от 52,5% до 71,4% по tie-adjusted win rate.
Почему это важно для no-code и маркетинговых команд? Потому что логика смещается от «собрали датасет руками» к «настроили контур, где качество проверяет другая модель». Для AI-поиска, ответов в стиле AI Overviews, Perplexity и похожих систем это особенно интересно: ранжироваться и попадать в ответы могут тексты, которые лучше “понимает” не только человек, но и модель-оценщик.
Практический вывод для контент-операций такой: всё больше ценности у структурированных материалов, где есть ясная задача, однозначные формулировки, хорошая связность и минимум шума. То есть у текстов, которые легче проверять автоматически и проще включать в AI-пайплайны.
Код обещают открыть после публикации. Сама работа — хороший сигнал, что в AI-контенте и MarTech следующий виток качества будет строиться не только на ручной разметке, но и на связке моделей, где одна оценивает другую.
В свежей работе показали подход Cross-Model Entropy (CME): награду для RL-посттренинга считают не по ручной оценке, а через отдельную verifier-модель. Идея простая: одна модель генерирует ответ, другая — смотрит на него как на кандидат на качество.
Авторы встроили CME в GRPO без правок в сам цикл обучения. На наборах UltraFeedback и AlpacaEval 2.0 метод сравнили с базовой моделью без дообучения. Результат оказался заметным: в парных сравнениях CME обошёл baseline у нескольких семейств моделей, включая Qwen, Llama, Gemma и OLMo. Преимущество было не символическим, а в диапазоне примерно от 52,5% до 71,4% по tie-adjusted win rate.
Почему это важно для no-code и маркетинговых команд? Потому что логика смещается от «собрали датасет руками» к «настроили контур, где качество проверяет другая модель». Для AI-поиска, ответов в стиле AI Overviews, Perplexity и похожих систем это особенно интересно: ранжироваться и попадать в ответы могут тексты, которые лучше “понимает” не только человек, но и модель-оценщик.
Практический вывод для контент-операций такой: всё больше ценности у структурированных материалов, где есть ясная задача, однозначные формулировки, хорошая связность и минимум шума. То есть у текстов, которые легче проверять автоматически и проще включать в AI-пайплайны.
Код обещают открыть после публикации. Сама работа — хороший сигнал, что в AI-контенте и MarTech следующий виток качества будет строиться не только на ручной разметке, но и на связке моделей, где одна оценивает другую.
Почему длинный поток в no-code сценариях хуже, чем кажется
Исследование на arXiv 2605.30233 хорошо объясняет, почему языковые модели часто «собирают» смысл не по ходу чтения, а ближе к финалу. Авторы пишут, что модель не хранит состояние запроса как аккуратную цепочку шагов по токенам. Вместо этого она добирает нужные фрагменты информации в конце, когда контекст уже полностью собран.
Для no-code-операций это важный сигнал. Если вы строите связку «форма → CRM → чат → письмо → отчёт», модель может не удерживать логику так, как это делает человек. Чем длиннее сценарий и чем позже появляется явный запрос, тем выше риск, что система начнёт цепляться за лишние детали или пропустит нужную сущность.
Отсюда практический вывод для маркетологов и операционных команд:
- не прячьте ключевой объект слишком далеко;
- формулируйте задачу и роль сущностей в самом начале;
- разбивайте сложный сценарий на короткие, понятные блоки;
- в шаблонах и инструкциях держите один смысл на один шаг;
- в FAQ, базах знаний и внутренних регламентах не рассчитывайте на то, что модель «дочитает и поймёт сама».
В этом же исследовании отдельно отмечен механизм REMOVE: по сути, у модели удаление связей может работать через хрупкий глобальный сигнал подавления. Это значит, что сложные операции с исключениями и отрицаниями особенно чувствительны к формулировке.
Для no-code это полезное напоминание: хорошие автоматизации для LLM — это не самые длинные, а самые явные. Чем проще структура входа, тем надёжнее ответ, классификация и извлечение данных.
Исследование на arXiv 2605.30233 хорошо объясняет, почему языковые модели часто «собирают» смысл не по ходу чтения, а ближе к финалу. Авторы пишут, что модель не хранит состояние запроса как аккуратную цепочку шагов по токенам. Вместо этого она добирает нужные фрагменты информации в конце, когда контекст уже полностью собран.
Для no-code-операций это важный сигнал. Если вы строите связку «форма → CRM → чат → письмо → отчёт», модель может не удерживать логику так, как это делает человек. Чем длиннее сценарий и чем позже появляется явный запрос, тем выше риск, что система начнёт цепляться за лишние детали или пропустит нужную сущность.
Отсюда практический вывод для маркетологов и операционных команд:
- не прячьте ключевой объект слишком далеко;
- формулируйте задачу и роль сущностей в самом начале;
- разбивайте сложный сценарий на короткие, понятные блоки;
- в шаблонах и инструкциях держите один смысл на один шаг;
- в FAQ, базах знаний и внутренних регламентах не рассчитывайте на то, что модель «дочитает и поймёт сама».
В этом же исследовании отдельно отмечен механизм REMOVE: по сути, у модели удаление связей может работать через хрупкий глобальный сигнал подавления. Это значит, что сложные операции с исключениями и отрицаниями особенно чувствительны к формулировке.
Для no-code это полезное напоминание: хорошие автоматизации для LLM — это не самые длинные, а самые явные. Чем проще структура входа, тем надёжнее ответ, классификация и извлечение данных.
Почему LLM иногда «теряют» контекст в длинных цепочках
Свежая работа arXiv 2605.30233 полезна не только исследователям, но и тем, кто строит no-code сценарии на базе ИИ. Авторы показывают: языковая модель не ведёт состояние как обычный процессор, который аккуратно обновляет каждую переменную по ходу чтения.
На практике это значит, что модель чаще не пошагово хранит все детали, а собирает нужные признаки ближе к моменту ответа. Пока запрос разрастается, часть информации может оставаться не в явном «буфере», а в распределённом виде. Из-за этого длинные инструкции, вложенные условия и цепочки сущностей иногда дают неожиданный результат.
Отдельно в исследовании разбирают операцию удаления информации. В модели она может работать не как чистое стирание, а как глобальное подавление признака. Такой механизм выглядит хрупким: он помогает в одних случаях, но в других создаёт сбои, особенно когда контекст сложный и многослойный.
Для no-code автоматизаций это важный практический вывод. Если вы строите сценарии в духе «собери данные → уточни → сравни → сделай вывод», лучше не перегружать один запрос слишком большим числом правил. Надёжнее дробить логику на этапы, явно передавать промежуточный результат и не рассчитывать, что модель безошибочно удержит всё состояние до конца.
Иными словами, LLM — это не классический state machine, а скорее агрегатор сигналов, который становится особенно чувствителен к структуре контекста. Для маркетолога и no-code оператора это повод проектировать цепочки проще и проверять их на длинных сценариях, а не только на коротких тестах.
Свежая работа arXiv 2605.30233 полезна не только исследователям, но и тем, кто строит no-code сценарии на базе ИИ. Авторы показывают: языковая модель не ведёт состояние как обычный процессор, который аккуратно обновляет каждую переменную по ходу чтения.
На практике это значит, что модель чаще не пошагово хранит все детали, а собирает нужные признаки ближе к моменту ответа. Пока запрос разрастается, часть информации может оставаться не в явном «буфере», а в распределённом виде. Из-за этого длинные инструкции, вложенные условия и цепочки сущностей иногда дают неожиданный результат.
Отдельно в исследовании разбирают операцию удаления информации. В модели она может работать не как чистое стирание, а как глобальное подавление признака. Такой механизм выглядит хрупким: он помогает в одних случаях, но в других создаёт сбои, особенно когда контекст сложный и многослойный.
Для no-code автоматизаций это важный практический вывод. Если вы строите сценарии в духе «собери данные → уточни → сравни → сделай вывод», лучше не перегружать один запрос слишком большим числом правил. Надёжнее дробить логику на этапы, явно передавать промежуточный результат и не рассчитывать, что модель безошибочно удержит всё состояние до конца.
Иными словами, LLM — это не классический state machine, а скорее агрегатор сигналов, который становится особенно чувствителен к структуре контекста. Для маркетолога и no-code оператора это повод проектировать цепочки проще и проверять их на длинных сценариях, а не только на коротких тестах.
Как выбирать не следующий шаг, а правильный
В агентных сценариях и no-code автоматизациях часто ломается не генерация сама по себе, а выбор действия. Модель может хорошо «понимать» задачу, но в реальном workflow всё решает момент: что сделать сейчас — нажать, открыть, заполнить, отправить или подождать.
Именно на этом фокусируется IntentScore — модель ранжирования действий, которая смотрит не только на текущее состояние интерфейса, но и на то, насколько кандидатный шаг помогает дойти до цели. Для обучения использовали 398 тысяч офлайн-шагов взаимодействия с GUI в трёх операционных системах.
Что важно для тех, кто собирает no-code связки и AI-агентов:
- качество сценария зависит не только от LLM, но и от ранжирования шагов внутри цепочки;
- отдельный слой оценки действий может заметно поднять точность выполнения задач;
- шумные данные из реальных интерфейсов лучше обрабатываются, когда модель учится сопоставлять состояние и действие, а не просто выдавать общий скор.
В эксперименте с Agent S3 на OSWorld такой reranker дал прирост успешности выполнения задач на 6,9 пункта. Для рынка это хороший сигнал: если агент «спотыкается» на действиях, проблему стоит искать не только в промпте, но и в логике выбора следующего шага.
Для no-code операторов вывод простой: чем сложнее автоматизация с интерфейсами, тем ценнее инструменты, которые умеют оценивать варианты действий, а не просто генерировать текст. Это уже зона не только LLM, но и архитектуры принятия решений.
Источник: arXiv 2604.05157
В агентных сценариях и no-code автоматизациях часто ломается не генерация сама по себе, а выбор действия. Модель может хорошо «понимать» задачу, но в реальном workflow всё решает момент: что сделать сейчас — нажать, открыть, заполнить, отправить или подождать.
Именно на этом фокусируется IntentScore — модель ранжирования действий, которая смотрит не только на текущее состояние интерфейса, но и на то, насколько кандидатный шаг помогает дойти до цели. Для обучения использовали 398 тысяч офлайн-шагов взаимодействия с GUI в трёх операционных системах.
Что важно для тех, кто собирает no-code связки и AI-агентов:
- качество сценария зависит не только от LLM, но и от ранжирования шагов внутри цепочки;
- отдельный слой оценки действий может заметно поднять точность выполнения задач;
- шумные данные из реальных интерфейсов лучше обрабатываются, когда модель учится сопоставлять состояние и действие, а не просто выдавать общий скор.
В эксперименте с Agent S3 на OSWorld такой reranker дал прирост успешности выполнения задач на 6,9 пункта. Для рынка это хороший сигнал: если агент «спотыкается» на действиях, проблему стоит искать не только в промпте, но и в логике выбора следующего шага.
Для no-code операторов вывод простой: чем сложнее автоматизация с интерфейсами, тем ценнее инструменты, которые умеют оценивать варианты действий, а не просто генерировать текст. Это уже зона не только LLM, но и архитектуры принятия решений.
Источник: arXiv 2604.05157
Искусственный интеллект играет в покер без готовых решений — и это важно для всех, кто работает с правилами и процедурами
Недавно в научном архиве arXiv появилась система PokerSkill, которая заставила задуматься не только любителей покера, но и тех, кто строит автоматизацию на основе ИИ. Суть в том, что модели вроде GPT-5.5 и Claude Opus 4.6 получили сложную задачу — играть в техасский холдем, — но без доступа к специализированным солверам и предобученным стратегиям. Результаты пока не в пользу ИИ: проигрыш в районе 57–80 mbb/hand. Но сам подход оказался перспективным.
Ключевое — PokerSkill не просто просит модель «подумать как профи», а даёт чёткую структуру: формализованные действия, правила принятия решений, дерево возможных ходов. Это позволило сократить потери почти вдвое по сравнению с обычным промптом. Даже без идеального результата видно: когда задача описана как последовательность шагов, машина справляется лучше.
Что это даёт no-code операторам и маркетологам? Простой вывод: если ваш процесс можно разложить на правила, условия и действия — не полагайтесь на расплывчатые инструкции. Лучше потратить время на структурирование логики, чем потом исправлять ошибки ИИ. Особенно это актуально для автоматизации в CRM, обработке лидов, создании чек-листов или внутренних инструкций.
Интересно, что следующий шаг — перенос такого подхода за пределы игры. Представьте, как система анализирует коммерческое предложение, проверяет его на соответствие шаблону, предлагает правки по правилам компании — всё без кода, но с чёткой внутренней логикой. Это уже не фантазия, а направление, которое начинает работать.
Пока ИИ проигрывает в покере, он учится думать последовательно. А это как раз то, что нужно для построения надёжных операционных процессов.
Недавно в научном архиве arXiv появилась система PokerSkill, которая заставила задуматься не только любителей покера, но и тех, кто строит автоматизацию на основе ИИ. Суть в том, что модели вроде GPT-5.5 и Claude Opus 4.6 получили сложную задачу — играть в техасский холдем, — но без доступа к специализированным солверам и предобученным стратегиям. Результаты пока не в пользу ИИ: проигрыш в районе 57–80 mbb/hand. Но сам подход оказался перспективным.
Ключевое — PokerSkill не просто просит модель «подумать как профи», а даёт чёткую структуру: формализованные действия, правила принятия решений, дерево возможных ходов. Это позволило сократить потери почти вдвое по сравнению с обычным промптом. Даже без идеального результата видно: когда задача описана как последовательность шагов, машина справляется лучше.
Что это даёт no-code операторам и маркетологам? Простой вывод: если ваш процесс можно разложить на правила, условия и действия — не полагайтесь на расплывчатые инструкции. Лучше потратить время на структурирование логики, чем потом исправлять ошибки ИИ. Особенно это актуально для автоматизации в CRM, обработке лидов, создании чек-листов или внутренних инструкций.
Интересно, что следующий шаг — перенос такого подхода за пределы игры. Представьте, как система анализирует коммерческое предложение, проверяет его на соответствие шаблону, предлагает правки по правилам компании — всё без кода, но с чёткой внутренней логикой. Это уже не фантазия, а направление, которое начинает работать.
Пока ИИ проигрывает в покере, он учится думать последовательно. А это как раз то, что нужно для построения надёжных операционных процессов.
Эволюция автоматизации: переход к гибридной маршрутизации задач
Разработчики Perplexity анонсировали инструмент, который меняет подход к распределению вычислительных нагрузок. Система берет на себя выбор: выполнять задачу локально на устройстве пользователя или отправлять запрос в облако к мощным языковым моделям. Это не просто обновление интерфейса, а сдвиг в сторону гибкой архитектуры интеллектуальных агентов.
Для тех, кто выстраивает процессы автоматизации на базе No-Code, это важный рыночный сигнал. Долгое время мы выбирали между скоростью (локальные решения) и качеством «мышления» (облачные модели). Теперь фокус смещается на создание связок, где маршрутизация становится ключевым элементом системы.
Как это применить в операционной работе:
Разделяйте логику по сложности. Рутинные операции — быстрый анализ структуры рекламного кабинета, первичная сортировка креативов или подготовка черновиков — могут выполняться локально. Это экономит бюджет и снижает задержки.
Выносите «тяжелую» аналитику в облако. Сложные задачи, требующие глубокого понимания контекста, стратегического планирования или перекрестной проверки данных из нескольких источников, по-прежнему требуют ресурсов передовых моделей.
Стройте многоуровневую архитектуру. Вместо того чтобы пытаться заставить одну модель делать всё, проектируйте систему как конвейер. Пусть «умный» агент в облаке только ставит задачи и интерпретирует выводы, а первичный сбор данных и простая фильтрация происходят там, где это быстрее и дешевле.
Главный вопрос для оператора сегодня — не наличие агента в связке, а эффективность маршрутизатора между вашими инструментами. Если ваши автоматизации до сих пор работают по принципу «один сценарий — одна тяжелая модель», вы переплачиваете за избыточные вычисления. Время пересмотреть архитектуру в пользу гибридных решений.
Разработчики Perplexity анонсировали инструмент, который меняет подход к распределению вычислительных нагрузок. Система берет на себя выбор: выполнять задачу локально на устройстве пользователя или отправлять запрос в облако к мощным языковым моделям. Это не просто обновление интерфейса, а сдвиг в сторону гибкой архитектуры интеллектуальных агентов.
Для тех, кто выстраивает процессы автоматизации на базе No-Code, это важный рыночный сигнал. Долгое время мы выбирали между скоростью (локальные решения) и качеством «мышления» (облачные модели). Теперь фокус смещается на создание связок, где маршрутизация становится ключевым элементом системы.
Как это применить в операционной работе:
Разделяйте логику по сложности. Рутинные операции — быстрый анализ структуры рекламного кабинета, первичная сортировка креативов или подготовка черновиков — могут выполняться локально. Это экономит бюджет и снижает задержки.
Выносите «тяжелую» аналитику в облако. Сложные задачи, требующие глубокого понимания контекста, стратегического планирования или перекрестной проверки данных из нескольких источников, по-прежнему требуют ресурсов передовых моделей.
Стройте многоуровневую архитектуру. Вместо того чтобы пытаться заставить одну модель делать всё, проектируйте систему как конвейер. Пусть «умный» агент в облаке только ставит задачи и интерпретирует выводы, а первичный сбор данных и простая фильтрация происходят там, где это быстрее и дешевле.
Главный вопрос для оператора сегодня — не наличие агента в связке, а эффективность маршрутизатора между вашими инструментами. Если ваши автоматизации до сих пор работают по принципу «один сценарий — одна тяжелая модель», вы переплачиваете за избыточные вычисления. Время пересмотреть архитектуру в пользу гибридных решений.
Как метки «написано человеком» искажают объективность при работе с контентом
В недавнем эксперименте исследователи проверили, как наличие плашки «сгенерировано нейросетью» или «написано человеком» влияет на восприятие текста. Участникам предлагали оценить материалы, содержащие логические ошибки, при этом манипулируя пометками об авторстве.
Результаты оказались любопытными: люди гораздо охотнее принимали нелогичные аргументы, если те были маркированы как созданные человеком или человеком при помощи ИИ. В то же время, когда текст помечался как сугубо машинный, критическое восприятие читателей обострялось. Примечательно, что модели оценки на базе языковых алгоритмов (LLM) оказались куда более беспристрастными: их суждения были стабильны независимо от того, какой «ярлык» повесили на текст.
Для тех, кто выстраивает операционные процессы в контенте и маркетинге, этот кейс несет важный урок. Если ваш рабочий пайплайн включает ручную модерацию, проверку качества или смешанные процессы (человек + ИИ), вы рискуете столкнуться с предвзятостью оценщиков. Человеческий фактор здесь работает против объективности: мы подсознательно доверяем «своим» и излишне критикуем «машину», даже когда аргументация идентична.
Что это значит для no-code оператора, работающего с автоматизацией контента:
1. Слепые тесты обязательны. Если вы проводите A/B-тестирование креативов или статей, уберите любые указания на авторство из интерфейсов оценки. Оценка контента должна идти «в вакууме», иначе вы будете тестировать не качество смыслов, а свои предубеждения.
2. Автоматизация оценки надежнее. В задачах по фильтрации контента или оценке качества по заданным критериям ИИ-агенты справляются стабильнее, так как они не подвержены влиянию ярлыков «человек vs нейросеть».
3. Проверка пайплайнов. При настройке процессов автоматизированного ревью убедитесь, что разметчики не видят, кто именно подготовил черновик. Предвзятость, заложенная в методологию оценки, — это «тихая» ошибка, которая может стоить эффективности всей воронки.
В условиях, когда границы между авторством ИИ и человека стираются, доверие к контенту начинают определять не сами смыслы, а контекст и метки. Не позволяйте предвзятости искажать данные вашего тестирования.
В недавнем эксперименте исследователи проверили, как наличие плашки «сгенерировано нейросетью» или «написано человеком» влияет на восприятие текста. Участникам предлагали оценить материалы, содержащие логические ошибки, при этом манипулируя пометками об авторстве.
Результаты оказались любопытными: люди гораздо охотнее принимали нелогичные аргументы, если те были маркированы как созданные человеком или человеком при помощи ИИ. В то же время, когда текст помечался как сугубо машинный, критическое восприятие читателей обострялось. Примечательно, что модели оценки на базе языковых алгоритмов (LLM) оказались куда более беспристрастными: их суждения были стабильны независимо от того, какой «ярлык» повесили на текст.
Для тех, кто выстраивает операционные процессы в контенте и маркетинге, этот кейс несет важный урок. Если ваш рабочий пайплайн включает ручную модерацию, проверку качества или смешанные процессы (человек + ИИ), вы рискуете столкнуться с предвзятостью оценщиков. Человеческий фактор здесь работает против объективности: мы подсознательно доверяем «своим» и излишне критикуем «машину», даже когда аргументация идентична.
Что это значит для no-code оператора, работающего с автоматизацией контента:
1. Слепые тесты обязательны. Если вы проводите A/B-тестирование креативов или статей, уберите любые указания на авторство из интерфейсов оценки. Оценка контента должна идти «в вакууме», иначе вы будете тестировать не качество смыслов, а свои предубеждения.
2. Автоматизация оценки надежнее. В задачах по фильтрации контента или оценке качества по заданным критериям ИИ-агенты справляются стабильнее, так как они не подвержены влиянию ярлыков «человек vs нейросеть».
3. Проверка пайплайнов. При настройке процессов автоматизированного ревью убедитесь, что разметчики не видят, кто именно подготовил черновик. Предвзятость, заложенная в методологию оценки, — это «тихая» ошибка, которая может стоить эффективности всей воронки.
В условиях, когда границы между авторством ИИ и человека стираются, доверие к контенту начинают определять не сами смыслы, а контекст и метки. Не позволяйте предвзятости искажать данные вашего тестирования.