MT-Bench: релиз года для тех, кто хочет сравнивать llm без магии и ручного шаманства

MT-Bench — это не «одна цифра для прессы», а многоходовка: модель отвечает на набор диалоговых задач, а потом её ответы оценивают по качеству, полезности и следованию инструкции. Ирония в том, что именно такой тест часто вскрывает разницу между «звучит умно» и «реально умеет».

Если используешь его как model_comparison, держи три правила:
— сравнивай только на одинаковых промптах и одинаковом формате ответа;
— не смешивай MT-Bench с задачами на код или знания: это про диалог, а не про всё на свете;
— смотри не только на средний балл, но и на провалы по отдельным категориям: иногда модель красивая в общем зачёте и очень нервная в длинных ответах.

Ещё один вечный баг: люди читают результат как «победитель лучший везде». Нет. MT-Bench хорошо ловит качество ассистента, но плохо заменяет benchmarks для reasoning, code, factuality и safety. Нормальная практика — собирать стек из нескольких evals, а не молиться на один таблоидный рейтинг.

Используй MT-Bench как фильтр, а не как приговор: если модель там сильна, это хороший знак для chat-UX, но финальный вердикт всё равно дают остальные evals. Может, конечно, ни хуя не взлетит именно в твоём кейсе — и это не баг, а обычная жизнь llm.

Youtube тестирует поиск с AI

YouTube начал тестировать Ask YouTube — поиск с ИИ, где можно задавать вопросы обычным языком и получать не список ссылок, а готовую подборку видео и фрагментов.

Фича уже доступна в США и работает на сложные запросы: если нужно, ИИ уточняет вопрос и подсказывает следующий шаг.

Что это значит для поиска на YouTube и когда новинка дойдёт до других…

➡️ Читайте на сайте: https://aff.top/blog/youtube-testiruet-poisk-s-ai

🧠 Ещё больше инсайтов → в канале AFF.top

Customer data ломается не в сборе, а на стыке ID, событий и прав доступа

Если у вас в CRM, CDP и рекламных кабинетах разные customer_id, дальше начинается зоопарк: дубли, кривой attribution и сегменты, которые нельзя активировать без ручной чистки. Базовое правило: один человек — один master ID, а все внешние ключи должны быть лишь связями.

Схема без боли обычно держится на 3 слоях:
— raw events: как пришло, без «улучшений»;
— normalized profile: почистили email, phone, country, consent;
— activation-ready: только те поля, которые можно безопасно лить в email, push, ads.

Ошибки, которые потом дорого чинить:
— хранить PII в каждом событии, а не в профиле;
— менять названия полей без версионирования;
— смешивать product events и marketing events в одном потоке;
— не фиксировать источник и timestamp на уровне события.

Для customer data важнее не «собрать всё», а заранее решить, что вы сможете удалить, склеить и переотправить. Если этого нет, reverse-ETL превращается в доставку мусора в ещё один инструмент.

Начните с карты идентификаторов и списка обязательных полей для активации. Всё остальное можно нарастить позже.

Z.ai анонсировала новую GLM-5.5

Z.ai готовит релиз флагманской GLM-5.5: модель обещают показать в августе 2026 года.

Главная интрига — рост до 1 трлн параметров при том же контекстном окне в 1 млн токенов. Новинка снова будет заточена под код и агентные задачи.

Почему версия сразу 5.5, без 5.3 и 5.4, и что это может означать для рынка — в блоге.

➡️ Читайте на сайте: https://aff.top/blog/z-ai-anonsirovala-novuiu-glm-5-5

🧠 Ещё больше инсайтов → в канале AFF.top

Telegram запустил собственный сервер для ботов

Telegram запустил собственный сервер для ботов и мани-приложений: теперь backend можно размещать прямо внутри инфраструктуры мессенджера.

Сервер работает на JavaScript/TypeScript, через вебхуки, и позволяет подключать SQL-базу для сбора контактов без посредников.

Пока неясны цена и ограничения — что именно уже можно тестировать, а где скрыт подв…

➡️ Читайте на сайте: https://aff.top/blog/telegram-zapustil-sobstvennyi-server-dlia-botov

🧠 Ещё больше инсайтов → в канале AFF.top

Identity resolution ломают не event'ы, а слабые правила склейки профиля

Если у вас один и тот же человек живёт как guest, email-user и app-user — CDP не “угадает” его магически. Склейка держится на источниках идентификатора и приоритетах: login_id, email_hash, phone_hash, device_id, cookie_id. Без этого один заказ уходит в один профиль, возврат — в другой, а LTV и сегменты начинают врать.

Что обычно должно быть в правилах:
— какой ID считается первичным;
— какие связи разрешены: deterministic только, или ещё probabilistic;
— как долго живёт anonymous-профиль;
— что делать при конфликте: merge, overwrite, keep both.

Самая дорогая ошибка — склеивать по любому совпадению. Один общий email на семью, один девайс у менеджера, пересечение по телефону в CRM — и вы получаете “суперпрофиль” из чужих покупок, писем и отказов. После этого ретаргет бьёт мимо, а триггеры в lifecycle-цепочках начинают сыпать не тем людям.

Проверка простая: берёте 20 реальных кейсов и вручную смотрите цепочку идентификаторов от первого визита до оплаты. Если в логике есть дыры, сначала чините схему событий и правила merge, а уже потом настраивайте activation в CRM и ads. Иначе любая CDP будет просто красивым слоем поверх мусора.

Google картинки станут конкурентом Pinterest

Google Картинки начали превращать в полноценную платформу с персональной лентой по прошлым запросам — по сути, в аналог Pinterest.

Во вкладке For you уже тестируют подборки, а ещё обещают коллекции и генерацию изображений во встроенной Nano Banana.

Как это будет работать и когда новинка дойдёт до других стран — в блоге.

➡️ Читайте на сайте: https://aff.top/blog/google-kartinki-stanut-konkurentom-pinterest

🧠 Ещё больше инсайтов → в канале AFF.top

Customer Data ломается не в CDP, а в моменте, когда у событий нет хозяина и схемы

Если customer data собирают «по пути», через 3 месяца начинается хаос: один и тот же пользователь в разных форматах, дубли событий, пустые поля, а дальше — кривые сегменты и сломанная активация. CDP тут не спасает, если входной слой грязный.

Рабочий минимум для D2C:
— один владелец за каждую сущность: user, order, product, subscription;
— стабильный event name и обязательные поля;
— отдельные правила для anonymous_id и user_id;
— версионирование схемы, даже если это простой changelog;
— проверка null/empty/duplicate до отправки в warehouse и маркетинг-инструменты.

Самая дорогая ошибка — смешать raw-ивенты и бизнес-атрибуты в одном поле. Тогда «заказ» превращается в мусорный контейнер, а reverse-ETL начинает лить в CRM то, что нельзя использовать для сегментации или триггеров.

Если нет data dictionary и списка обязательных полей, сначала делайте их, потом интеграции. Иначе любая автоматизация будет ускорять не рост, а беспорядок.

Россияне не смогут покупать стейблкоины

Россиянам могут закрыть доступ к покупке стейблкоинов: в новой версии закона их приравняли к иностранным активам.

Купить такие токены смогут только квалифицированные инвесторы — например, с активами от 24 млн рублей или доходом от 12 млн в год.

Что это значит для обычных пользователей и когда правило заработает — в блоге.

➡️ Читайте на сайте: https://aff.top/blog/rossiiane-ne-smogut-pokupat-steiblkoiny

🧠 Ещё больше инсайтов → в канале AFF.top

Reverse-ETL ломается не в коннекторе, а в схеме: 4 места, где теряются деньги

Reverse-ETL — это не «залить аудитории в CRM». Это доставка уже собранных данных из DWH в рабочие системы: CRM, ads, helpdesk, email, product. Если в базе грязь, дубли и неясный ключ пользователя, активировать нечего: сегменты плывут, статусы не совпадают, а команды начинают спорить не о росте, а о том, «у кого правда».

Проверьте 4 вещи до запуска:
— единый ключ идентичности: user_id, email, phone — но один главный, остальные как fallback;
— правила дедупликации: что делать с несколькими событиями, несколькими лидами и merged-профилями;
— freshness SLA: какие поля можно отправлять раз в час, а какие должны обновляться почти сразу;
— идемпотентность: повторная отправка не должна создавать новый лид, сделку или подписку.

Самая частая ошибка — слать в downstream сырые события вместо готовых атрибутов. CRM не любит event-stream, ей нужен понятный профиль: стадия, флаг, сумма, сегмент, причина отказа. Для ads-активации наоборот важны стабильные аудитории и предсказуемый refresh, иначе вы каждый раз обучаете алгоритм на новой каше.

Еще один грабль — маппинг полей без владельца. Пока никто не отвечает за соответствие «source → target», через пару месяцев в одной системе будет last_purchase, в другой last_order_date, а в третьей пусто. Назначайте владельца на каждый критичный атрибут и логируйте ошибки доставки, а не только успехи.

Начинайте reverse-ETL не с «куда лить», а с одного сценария, где есть понятный выигрыш: триггер в CRM, suppression list, возврат неактивных, handoff в саппорт. Когда один маршрут стабилен, масштабировать проще, чем чинить пять полуразобранных.

Customer data ломается не в BI, а на входе: 5 правил, которые спасают схему

Если customer data собрать как попало, дальше уже не поможет ни CDP, ни reverse-ETL. Боль обычно одна и та же: событие назвали по-разному в web и app, часть свойств приходит пустой, а user_id живёт отдельно от email и phone. В итоге сегменты кривые, атрибуция шумит, а активация льёт не туда.

• Делайте одну базовую схему событий: просмотр, add_to_cart, checkout, purchase. Не плодите синонимы.
• Для каждого события фиксируйте обязательные поля: user_id, anonymous_id, timestamp, source, device, currency.
• Отдельно храните identity-ключи и не смешивайте их в одном поле.
• Валидируйте типы: цена — число, дата — дата, статус — enum, а не строка “ok”.
• Все кастомные свойства — через список разрешённых полей, иначе зоопарк вернётся через месяц.

Для customer data важнее не объём, а предсказуемость. Если аналитик не может по схеме понять, что придёт в payload, маркетинг не сможет нормально сегментировать аудиторию, а CDP начнёт разносить мусор по CRM и рекламным кабинетам. Это особенно заметно, когда один и тот же человек приходит с web, app и офлайна.

Самый рабочий тест — взять 10 последних событий и руками проверить: совпадают ли идентификаторы, заполнены ли обязательные поля, нет ли дублей и пустых значений в критичных атрибутах. Если этот чек не проходит, сначала чините схему, потом уже строите активацию.

7 полей customer data, без которых CDP превращается в склад мусора

Customer data ломается не на сборе, а на кривой структуре. Если у события нет стабильного имени, нормального user_id и понятного source, дальше начинается ад: дубли, пустые профили и activation «в никуда».

Минимум, который должен жить в каждой схеме:
— event_name: одно действие = одно имя
— user_id и anonymous_id: чтобы склеивать до и после логина
— timestamp в одном формате
— source / channel / campaign: без этого атрибуция слепая
— properties: только то, что реально нужно для сегментации и триггеров

Отдельно следите за identity resolution. Если email, phone и external_id не описаны как приоритеты склейки, один человек легко превращается в три профиля. Потом CRM шлёт три одинаковых цепочки, а маркетинг думает, что «сработала гипотеза».

Ещё одна частая ошибка — тащить в CDP всё подряд. Не каждый клик нужен в профиле. Лишние поля раздувают схему, усложняют контроль качества и делают reverse-ETL хрупким: одно пустое поле, и отправка в ads/CRM падает.

Держите схему короткой, а правила именования — жёсткими. Чем меньше исключений в customer data, тем дешевле активация и тем меньше ручной починки в аналитике.