Привет, на связи команда BI-разработчиков коммерческого департамента: Алексей Дубинец и Павел Беспалов. 

В статье расскажем, как построили пайплайн миграции наших витрин с помощью локальной LLM. 

Сразу оговорюсь: это не история про то, как мы дали в Codex или Claude Code, написали скилл и получили магический результат. Покажем инженерную часть задачи: где локальная модель срабатывает не так, какие наивные решения не работают и что пришлось построить вокруг неё, чтобы перевод стал воспроизводимым.

Пятьдесят дней назад планирование моих тренировок переехало из головы и переписки в телеграм-бота. Он читает восстановление из WHOOP и форму из TrainingPeaks, рассуждает через Claude и сам пишет структурированные тренировки обратно в календарь — оттуда они уезжают в Garmin Connect и на часы. За это время он записал в календарь 72 тренировки, а стоимость эксплуатации (дроплет, инференс, подписки) составила около 4 500 рублей в месяц против 30 000+ за живого тренера с теми же подписками на спортивные сервисы.

Официального доступа к TrainingPeaks у меня нет: в партнёрскую программу я написал и получил отказ без объяснения причин. В статье — как я всё равно научился писать в чужой календарь: обмен куки веб-сессии на bearer, GET-merge-PUT вместо несуществующего PATCH, поле, которое на чтении приходит объектом, а на запись требует JSON внутри JSON, и почему IF и TSS плановой тренировки приходится считать самому.

Вторая половина — про то, где это ломалось. Три отказа за пятьдесят дней, и ни один не был виной модели: устаревший в настройках пороговый темп, мой собственный баг с зонами не того вида спорта, один невалидный OAuth-scope, отбивавший запрос согласия целиком, и ответы, обрывавшиеся на полуслове из-за параметра, у которого «по умолчанию» значит разное у разных моделей. Плюс три дня, когда я был уверен, что агент зря меня бережёт, — а данные говорят, что прав был он.

Спортивного результата пока нет: до целевого марафона сто дней, но надеюсь на лучшее.

И снова возвращаюсь к теме больших языковых моделей. В своей достаточно старой статье я писал, что текущая архитектура БЯМ(LLM) — это гонка в тупик. Наблюдения за прошедшее время только укрепляют меня в этом мнении. Но сегодня хочу поговорить о другом, а что если тупик — это не конец пути, а просто барьер, за которым нас ждет технологическая революция? И почему те, кто сейчас вкладывает сотни миллиардов в дата-центры, сделают всё, чтобы эта революция не случилась? Разберем по порядку.

BI снова хоронят: подключаем LLM к хранилищу и аналитики больше не нужны, деньги тратить на лицензии не нужно. По крайней мере, так выглядит обещание.

На практике дата-агент может написать корректный SQL, получить верные цифры и всё равно уверенно ответить не на тот бизнес-вопрос. Он путается в определениях метрик, теряет права пользователя, дорого ходит по кругу и иногда рассуждает хуже, когда ему дают больше времени.

Я разобрал свежие кейсы OpenAI, Anthropic и Hex: что действительно улучшает ответы, какие очевидные подходы уже провалились, из чего складывается реальная стоимость и как за шесть шагов проверить

209 тысяч наименований товаров в 150 представительствах записаны по-разному, а обычный join сопоставляет от силы 1% из них. Дата-инженер Дмитрий Дунаев на Вечерней школе Слёрма показал, как эту путаницу разгребли с помощью LLM, эмбеддингов и fuzzy-поиска, а заодно избавили менеджеров от звонков по 5 минут за штуку из бесконечного списка на обзвон.

Из 15 протестированных моделей нужный баланс критериев показала только одна. Какая именно и почему, разбираем в конспекте доклада вместе с чек-листом, когда агента строить стоит, а когда деньги лучше сэкономить.

Когда я только начал применять языковые модели в работе с TIA Portal, всё выглядело довольно привычно. Копируешь в чат фрагмент SCL-кода, описываешь задачу, получаешь объяснение или готовую функцию. Иногда результат можно использовать почти без изменений, иногда приходится долго уточнять контекст.

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

Если ошибка находится в одном блоке, этого может быть достаточно. В реальном проекте всё обычно сложнее. Один сигнал формируется в одном месте, проверяется в другом, сохраняется в DB, затем участвует в нескольких условиях и в итоге влияет на работу совершенно другого участка программы.

Чтобы получить полезный ответ, приходится вручную искать связанные блоки, копировать их в чат, объяснять структуру проекта, передавать сообщения компилятора, а затем снова возвращаться в TIA Portal за очередным фрагментом информации.

В какой-то момент у меня возник простой вопрос: почему модель вообще должна ждать, пока я принесу ей очередной блок? Можно ли дать ей возможность самостоятельно изучить проект TIA Portal, найти нужный код, проверить свои предположения и подготовить изменения?

Так появился OpennessLLM.

Пользователи слышат из ChatGPT собственный голос, внезапные крики и плач. Некоторые из этих историй звучат как байки с Reddit, но похожие сбои OpenAI фиксировала ещё во время тестирования голосовых моделей. Я попробовал разобраться, откуда они берутся и почему современный Voice Mode иногда ведёт себя настолько странно.

На днях говорил с мамой, она довольно часто пользуется ChatGPT. Есть одна формулировка, которая стабильно вызывает у неё ужас: она рассказывает какую-нибудь историю, а модель отвечает ей «у меня мурашки». Если честно, от этих ответов мурашки скорее у моей мамы.

Я каждый раз объясняю, что никаких мурашек там, конечно, нет. Модель подобрала реплику, которая хорошо смотрелась бы в человеческом разговоре. Но чем естественнее и чаще становятся такие ответы, тем сложнее воспринимать их как обычный вывод программы.

Недавно я наткнулся на случай, где эта граница стала ещё менее очевидной. Здесь я бы уже маму не успокоил.

Всем привет, с вами команда MERA.

В прошлом анонсе мы рассказали о новых публичных тестах на рассуждения и обещали, что следующим большим обновлением станет основная текстовая часть MERA. Пришло время выполнить обещание: представляем MERA Text 2.0 — новую версию текстового бенчмарка и, по сути, переосмысление, что сегодня имеет смысл измерять у фундаментальных текстовых языковых моделей.

Первую версию MERA мы начали создавать ещё в 2023 году. В то время бенчмарки хорошо разделяли модели в задачах, которые сегодня кажутся намного проще: знания о мире, логика, причинно-следственные связи, понимание текста, профессиональные и предметные знания. Во многих из этих задач даже сильным моделям было куда расти, и сам факт успешного решения уже многое говорил об их возможностях.

За три года картина заметно изменилась. Модели стали значительно умнее, а вместе с ними изменились и требования к оценке. На прежнем бенчмарке MERA современные SOTA-модели уже достигают, а в отдельных задачах и превышают результаты человека (Human Baseline). Часть тестов постепенно насыщается: верхняя часть бенчмарка сжимается, разница между сильными моделями становится всё менее заметной, а некоторые задачи просто перестают давать нам достаточно новой информации.

Для бенчмарка это естественный жизненный цикл. Если несколько лет назад вопрос был, скорее: «умеет ли модель это делать вообще?», то сегодня всё чаще приходится спрашивать: «где проходят реальные границы её возможностей?».

Поэтому мы решили не просто добавить в старый бенчмарк ещё несколько датасетов. Вместо этого мы пересобрали текстовую оценку вокруг групп навыков, которые пока ещё остаются сложными и содержательными для современных моделей.

Задача звучит как парадокс с порога: как измерить состояние у технической системы, к которой неприменим термин «чувствовать»?

Ответ на этот вопрос можно найти в работе «Can Induced Emotion Bias LLM Behaviors in Sequential Decision Making?». Ее авторы исследовали способность эмоционального контекста влиять принятие решений в цепочке рассуждений LLM. Прямые вопросы об эмоциях заставят модель сымитировать рассуждения и по ним нельзя будет понять реальное их влияние на ее поведение.

Исследователи выстраивали ход эксперимента с нуля: вызывали состояние, похожее на эмоцию, ни разу не озвучив ее; проверяли их соответствие друг другу; и в конце анализировали конкретные решения модели. Давайте посмотрим ход их действий и выводы, к которым они пришли. А это очень интересно и познавательно для тех, кто много работает с нейросетями.

Привет!

Эпоха дикой генерации слопотекста, кажется, заканчивается.

Недавно от Anthropic вышла статья How Claude's Text Watermark Works, которая была посвящена покушению на святое — копирайту на сгенерированный текст и его детекции.

Тема супер интересная и когда один из главных научпоп-исследователей LLM — Себастьян Рашка — подготовил детальный разбор того, как вообще в LLM может быть устроен вотермаркинг, я понял, что надо брать. Я сделал частичный перевод этого разбора — автор очень крутой, но часто долго разгоняется, слишком много извиняется за свои предположения, порой чрезмерно рекламит, а иногда просто нудит и тяжело пишет.

Поэтому публикую чистенькую, вручную переписанную и адаптированную под русский язык версию. Тема очень крутая и горячая, приятного чтения!

В первой статье цикла мы гоняли по нашим тестам Opus 4.8, GPT 5.5 и Gemini 3.1 Pro, во второй устроили дуэль тяжеловесов Claude Fable 5 и GPT 5.5 Pro, в третьей спустились в средний класс, а в четвёртой вывели на ринг китайские флагманы. В комментариях к прошлой части нас спросили о том, что происходит этажом ниже: флагманы флагманами, а работать людям приходится на моделях попроще. Справедливо. Сегодня спускаемся на пару ступеней ниже.

Привет! Я Чичев Максим, работаю руководителем разработки платформенных решений в Петрович-Тех. В этой статье хочу рассказать о том, как я прогнал три LLM трёх весовых категорий через один и тот же харнесс на агентных задачах длиной 2, 3 и 15 шагов — и почему на длинных цепочках тезис «харнесс важнее модели» перестаёт работать.

А вы когда-нибудь задумывались, почему ваша любимая LLM-ка на 70 лярдов параметров, обученная на всем интернете, может с уверенностью университетского профессора выдать, например, что Наполеон изобрел электричество? Откуда это берется?

Долгое время индустрия списывала галлюцинации на плохие данные, кривой RLHF или декодинг. Но группа ученых из Университета Цинхуа залезла внутрь нейросети и нашла конкретных виновников — 0.1% нейронов, которые буквально заставляют модель врать. И это не метафора, это реальные веса в FFN-слоях трансформера.

В этой статье расскажу, что же обнаружили китайские исследователи, как нейроны-галлюцинаторы связаны с чрезмерной уступчивостью модели и почему корень зла лежит в претрейне. Возможно будет любопытно ML- и дата-инженерам, а также всем, кто не хочет быть одураченным в очередном диалоге с GPT-шкой.