Qwen 3.7 Max теперь можно подключать через Vercel AI Gateway
Для no-code и martech-сценариев это интересная новость не потому, что модель «ещё одна в списке», а потому что она встраивается в привычный слой управления AI без отдельной возни с провайдерами.
Что даёт такой формат:
— единая точка вызова для разных моделей
— учёт использования и затрат в одном месте
— retries и failover, чтобы цепочки не ломались на одном сбое
— базовые оптимизации по производительности без ручной сборки вокруг каждой интеграции
В каталоге модель обозначена как `alibaba/qwen-3.7-max`.
Самый полезный угол здесь — агентные задачи. Не разовый запрос в духе «напиши текст для лендинга», а более длинный процесс: сгенерировать несколько вариантов блоков, проверить формулировки, пройтись по структуре страницы, подставить данные из других источников, довести результат до пригодного состояния.
Для no-code-операторов это особенно важно, если AI живёт не в отдельном чате, а внутри workflow:
— генерация контента для страниц и форм
— автоподготовка вариантов заголовков и CTA
— многошаговая обработка заявок и текстов
— backend-логика для лендингов и внутренних инструментов
По сути, Qwen 3.7 Max в таком стеке интересна не как замена конструкторам сайтов, а как рабочая модель для фоновых операций: когда нужна не одна подсказка, а длинная цепочка действий с контролем качества и устойчивостью.
Пока это именно сигнал о доступности в Gateway, а не вывод о качестве кода или экономике в реальных проектах. Но для тех, кто строит автоматизацию без тяжёлой разработки, такой релиз стоит держать в поле зрения.
Для no-code и martech-сценариев это интересная новость не потому, что модель «ещё одна в списке», а потому что она встраивается в привычный слой управления AI без отдельной возни с провайдерами.
Что даёт такой формат:
— единая точка вызова для разных моделей
— учёт использования и затрат в одном месте
— retries и failover, чтобы цепочки не ломались на одном сбое
— базовые оптимизации по производительности без ручной сборки вокруг каждой интеграции
В каталоге модель обозначена как `alibaba/qwen-3.7-max`.
Самый полезный угол здесь — агентные задачи. Не разовый запрос в духе «напиши текст для лендинга», а более длинный процесс: сгенерировать несколько вариантов блоков, проверить формулировки, пройтись по структуре страницы, подставить данные из других источников, довести результат до пригодного состояния.
Для no-code-операторов это особенно важно, если AI живёт не в отдельном чате, а внутри workflow:
— генерация контента для страниц и форм
— автоподготовка вариантов заголовков и CTA
— многошаговая обработка заявок и текстов
— backend-логика для лендингов и внутренних инструментов
По сути, Qwen 3.7 Max в таком стеке интересна не как замена конструкторам сайтов, а как рабочая модель для фоновых операций: когда нужна не одна подсказка, а длинная цепочка действий с контролем качества и устойчивостью.
Пока это именно сигнал о доступности в Gateway, а не вывод о качестве кода или экономике в реальных проектах. Но для тех, кто строит автоматизацию без тяжёлой разработки, такой релиз стоит держать в поле зрения.
LLM без привычных «плотных» слоёв: зачем это no-code командам
В свежем исследовании показали модель Graph Memory Transformer, где токены идут не только через attention, но и через граф памяти. Самое любопытное — из архитектуры убрали dense FFN-слои, а вместо них оставили memory cell с маршрутизацией через центроиды и переходами по направленному графу.
По параметрам это выглядит скромнее классического подхода: у базовой версии GMT v7 около 82,2 млн параметров против 103 млн у dense GPT-бейзлайна. Но по качеству пока есть отставание: perplexity у новой схемы хуже, чем у обычной модели. Иными словами, идея интересная, но до замены стандартного Transformer ей ещё далеко.
Почему это вообще важно для no-code ops и маркетинга? Потому что такой дизайн делает путь решения более «читаемым». Если подобные архитектуры дожмут качество, появится шанс разбирать не только prompt и логи, но и то, как модель выбирает маршрут внутри памяти. Для AI-воркфлоу это полезно: проще искать, где именно ломается генерация текста, структуры лендинга, вариантов оффера или связок для авто-контента.
Практический вывод сейчас простой: это не готовый продакшен-инструмент, а сигнал, куда движется рынок моделей. В 2026 году интерес к архитектурам без FFN, похоже, будет расти — особенно там, где важны управляемость, экономия ресурсов и более понятная отладка AI-систем без тяжёлой разработки.
В свежем исследовании показали модель Graph Memory Transformer, где токены идут не только через attention, но и через граф памяти. Самое любопытное — из архитектуры убрали dense FFN-слои, а вместо них оставили memory cell с маршрутизацией через центроиды и переходами по направленному графу.
По параметрам это выглядит скромнее классического подхода: у базовой версии GMT v7 около 82,2 млн параметров против 103 млн у dense GPT-бейзлайна. Но по качеству пока есть отставание: perplexity у новой схемы хуже, чем у обычной модели. Иными словами, идея интересная, но до замены стандартного Transformer ей ещё далеко.
Почему это вообще важно для no-code ops и маркетинга? Потому что такой дизайн делает путь решения более «читаемым». Если подобные архитектуры дожмут качество, появится шанс разбирать не только prompt и логи, но и то, как модель выбирает маршрут внутри памяти. Для AI-воркфлоу это полезно: проще искать, где именно ломается генерация текста, структуры лендинга, вариантов оффера или связок для авто-контента.
Практический вывод сейчас простой: это не готовый продакшен-инструмент, а сигнал, куда движется рынок моделей. В 2026 году интерес к архитектурам без FFN, похоже, будет расти — особенно там, где важны управляемость, экономия ресурсов и более понятная отладка AI-систем без тяжёлой разработки.
Почему метрики качества текста ломаются на смысле
В исследованиях по распознаванию речи всё чаще смотрят не только на точность слов, но и на то, не потерялся ли смысл. Для этого предложили два интересных инструмента: Agentic ASR и S²ER.
Agentic ASR работает не как классический «один проход — один результат». Модель делает несколько итераций: уточняет спорные места, учитывает контекст, исправляет смысловые ошибки и может по-разному обрабатывать имена, термины и смешение языков. Это полезно там, где один неверно распознанный фрагмент меняет весь ответ.
Вторая часть — Sentence-level Semantic Error Rate, или S²ER. Это метрика, которую оценивает LLM, и она проверяет уже не символы и не количество опечаток, а то, насколько близок итоговый текст по смыслу. То есть WER и CER покажут, что строка «почти совпала», а S²ER заметит, что смысл уехал.
Для no-code и MarTech это особенно интересно. Если вы строите пайплайн из голосовых заметок, расшифровок звонков, AI-саммари, поиска по знаниям или контентных воронок, одной «технической точности» мало. Важно, чтобы система не просто угадывала слова, а сохраняла намерение, сущности и логику ответа.
Практический вывод простой: в продуктах с LLM-проверкой стоит смотреть не только на совпадение текста, но и на семантическое качество. Иначе автоматизация будет выглядеть корректно, но работать мимо задачи пользователя.
В исследованиях по распознаванию речи всё чаще смотрят не только на точность слов, но и на то, не потерялся ли смысл. Для этого предложили два интересных инструмента: Agentic ASR и S²ER.
Agentic ASR работает не как классический «один проход — один результат». Модель делает несколько итераций: уточняет спорные места, учитывает контекст, исправляет смысловые ошибки и может по-разному обрабатывать имена, термины и смешение языков. Это полезно там, где один неверно распознанный фрагмент меняет весь ответ.
Вторая часть — Sentence-level Semantic Error Rate, или S²ER. Это метрика, которую оценивает LLM, и она проверяет уже не символы и не количество опечаток, а то, насколько близок итоговый текст по смыслу. То есть WER и CER покажут, что строка «почти совпала», а S²ER заметит, что смысл уехал.
Для no-code и MarTech это особенно интересно. Если вы строите пайплайн из голосовых заметок, расшифровок звонков, AI-саммари, поиска по знаниям или контентных воронок, одной «технической точности» мало. Важно, чтобы система не просто угадывала слова, а сохраняла намерение, сущности и логику ответа.
Практический вывод простой: в продуктах с LLM-проверкой стоит смотреть не только на совпадение текста, но и на семантическое качество. Иначе автоматизация будет выглядеть корректно, но работать мимо задачи пользователя.
Как встроить проверку фактов в no-code пайплайн
В свежей работе на ArXiv показали практичный подход к снижению «галлюцинаций» у LLM в задачах, где ошибка особенно дорога. Речь не только про медицину: логика хорошо ложится и на no-code процессы, где AI пишет черновики для рассылок, карточек товаров, CRM-заметок, саппорт-ответов и отчётов.
Схема состоит из двух частей. Первая — итеративная правка ответа на этапе генерации: модель не просто выдаёт текст, а проходит через проверку на фактические ошибки и исправляет спорные места шаг за шагом. Вторая — превращение таких траекторий исправлений в обучающие пары предпочтений, чтобы дообучить модель на более аккуратные ответы.
На клиническом наборе MIMIC-IV это дало заметный эффект: у Llama и Gemma снизилось число фактических ошибок, а качество текста по оценкам экспертов не просело по читаемости, связности и уместности. Для no-code оператора это важный сигнал: качество AI-черновика можно улучшать не только промптом, но и отдельным контуром контроля перед публикацией.
Что это означает на практике:
- AI можно использовать как генератор первого драфта, а не как финальный источник истины.
- Проверку фактов стоит выносить в отдельный шаг.
- Для контентных и операционных сценариев полезнее не «идеальная генерация», а управляемая цепочка: черновик → проверка → правка → выпуск.
Если вы строите no-code систему на базе LLM, такой подход особенно полезен там, где важны точность, доверие и повторяемость результата.
В свежей работе на ArXiv показали практичный подход к снижению «галлюцинаций» у LLM в задачах, где ошибка особенно дорога. Речь не только про медицину: логика хорошо ложится и на no-code процессы, где AI пишет черновики для рассылок, карточек товаров, CRM-заметок, саппорт-ответов и отчётов.
Схема состоит из двух частей. Первая — итеративная правка ответа на этапе генерации: модель не просто выдаёт текст, а проходит через проверку на фактические ошибки и исправляет спорные места шаг за шагом. Вторая — превращение таких траекторий исправлений в обучающие пары предпочтений, чтобы дообучить модель на более аккуратные ответы.
На клиническом наборе MIMIC-IV это дало заметный эффект: у Llama и Gemma снизилось число фактических ошибок, а качество текста по оценкам экспертов не просело по читаемости, связности и уместности. Для no-code оператора это важный сигнал: качество AI-черновика можно улучшать не только промптом, но и отдельным контуром контроля перед публикацией.
Что это означает на практике:
- AI можно использовать как генератор первого драфта, а не как финальный источник истины.
- Проверку фактов стоит выносить в отдельный шаг.
- Для контентных и операционных сценариев полезнее не «идеальная генерация», а управляемая цепочка: черновик → проверка → правка → выпуск.
Если вы строите no-code систему на базе LLM, такой подход особенно полезен там, где важны точность, доверие и повторяемость результата.
Как оценивать ответы ИИ без разметки: интересный кейс для No-Code Ops
Исследователи показали подход, который может быть полезен всем, кто собирает AI-воркфлоу без тяжёлой разработки. Речь про Cross-Model Entropy — способ дать модели «внутренний» сигнал качества, когда отдельный verifier смотрит на ответ генератора и оценивает его по средней логарифмической вероятности.
Практический смысл тут простой: для дообучения и настройки поведения ИИ не всегда нужен большой массив ручной разметки. CME можно встроить в GRPO и не менять сам цикл обучения. В тестах на UltraFeedback и AlpacaEval 2.0 такой reward показал рост качества в сравнении с необученной базой на нескольких семействах моделей, включая Qwen, Llama, Gemma и OLMo.
Почему это важно для no-code операторов и маркетологов? Потому что всё больше задач вокруг AI-ассистентов, внутренних баз знаний и генерации контента зависит не только от промптов, но и от того, как система оценивает ответ. Если оценка становится стабильнее без ручных меток, проще строить автоматизацию, где модель не просто генерирует текст, а ещё и сама отбраковывает слабые варианты.
Для рабочих сценариев это означает несколько вещей:
- меньше хаоса в ответах ИИ;
- выше шанс получить структурированный и полезный текст;
- проще масштабировать AI-процессы в саппорте, контенте и поисковых сценариях.
Иными словами, рынок двигается к тому, что качество ИИ всё сильнее зависит не от «красивого промпта», а от того, как выстраивается контур оценки. Для no-code стеков это хороший сигнал: появится больше инструментов, где улучшение качества можно собирать без полноценной команды ML-разработки.
Исследователи показали подход, который может быть полезен всем, кто собирает AI-воркфлоу без тяжёлой разработки. Речь про Cross-Model Entropy — способ дать модели «внутренний» сигнал качества, когда отдельный verifier смотрит на ответ генератора и оценивает его по средней логарифмической вероятности.
Практический смысл тут простой: для дообучения и настройки поведения ИИ не всегда нужен большой массив ручной разметки. CME можно встроить в GRPO и не менять сам цикл обучения. В тестах на UltraFeedback и AlpacaEval 2.0 такой reward показал рост качества в сравнении с необученной базой на нескольких семействах моделей, включая Qwen, Llama, Gemma и OLMo.
Почему это важно для no-code операторов и маркетологов? Потому что всё больше задач вокруг AI-ассистентов, внутренних баз знаний и генерации контента зависит не только от промптов, но и от того, как система оценивает ответ. Если оценка становится стабильнее без ручных меток, проще строить автоматизацию, где модель не просто генерирует текст, а ещё и сама отбраковывает слабые варианты.
Для рабочих сценариев это означает несколько вещей:
- меньше хаоса в ответах ИИ;
- выше шанс получить структурированный и полезный текст;
- проще масштабировать AI-процессы в саппорте, контенте и поисковых сценариях.
Иными словами, рынок двигается к тому, что качество ИИ всё сильнее зависит не от «красивого промпта», а от того, как выстраивается контур оценки. Для no-code стеков это хороший сигнал: появится больше инструментов, где улучшение качества можно собирать без полноценной команды ML-разработки.
Модели можно не только просить «написать», но и заставлять исправлять себя по ходу работы
В свежем исследовании предложили подход IterModel: генерация идёт итерациями, а между шагами в работу подключается детектор ошибок. Он отмечает места, где ответ похож на галлюцинацию, и модель переписывает именно проблемные фрагменты, а не весь текст целиком.
Есть и вторая версия — IterModel for Preference Learning. Там цепочки исправлений превращают в пары предпочтений для дообучения, чтобы модель со временем лучше понимала, как выглядит более точный вариант ответа.
На клинических заметках MIMIC-IV это дало заметный эффект: у Llama-3.1-8B-Instruct число галлюцинаций сократилось на 24% в базовой версии и на 48% во второй. При этом эксперты и LLM-Jury не увидели провала по связности, беглости и релевантности.
Для no-code и MarTech здесь полезен не медицинский результат, а сам принцип. Если у вас длинные тексты, автоматические саммари, описания товаров, ответы саппорта или отчёты из CRM, качество можно поднять не только за счёт лучшей модели, но и за счёт слоя проверки. Сценарий простой по логике: генерация → детекция сомнительных мест → точечная правка → финальная верификация.
Особенно это важно там, где ошибка стоит дорого: финансы, медицина, юртематика, B2B-лендинги, продуктовые FAQ. Для no-code операторов это хороший сигнал: надёжный AI-процесс часто строится не на «одной умной модели», а на связке из нескольких маленьких инструментов.
Источник: arxiv.org/abs/2605.28910
В свежем исследовании предложили подход IterModel: генерация идёт итерациями, а между шагами в работу подключается детектор ошибок. Он отмечает места, где ответ похож на галлюцинацию, и модель переписывает именно проблемные фрагменты, а не весь текст целиком.
Есть и вторая версия — IterModel for Preference Learning. Там цепочки исправлений превращают в пары предпочтений для дообучения, чтобы модель со временем лучше понимала, как выглядит более точный вариант ответа.
На клинических заметках MIMIC-IV это дало заметный эффект: у Llama-3.1-8B-Instruct число галлюцинаций сократилось на 24% в базовой версии и на 48% во второй. При этом эксперты и LLM-Jury не увидели провала по связности, беглости и релевантности.
Для no-code и MarTech здесь полезен не медицинский результат, а сам принцип. Если у вас длинные тексты, автоматические саммари, описания товаров, ответы саппорта или отчёты из CRM, качество можно поднять не только за счёт лучшей модели, но и за счёт слоя проверки. Сценарий простой по логике: генерация → детекция сомнительных мест → точечная правка → финальная верификация.
Особенно это важно там, где ошибка стоит дорого: финансы, медицина, юртематика, B2B-лендинги, продуктовые FAQ. Для no-code операторов это хороший сигнал: надёжный AI-процесс часто строится не на «одной умной модели», а на связке из нескольких маленьких инструментов.
Источник: arxiv.org/abs/2605.28910
arXiv.org
Hallucination Detection-Guided Preference Optimization for...
Large language models (LLMs) have shown promise on summarization tasks, but they often produce hallucinations, which are unsupported or incorrect statements that limit their reliability in...
Почему подпись к материалу иногда важнее самого текста
Есть свежий эксперимент на 505 участниках: людям показывали комментарии с логическими ошибками и разными пометками источника — написано человеком, сделано ИИ, человек с помощью ИИ, ИИ с помощью человека или вообще без указания автора. Потом ответы сравнили с оценками языковой модели.
Что оказалось неожиданным: когда текст был отмечен как «человеческий» или «человеческий с ИИ-помощью», участники чаще закрывали глаза на ошибки и ставили выше доверие к материалу и его качеству.
А вот оценки самой LLM почти не менялись, даже если метка источника менялась.
Для no-code и маркетинга здесь важный вывод простой: в интерфейсах, где контент создаётся или собирается без тяжёлой разработки, метка автора и источник генерации становятся частью продукта. Пользователь считывает не только смысл, но и происхождение. И это влияет на доверие сильнее, чем кажется.
Что это значит на практике:
- бейдж «сделано человеком» способен поднимать субъективное качество даже у слабого текста;
- прозрачная маркировка ИИ может, наоборот, менять восприятие материала до чтения;
- в лендингах, базах знаний, help center и генераторах контента стоит тестировать не только формулировки, но и подписи к ним.
Для no-code оператора это хороший ориентир: если вы автоматизируете контент, карточки товаров, FAQ или ответы поддержки, следите не только за самим текстом, но и за тем, как вы объясняете его происхождение. Иногда именно эта маленькая строка решает, будет ли материал восприниматься как полезный или как «автоматический шум».
Есть свежий эксперимент на 505 участниках: людям показывали комментарии с логическими ошибками и разными пометками источника — написано человеком, сделано ИИ, человек с помощью ИИ, ИИ с помощью человека или вообще без указания автора. Потом ответы сравнили с оценками языковой модели.
Что оказалось неожиданным: когда текст был отмечен как «человеческий» или «человеческий с ИИ-помощью», участники чаще закрывали глаза на ошибки и ставили выше доверие к материалу и его качеству.
А вот оценки самой LLM почти не менялись, даже если метка источника менялась.
Для no-code и маркетинга здесь важный вывод простой: в интерфейсах, где контент создаётся или собирается без тяжёлой разработки, метка автора и источник генерации становятся частью продукта. Пользователь считывает не только смысл, но и происхождение. И это влияет на доверие сильнее, чем кажется.
Что это значит на практике:
- бейдж «сделано человеком» способен поднимать субъективное качество даже у слабого текста;
- прозрачная маркировка ИИ может, наоборот, менять восприятие материала до чтения;
- в лендингах, базах знаний, help center и генераторах контента стоит тестировать не только формулировки, но и подписи к ним.
Для no-code оператора это хороший ориентир: если вы автоматизируете контент, карточки товаров, FAQ или ответы поддержки, следите не только за самим текстом, но и за тем, как вы объясняете его происхождение. Иногда именно эта маленькая строка решает, будет ли материал восприниматься как полезный или как «автоматический шум».
Почему в no-code-автоматизациях метка автора влияет на доверие сильнее, чем сама логика
В одном онлайн-эксперименте сравнили, как люди и языковые модели оценивают одинаковые тексты, если рядом стоит разная отметка источника: «написано человеком», «сделано ИИ», «человек с помощью ИИ», «ИИ с помощью человека» или вообще без пояснения.
Результат оказался показательный. Люди заметно чаще считали убедительным текст, если он выглядел «человеческим» или гибридным. Даже когда в нём была логическая ошибка, доверие к такому материалу росло.
У моделей картина была ровнее: они меньше реагировали на подпись и сильнее держались за содержание, хотя различия между самими моделями всё равно были.
Для no-code ops и маркетинга это важный сигнал. Мы часто обсуждаем качество текста, но в реальной работе решает не только формулировка. На восприятие влияет ещё и то, как контент упакован в интерфейсе: есть ли пометка об источнике, кто автор, как выглядит карточка, есть ли следы участия ИИ, насколько «живым» кажется материал.
Это особенно заметно в инструментах, где контент проходит через несколько слоёв: генерация, редактирование, публикация, подборка в базу знаний, выдача в поиске, внутренний поиск по ассистенту. На каждом этапе одна и та же заметка может восприниматься по-разному.
Практический вывод простой: в автоматизации контента стоит тестировать не только текст, но и его атрибуцию. Иногда небольшая правка в подписи, карточке автора или пояснении к источнику меняет доверие сильнее, чем переписывание самого абзаца.
В одном онлайн-эксперименте сравнили, как люди и языковые модели оценивают одинаковые тексты, если рядом стоит разная отметка источника: «написано человеком», «сделано ИИ», «человек с помощью ИИ», «ИИ с помощью человека» или вообще без пояснения.
Результат оказался показательный. Люди заметно чаще считали убедительным текст, если он выглядел «человеческим» или гибридным. Даже когда в нём была логическая ошибка, доверие к такому материалу росло.
У моделей картина была ровнее: они меньше реагировали на подпись и сильнее держались за содержание, хотя различия между самими моделями всё равно были.
Для no-code ops и маркетинга это важный сигнал. Мы часто обсуждаем качество текста, но в реальной работе решает не только формулировка. На восприятие влияет ещё и то, как контент упакован в интерфейсе: есть ли пометка об источнике, кто автор, как выглядит карточка, есть ли следы участия ИИ, насколько «живым» кажется материал.
Это особенно заметно в инструментах, где контент проходит через несколько слоёв: генерация, редактирование, публикация, подборка в базу знаний, выдача в поиске, внутренний поиск по ассистенту. На каждом этапе одна и та же заметка может восприниматься по-разному.
Практический вывод простой: в автоматизации контента стоит тестировать не только текст, но и его атрибуцию. Иногда небольшая правка в подписи, карточке автора или пояснении к источнику меняет доверие сильнее, чем переписывание самого абзаца.
В ASR стали мерить не только ошибки, но и смысл
Если вы собираете no-code цепочки вокруг голоса — расшифровку звонков, ассистента поддержки, автозаполнение CRM — одного WER/CER уже мало. Эти метрики считают, сколько слов или символов система перепутала, но не отвечают на главный вопрос: сохранился ли смысл.
В исследованиях по Interactive ASR появился полезный сдвиг: распознавание речи стали рассматривать как диалог с моделью, где результат можно уточнять и переписывать по ходу работы. Для такой оценки авторы предложили S^2ER (Sentence-level Semantic Error Rate) — метрику, которая измеряет не буквальную точность, а семантическую ошибку на уровне предложения.
Это особенно важно для маркетинга и no-code-операций. В реальных голосовых сценариях ломается не текст, а намерение. На русско-английских созвонах, с фамилиями, названиями компаний и кодовыми словами транскрипт может выглядеть почти идеальным, а триггер в автоматизации всё равно уедет не туда. По WER всё нормально, по факту — лид потерян или тикет попал в неверный поток.
Для команд, которые выбирают ASR-сервис или строят голосовые сценарии без тяжёлой разработки, вывод простой: смотреть нужно не только на чистоту расшифровки, но и на то, совпадает ли итоговый смысл с бизнес-задачей. Именно в эту сторону сейчас двигается оценка голосовых AI-инструментов.
Если вы собираете no-code цепочки вокруг голоса — расшифровку звонков, ассистента поддержки, автозаполнение CRM — одного WER/CER уже мало. Эти метрики считают, сколько слов или символов система перепутала, но не отвечают на главный вопрос: сохранился ли смысл.
В исследованиях по Interactive ASR появился полезный сдвиг: распознавание речи стали рассматривать как диалог с моделью, где результат можно уточнять и переписывать по ходу работы. Для такой оценки авторы предложили S^2ER (Sentence-level Semantic Error Rate) — метрику, которая измеряет не буквальную точность, а семантическую ошибку на уровне предложения.
Это особенно важно для маркетинга и no-code-операций. В реальных голосовых сценариях ломается не текст, а намерение. На русско-английских созвонах, с фамилиями, названиями компаний и кодовыми словами транскрипт может выглядеть почти идеальным, а триггер в автоматизации всё равно уедет не туда. По WER всё нормально, по факту — лид потерян или тикет попал в неверный поток.
Для команд, которые выбирают ASR-сервис или строят голосовые сценарии без тяжёлой разработки, вывод простой: смотреть нужно не только на чистоту расшифровки, но и на то, совпадает ли итоговый смысл с бизнес-задачей. Именно в эту сторону сейчас двигается оценка голосовых AI-инструментов.
Почему LLM иногда «теряют нить» и как это учитывать в No-Code Ops
Свежая arXiv-работа 2605.30233 хорошо объясняет один неприятный эффект в работе языковых моделей: они не обязательно ведут внутреннее состояние шаг за шагом, пока читают текст. По сути, нужные детали могут собираться не постепенно, а ближе к финалу — когда запрос уже стал полностью понятен.
Практический вывод для no-code автоматизаций и маркетинговых сценариев простой: если вы строите цепочку на LLM, нельзя рассчитывать, что модель одинаково надёжно удержит длинный контекст от начала до конца. Особенно это заметно в сценариях вроде:
- обработки обращений из формы или чата;
- разборов FAQ и базы знаний;
- генерации ответов по длинному брифу;
- AI-search и семантической выдачи;
- многошаговых промптов с условиями и исключениями.
Авторы также описывают слабое место в операции REMOVE: модель может подавлять ненужное не точечно, а через общий «глобальный» механизм. Отсюда — странные сбои, когда лишняя сущность вроде бы удалена, но продолжает влиять на ответ.
Что это значит для no-code операторов:
- выносите ключевые сущности ближе к началу промпта;
- не прячьте ограничения в конце длинного текста;
- дробите сложные задачи на несколько коротких шагов;
- в автоматизациях лучше передавать модели уже нормализованный контекст, а не «сырой поток»;
- для критичных сценариев добавляйте промежуточную проверку полей и сущностей.
Для маркетолога и оператора это не академическая мелочь, а вопрос качества системы. Если LLM собирает смысл «на финише», то структура данных и порядок блоков начинают влиять на результат не меньше, чем сам текст.
Свежая arXiv-работа 2605.30233 хорошо объясняет один неприятный эффект в работе языковых моделей: они не обязательно ведут внутреннее состояние шаг за шагом, пока читают текст. По сути, нужные детали могут собираться не постепенно, а ближе к финалу — когда запрос уже стал полностью понятен.
Практический вывод для no-code автоматизаций и маркетинговых сценариев простой: если вы строите цепочку на LLM, нельзя рассчитывать, что модель одинаково надёжно удержит длинный контекст от начала до конца. Особенно это заметно в сценариях вроде:
- обработки обращений из формы или чата;
- разборов FAQ и базы знаний;
- генерации ответов по длинному брифу;
- AI-search и семантической выдачи;
- многошаговых промптов с условиями и исключениями.
Авторы также описывают слабое место в операции REMOVE: модель может подавлять ненужное не точечно, а через общий «глобальный» механизм. Отсюда — странные сбои, когда лишняя сущность вроде бы удалена, но продолжает влиять на ответ.
Что это значит для no-code операторов:
- выносите ключевые сущности ближе к началу промпта;
- не прячьте ограничения в конце длинного текста;
- дробите сложные задачи на несколько коротких шагов;
- в автоматизациях лучше передавать модели уже нормализованный контекст, а не «сырой поток»;
- для критичных сценариев добавляйте промежуточную проверку полей и сущностей.
Для маркетолога и оператора это не академическая мелочь, а вопрос качества системы. Если LLM собирает смысл «на финише», то структура данных и порядок блоков начинают влиять на результат не меньше, чем сам текст.
Почему качество LLM зависит не только от модели, но и от того, где она «передумывает»
В обсуждениях ИИ обычно сравнивают сами модели: параметры, контекстное окно, результаты тестов. Но всё чаще преимущество появляется на уровне инфраструктуры генерации ответа.
Недавняя исследовательская работа описывает подход, при котором система анализирует ход рассуждений модели и ищет моменты максимальной неопределённости. Вместо того чтобы пересчитывать весь путь целиком, алгоритм возвращается только к таким узловым точкам и строит альтернативные варианты решения именно там.
Для no-code специалистов это интересный сигнал. Многие привыкли считать, что качество ответа определяется промптом и выбранной моделью. На практике всё большее значение получают механизмы между запросом и финальным результатом: повторная генерация отдельных фрагментов, ранжирование вариантов ответа, фильтрация промежуточных шагов и другие техники постобработки.
Отсюда важный вывод для тех, кто собирает автоматизации на базе LLM. Если вчера один и тот же сценарий в no-code платформе выдавал средний результат, а сегодня стал заметно точнее, причина может быть вовсе не в обновлении модели. Провайдер мог изменить внутренние правила генерации и выбора ответов.
Поэтому при оценке AI-инструментов стоит смотреть не только на название модели в настройках. Всё чаще конкурентное преимущество создают скрытые слои оркестрации: как система перебирает варианты, в каких местах пересматривает ход рассуждений и по каким критериям выбирает финальный ответ. Именно там сейчас происходит значительная часть реального прогресса в качестве ИИ-сервисов.
В обсуждениях ИИ обычно сравнивают сами модели: параметры, контекстное окно, результаты тестов. Но всё чаще преимущество появляется на уровне инфраструктуры генерации ответа.
Недавняя исследовательская работа описывает подход, при котором система анализирует ход рассуждений модели и ищет моменты максимальной неопределённости. Вместо того чтобы пересчитывать весь путь целиком, алгоритм возвращается только к таким узловым точкам и строит альтернативные варианты решения именно там.
Для no-code специалистов это интересный сигнал. Многие привыкли считать, что качество ответа определяется промптом и выбранной моделью. На практике всё большее значение получают механизмы между запросом и финальным результатом: повторная генерация отдельных фрагментов, ранжирование вариантов ответа, фильтрация промежуточных шагов и другие техники постобработки.
Отсюда важный вывод для тех, кто собирает автоматизации на базе LLM. Если вчера один и тот же сценарий в no-code платформе выдавал средний результат, а сегодня стал заметно точнее, причина может быть вовсе не в обновлении модели. Провайдер мог изменить внутренние правила генерации и выбора ответов.
Поэтому при оценке AI-инструментов стоит смотреть не только на название модели в настройках. Всё чаще конкурентное преимущество создают скрытые слои оркестрации: как система перебирает варианты, в каких местах пересматривает ход рассуждений и по каким критериям выбирает финальный ответ. Именно там сейчас происходит значительная часть реального прогресса в качестве ИИ-сервисов.
Метка «сделано человеком» влияет на оценку сильнее, чем сам текст
В одном онлайн-эксперименте 505 участников читали комментарии с логическими ошибками и оценивали их в нескольких вариантах: без указания автора, как текст от человека, как текст от ИИ, а также в смешанных сценариях — человек с помощью ИИ и ИИ с помощью человека.
Итог любопытный: одна и та же формулировка воспринималась по-разному, если рядом стояла метка источника. То есть люди оценивали не только качество текста, но и свою степень доверия к нему.
При этом языковые модели вроде GPT-5.2, Gemini 2.5 Flash и Claude были заметно стабильнее: на их оценки ярлык «human» или «AI-assisted» влиял гораздо меньше.
Для no-code и маркетинговых команд это важный практический сигнал. Когда вы проверяете тексты, карточки, ответы саппорта, описания товаров или генерацию для лендинга, не стоит смешивать два разных фактора:
- насколько текст действительно хорош;
- кто его якобы сделал.
Иначе ручная оценка начинает «плыть» не из-за качества материала, а из-за этикетки.
Это особенно заметно в A/B-тестах, контентной модерации и при разметке данных для AI Search: одна и та же формулировка может получить разные баллы только потому, что аудитория видит слово «AI».
Вывод простой: если в процессе есть ИИ, фиксируйте это отдельно от оценки результата. Иначе вы будете оптимизировать не текст, а реакцию на подпись.
В одном онлайн-эксперименте 505 участников читали комментарии с логическими ошибками и оценивали их в нескольких вариантах: без указания автора, как текст от человека, как текст от ИИ, а также в смешанных сценариях — человек с помощью ИИ и ИИ с помощью человека.
Итог любопытный: одна и та же формулировка воспринималась по-разному, если рядом стояла метка источника. То есть люди оценивали не только качество текста, но и свою степень доверия к нему.
При этом языковые модели вроде GPT-5.2, Gemini 2.5 Flash и Claude были заметно стабильнее: на их оценки ярлык «human» или «AI-assisted» влиял гораздо меньше.
Для no-code и маркетинговых команд это важный практический сигнал. Когда вы проверяете тексты, карточки, ответы саппорта, описания товаров или генерацию для лендинга, не стоит смешивать два разных фактора:
- насколько текст действительно хорош;
- кто его якобы сделал.
Иначе ручная оценка начинает «плыть» не из-за качества материала, а из-за этикетки.
Это особенно заметно в A/B-тестах, контентной модерации и при разметке данных для AI Search: одна и та же формулировка может получить разные баллы только потому, что аудитория видит слово «AI».
Вывод простой: если в процессе есть ИИ, фиксируйте это отдельно от оценки результата. Иначе вы будете оптимизировать не текст, а реакцию на подпись.
Дообучение AI-модели: скорость адаптации или стабильность прошлых навыков?
Когда вы настраиваете AI-агента под новую задачу — например, под ответы на частые вопросы по продукту — важно понимать, как метод обучения влияет на его прежнее поведение. Исследователи на Qwen2.5-3B-Instruct сравнили два подхода: supervised fine‑tuning (SFT) и reinforcement learning (RL).
Результат: SFT быстрее подстраивается под новый сценарий, но при этом сильнее ломает цепочки рассуждений, которые модель выучила раньше. RL дольше адаптируется, зато почти не трогает старые паттерны. Для практики это значит, что если вы дообучаете модель для одного узкого запроса, через SFT она может начать хуже отвечать на смежные темы.
Для no‑code операторов и маркетологов, использующих AI‑оверлеи, умные чат-боты или генерацию контента, это прямой сигнал. Допустим, вы натренировали бота на документации по одному сервису, а потом захотели добавить информацию о новом. Выбор метода обучения определит, сохранится ли точность по старым вопросам. RL даёт более устойчивую базу, хотя и требует больше времени на настройку.
В связке с инструментами вроде AI Overviews или персонализированных сниппетов стабильность ответов критична — дрейф формулировок может ударить по органике и пользовательскому опыту. Итог: при выборе способа дообучения смотрите не только на метрики новой задачи, но и на то, как модель держит привычные сценарии.
Когда вы настраиваете AI-агента под новую задачу — например, под ответы на частые вопросы по продукту — важно понимать, как метод обучения влияет на его прежнее поведение. Исследователи на Qwen2.5-3B-Instruct сравнили два подхода: supervised fine‑tuning (SFT) и reinforcement learning (RL).
Результат: SFT быстрее подстраивается под новый сценарий, но при этом сильнее ломает цепочки рассуждений, которые модель выучила раньше. RL дольше адаптируется, зато почти не трогает старые паттерны. Для практики это значит, что если вы дообучаете модель для одного узкого запроса, через SFT она может начать хуже отвечать на смежные темы.
Для no‑code операторов и маркетологов, использующих AI‑оверлеи, умные чат-боты или генерацию контента, это прямой сигнал. Допустим, вы натренировали бота на документации по одному сервису, а потом захотели добавить информацию о новом. Выбор метода обучения определит, сохранится ли точность по старым вопросам. RL даёт более устойчивую базу, хотя и требует больше времени на настройку.
В связке с инструментами вроде AI Overviews или персонализированных сниппетов стабильность ответов критична — дрейф формулировок может ударить по органике и пользовательскому опыту. Итог: при выборе способа дообучения смотрите не только на метрики новой задачи, но и на то, как модель держит привычные сценарии.
Почему одни AI-ответы «плывут» после обновления, а другие держатся ровно
В исследованиях на Qwen2.5-3B-Instruct сравнили два способа дообучения модели на задаче scientific QA: supervised fine-tuning и reinforcement learning. Итог полезен не только для ML-команд, но и для тех, кто строит процессы вокруг AI-поиска и ассистентов.
SFT быстрее подгоняет модель под нужный формат ответа, но заметно сильнее перестраивает внутренние связи. На практике это означает: модель может лучше попадать в целевую задачу, но при этом чаще терять прежние навыки и стабильность. RL, наоборот, меняет поведение мягче: обучается медленнее, зато лучше сохраняет базовую «архитектуру» ответа.
Для no-code и martech-операций это важный сигнал. Если вы используете LLM в чат-ботах, генерации контента, AI Overviews или поисковых сценариях, резкие обновления модели могут менять не только стиль, но и логику выдачи. Сегодня ассистент уверенно отвечает одним способом, а после нового тюнинга начинает по-другому формулировать, иначе выбирать факты или терять часть контекста.
Что из этого следует для операторов:
- при внедрении AI-сценариев тестировать не один ответ, а набор одинаковых запросов;
- смотреть не только на точность, но и на повторяемость;
- отдельно проверять, как обновление модели влияет на шаблоны, извлечение фактов и цитирование.
Иными словами, для рабочих no-code сборок важна не только «умность» модели, но и её предсказуемость после очередного обновления.
В исследованиях на Qwen2.5-3B-Instruct сравнили два способа дообучения модели на задаче scientific QA: supervised fine-tuning и reinforcement learning. Итог полезен не только для ML-команд, но и для тех, кто строит процессы вокруг AI-поиска и ассистентов.
SFT быстрее подгоняет модель под нужный формат ответа, но заметно сильнее перестраивает внутренние связи. На практике это означает: модель может лучше попадать в целевую задачу, но при этом чаще терять прежние навыки и стабильность. RL, наоборот, меняет поведение мягче: обучается медленнее, зато лучше сохраняет базовую «архитектуру» ответа.
Для no-code и martech-операций это важный сигнал. Если вы используете LLM в чат-ботах, генерации контента, AI Overviews или поисковых сценариях, резкие обновления модели могут менять не только стиль, но и логику выдачи. Сегодня ассистент уверенно отвечает одним способом, а после нового тюнинга начинает по-другому формулировать, иначе выбирать факты или терять часть контекста.
Что из этого следует для операторов:
- при внедрении AI-сценариев тестировать не один ответ, а набор одинаковых запросов;
- смотреть не только на точность, но и на повторяемость;
- отдельно проверять, как обновление модели влияет на шаблоны, извлечение фактов и цитирование.
Иными словами, для рабочих no-code сборок важна не только «умность» модели, но и её предсказуемость после очередного обновления.