Как дообучают без разметки и почему это важно для 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 оператора это повод проектировать цепочки проще и проверять их на длинных сценариях, а не только на коротких тестах.