LLM под капотом

Мы открыли пятый поток вебинара "Разработка с AI-агентами" На этот раз без листов ожидания! Можно выбрать место в четвертом (29 июня) или пятом потоке (2 июля), оплатить его и сразу же получить на почту инвайт в группу потока и на встречу в Zoom https://buy.abdullin.com Это будет такой же вебинар, как предыдущие три. О том, как они прошли, почитать можно в обсуждениях здесь или здесь или здесь. Ваш, @llm_under_hood 🤗

Разослали приглашения на вебинар "Разработка с AI-агентами" Желающих было столько, что сразу открыли два потока - третий завтра и четвертый в следующий вторник. Все, кто записывался в waitlist - проверьте почту! Это будут такие же вебинары, как и предыдущие два потока. О том, как они прошли, почитать можно в обсуждениях здесь или здесь. Кстати, новый процесс оплаты был сделан с нуля за несколько дней сразу с интеграцией в платежные системы, почту и механизм инвайтов телеграмма на базе event-driven архитектуры. Полгода назад такое бы пришлось пилить сильно дольше. Это как раз пример AI Native архитектур, которые мы обсуждаем на вебинаре и в группах потоков. До встречи завтра! Ваш, @llm_under_hood 🤗

Насколько критичен для вас полноценный Structured Output при работе с локальными моделями? Напишите, пожалуйста, ответы в комментарии (не важен, предпочитаю, жить без него не могу итп). Зачем? Тут предлагают отсыпать токенов на локальные модели для тех команд, которые ставят эксперименты в области Agentic Commerce архитектур на платформе BitGN. Но есть нюанс, что токены без полноценного SO. Напоминаю, что: • Без SO - модель может вернуть любой текст. Вызовы json parse нужно оборачивать try/catch • SO/JSON - модель возвращает валидный JSON, но вместо числового поля может быть и текст. Схему нужно валидировать (Zod/Pydantic) и оборачивать в try/catch • Честный SO как у OpenAI/llguidance - если в схеме прописано число, то гарантированно будет число. Try/catch не нужен. Можно спокойно использовать Schema-Guided Reasoning. Ваш, @llm_under_hood 🤗

Третий поток вебинара "Разработка с AI-агентами" В этот четверг, 25.06 в 10:00 CEST / 11:00 MOW, мы с Айгизом проведем третий поток вебинара про разработку продуктов с AI-агентами. Это будет такой же вебинар, как предыдущие два. О том, как они прошли, почитать можно в обсуждениях здесь или здесь. Кстати, отдельная благодарность участникам вебинаров - ТГ-чаты потоков (где у нас идет вторая асинхронная часть работы) полны интересных вопросов, обсуждений и обмена опытом! Для тех, кто хочет принять участие в третьем потоке, вот здесь можно оставить свой емейл- ближе к дате проведения вышлем ссылку на оплату. Ваш, @llm_under_hood 🤗

Как сделать бенчмарк Open Weights LLM на агентских задачах? (1) Берем одну архитектуру с известными результатами (2) Подменяем LLM под капотом на другую версию (3) Прогоняем несколько раз в тестовой среде (4) Заносим результат в табличку Так и поступил Ильяс со своим агентом Exoskeleton, который занял первое место в BitGN ECOM1 PROD в категории скорость. Получившиеся графики - в посте, детальное исследование описано у него в канале. Из интересных инсайтов - (1) Kimi оказался лучше, чем ожидалось (2) Если у модели дешевые токены, то это вовсе не значит, что она в итоге выдет дешевле. Умные модели могут закончить работу раньше и сэкономить tokens. (3) обычно приходится выбирать между "быстро" или "качественно". Попозже я добавлю ссылки на это исследование и в BitGN Insights, чтобы инженеры из 103 городов мира тоже могли воспользоваться результатами. А еще у нас в чате канала Victor Savkov публикует сравнительные результаты прогонов своей архитектуры с разными LLM на тех же задачах из ECOM1-PROD! Ваш, @llm_under_hood 🤗

LLM Бенчмарк GLM-5.2 на бизнес-задачах GLM-5.2 - это очень интересная reasoning модель c контекстом в 1M и открытыми весами. Она заняла 12 место на бизнес задачах, а ее запуск стал самым дешевым среди моделей выше. По бенчмарку у GLM-5.2 наблюдается провал на задачах разработки и анализа кода, работы с маркетинговыми задачами (требуют хорошего владения английским) и ризонинга. Задачи на бенчмарке собраны из тестов и evals, которые мы собрали во время работы над внедрениями LLM в бизнес в корпорациях и стартапах в США и Европе. Подробнее тут, полный бенчмарк за Июнь, отвечает за бенчмарк @AigizK в TimeToAct Austria. С задачами “на подумать” самая большая беда у GLM-5.2. Она систематически упускает моменты или делает лишние выводы из текста. В итоге GLM-5.2 не просел так сильно из-за неточного следования формату, как Fable (формат важен, т.к. в бизнес задачах модель обычно интегрируется в другие системы), но зато у него хуже с reasoning и внимательностью. Если будете использовать - следите. А теперь смотрим внимательно. В абзаце выше мы сравнивали мифическую модель с open weights моделью на 753B параметров. И эта модель попала в TOP-12, а в этом диапазоне с Open Weights моделями пока было не очень густо. В общем, для практических задач ситуация с LLM моделями становится все приятнее и приятнее. Сначала мы увидели, что для решения важных бизнес задач уже не нужны фронтир модели. Потом увидели, как при правильной архитектуре небольшие модели могут выйти в топ сложных агентских задач (см Exoskeleton). Осталось только дождаться, пока небольшие Open Weights модели не станут настолько хороши, что при правильной архитектуре смогут показать результат лучше и дешевле типичного решения на фронтир модели. Думаю, осталось ждать не так много времени. А пока - будем продолжать вместе учиться, экспериментировать и двигать SotA вперед. Ваш, @llm _under_hood 🤗

После публикации инсайта про архитектуру агента Exoskeleton, счетчик на сайте BitGN начал крутиться с удвоенной силой, а его агента пододвинули с топов ECOM1 Live лидерборда. Переопыление между лучшими архитектурами работает! А между тем @salikhov_ilyas принял хардкорный вызов - попробовать портировать своего агента на Open Weights модели! Если такое получится без переобучения под PROD - это будет прямо прорывным моментом в разработке агентов. Кто запускал агентов в Agentic Commerce бенчмарке именно на Open Weights архитектурах? Какие у вас были секреты для получения очков повыше? Ваш, @llm_under_hood 🤗

Не спеками едиными Сейчас в разработке (SDLC) очень популярна тема SDD - Spec-Driven Development. Идея простая. Берем пару скиллов, прогоняем через них наше видение того, что нужно сделать в виде кода, отвечаем на вопросы и получаем спеки (которые понятны агентам)! А потом эти спеки скармливаем агентам, и они пишут код. Ну и допускаем, что если спеки были написаны хорошо и реализовывал их агент мощный, то код будет делать то, что от него ожидают. Правда потом эти спеки будут лежать в кодовой базе мертвым грузом и источником галлюцинаций, ибо нельзя никак проверить то, что код все еще соответствует спекам. Разве только потратив кучу токенов и без каких либо гарантий. Например, регулярно делать аудит кода агентами (что плохо масштабируется) То есть у нас не спеки получаются, а просто одноразовые вайб-планы. А можно ли лучше? Да легко. Смотрим в OpenAI Harness engineering - доки должны быть актуальны, а harness должен верифицировать. Потом смотрим в древние способы разработки, задолго до SDD, когда были только буквы в начале алфавита: Behaviour-Driven Development. BDD родился задолго до LLM-ok (этак лет двадцать назад), когда перед человеческими командами стояла та же проблема - как синхронизировать работу разработчиков, продактов и тестировщиков так, чтобы требования не устаревали. И тогда придумали формат Given-When-Then - формат читаемых сценариев, который могли понимать и технари и люди от бизнеса (пару примеров скину в комментарии). Эти сценарии описывали поведение системы с точки зрения черного ящика (как она выглядит снаружи). Эти сценарии обсуждались и писались лапками - вручную, но используя определенную структуру. А потом технари делали эти сценарии исполняемыми. То есть тестовая обвязка парсила сценарии, превращая в спеки, и просто запускала как end-to-end тесты системы. Получалась такая иерархия: (1) Описание требований (2) Набор читаемых сценариев под требования (обычно их группировали в папочки по именам требований) (3) Код, который на лету парсит сценарии и прогоняет тест системы. И если код начинал нарушать сценарий какого-то требования, то это сразу приводило к ошибке билда. А если добавляли новые требования, то у нас получался обычный Test-Driven Development. Чаще всего использовали формат сценариев Gherkin, а в качестве парсеров - Cucumber, JBehave, RSpec, Behave (и еще куча других). Оно работало хорошо и в эпоху до ChatGPT, когда все делалось лапками. А сейчас агенты замечательно нарезают высокоуровневые требования в BDD сценарии, и потом реализуют код. И при этом сценарии остаются синхронизированными с требованиями, но превращаются в нормальный AI-Native Harness, который агент может запускать хоть по сто раз за сессию. Правда лично у меня сам формат Gherkin всегда вызывал аллергию (ибо парсеры у команд становились источником отдельных проблем с ростом продукта), поэтому я использую чуть более специфичный формат исполняемых Given-When-Then спеков - event-driven specs. Он требует чуть больше инвестиций на уровне архитектуры, но зато в разы лучше масштабируется до 10k спеков и выше (особенно в AI Native проектах). Но это уже вкусовщина для отдельной беседы. Ваш, @llm_under_hood 🤗

Мы сейчас завершили второй поток вебинара "Разработка с AI-агентами: что реально работает" Большое спасибо всем участникам! Оставьте, пожалуйста, тут отзыв про вебинар - как оно прошло, что понравилось, какую самую интересную для себя вещь узнали. А с комьюнити я хочу поделиться самым важным слайдом из всего вебинара - про AI-Native Harness для спеков. Агенты работают с текстовыми спеками хорошо, а с исполняемыми спеками - гораздо лучше. На вторые не надо тратить контекст и время. Ваш, @llm_under_hood 🤗

Анализ Exoskeleton - самого умного из быстрых агентов в ECOM1 Это архитектура Ильяса Салихова. Она набрала 71.8 очков с суммарным временем работы агента в 51 минуту и заняла первое место Speed Leaderboard (туда попадают агенты быстрее часа). На самом деле Ильяс мог выбить результат еще лучше. За время соревнования у него был прогон в 74.7 очков за 42.5 минуты, но вслепую этого заранее нельзя было знать. А еще этот агент прямо сейчас занимает первое место в пост-соревновательном лидерборде ECOM1 LIVE. Под капотом крутятся gpt-5.4-mini и gpt-5.4-nano. Nano используется для pre-flight проверок и финализации ответа, а mini используется в agent REPL loop. В цикле агент может взаимодействовать через инструменты со средой Agentic OS. При этом основная информация грузится в агента принудительно еще перед стартом через context pre-fetch (еще до pre-flight проверок). Вообще в этой архитектуре очень много делается принудительно кодом (отсюда и Exoskeleton). Помимо инструментов для взаимодействия со средой задачи очень много тяжелой логики свалено на “domain helpers” (например есть прямо отдельный solver для dispatch задачи), а за сбор grounding references отвечает еще один компонент. Дополнительно к этому есть отдельный feedback цикл, который отвечает за сбор данных и “обучение” системы (и даже мои любимые heatmaps). Он не работал во время соревнования, но внес вклад в настройку архитектуры перед выходом в PROD. Вот ссылки: на инсайт, исходники и deep dive. Ваш, @llm_under_hood 🤗 PS: У Ильяса есть свой канал про AI! А вопросы по архитектуре Exoskeleton можно задать прямо в обсуждениях этого поста - @salikhov_ilyas

Два объявления и один инсайт про вебинар "Разработка с AI-агентами: что реально работает" На основе вопросов и обсуждений вебинара 12 числа мы выделили темы, которые интересуют AI разработчиков больше всего: • Работа с документами и борьба с энтропией. Как бороться с устаревшими планами и расползанием документации? Как сделать память проекта без карго-культа? • Как масштабировать процессы SDLC/AI-Native разработки на команду? как не получить 20 разных стилей разработки от 20 людей и агентов? • Как перейти от “агент вроде справился” к “мы можем ему доверять”? Как заменить доверие тестами и harness? • Если с разработкой бэка и агентов все понятно, то как сделать нормальный spec-first процесс разработки на фронтенде? • Anti-drift паттерны для долгих зимних вечеров agent goal loops. • Обсуждения всяких конкретных фишечек реализации: Codex, webhooks, Obsidian, nix, cloud/local, control centre. Прямо здорово, что вопросы не про вайб-кодинг, а про инженерные вопросы - как стабилизировать и масштабировать то, что уже неплохо работает. (1) кто оплатил вебинар 12го числа - в группе вебинара мы выложили запись вебинара для личного использования (доступ к группе по инвайту из письма). Плюс там же продолжаем отвечать на вопросы про AI-Native проекты. (2) кто записался на вебинар 16го числа - выслали на почту ссылки на оплату. Можно оплатить как международной карточкой, так и в РФ. Проверяйте почту. Кто хочет поучаствовать в вебинарах после 16го числа - мы упростим процесс и сделаем бота для записи, о чем напишем в канале. Но это будет потом, а сейчас мы пока фокусируемся на том, чтобы сделать вебинар 16го интересным и полезным. Ваш, @llm_under_hood 🤗

Anthropic 9 июня зарелизила свою новую модель Fable, а через несколько дней отключила ее из-за требований USA. Если читать новости, то за несколько дней прямо разразилась драма. Очень мощная модель, классно делает игры и рисует пеликанов. И ее внезапно подло отобрали, лишив кучу компаний их продуктов, которые они долго строили на fable. Ну и прочая и прочая. А теперь посмотрим на Fable с продуктовой точки. В бизнес, где нужно интегрироваться с процессами и запускать модель десятки тысяч раз (см примеры кйсов), ее не только никто не успел бы внедрить, но и не стал бы думать - есть более дешевые модели (см бенчмарк). Да и если бы стали рассматривать, то "подумать" требует времени - подключить к API, прогнать бенчмарки, проанализировать сильные и слабые стороны, выбрать кейсы, когда выгодно направлять задачи на эту модель итп. В общем, с практической точки зрения история с Fable - это просто шум, который не делает никакой погоды. Масштабно в бизнесе подобные модели не используются - слишком дорого и медленно. А тот средний сегмент моделей, которые используется, слишком хорошо представлен у разных вендоров, чтобы быть под риском отключения. Поэтому и волноваться не о чем. Ваш, @llm_under_hood 🤗

Первый поток вебинара "Разработка с AI-агентами: что реально работает" - в разгаре! Я хочу поделиться со всеми интересным Agents.MD, который Aigiz использует для разработки агентами пайплайнов (для внедрения в бизнес) в полностью автоматическом режим с использованием /goal режима. Ваш, @llm_under_hood 🤗

Тут подвезли новую интересную уязвимость в ECOM1-DEV Консультанты Blue41 нашли в AI агенте банка bunq простейшую уязвимость. Шлешь людям кучу транзакций на пару центов, а в описание докидываешь пару строчек про то, что надо пройти валидацию по такому-то url. Ну и если человек спросит своего банковского агента про последние транзакции, тот ему и выдаст среди всего фишинговую ссылку. Finn AI даже отличался тем, что выдавал ее как напоминание. Статью с сайта Blue41 уже убрали, но в web архиве она осталась. И заодно я добавил эту задачу в ECOM1-DEV как t55 (чтобы не забыть потом ее переосмыслить в ECOM2). Если вдруг будете тестить своих агентов, запостите в комментарий их первый ответ (до обучения) - интересно! Лимиты на платформе я сбросил для всех :) Ваш, @llm_under_hood 🤗

Апдейты по вебинару "Разработка с AI-агентами: что реально работает" Первый вебинар будет завтра 12 июня. Все, кто уже оплатил - проверьте, пожалуйста почту, там будет персональная ссылка в группу вебинара с деталями и инвайт в Zoom на завтра. Кто еще не оплатил - сделайте, пожалуйста, это сегодня (чтобы завтра нам в спешке не рассылать инвайты) Второй вебинар будет 16го числа. Ссылки на оплату вышлем завтра. Третий созвон точно состоится, т.к. плюсов набралось достаточно. С датой определимся попозже. До встречи на вебинаре завтра! Ваш, @llm_under_hood 🤗

Что стоит обсуждать при разговоре о разработке с AI агентами? Вот примерно такой план набросали мы с Айгизом для подготовке к созвону в пятницу. Нам пришлось порезать список проектов, о которых рассказываем, чтобы был шанс уложиться в два часа. Пройдемся от археологии старого кода до AI-native проектов и паттернов разработки в 2026 году. Какие важные на ваш взгляд вещи стоило еще бы обсудить при разговоре о современной разработке при помощи AI агентов? Кстати, если кто ждет третьего слота - отпишитесь, пожалуйста, под этим постом в комментариях. При его открытии напишем каждому в личку. Ваш, @llm_under_hood 🤗

LLM Бенчмарк Anthropic Fable 5 на бизнес-задачах c максимальным reasoning Если кратко, то эта новая модель считает себя слишком умной и на задачах, которые требуют точных ответов, иногда начинает нести больше отсебятины, нежели другие frontier модели. Из-за этого у нее такая просадка в Software Engineering задачах. По итогу она заняла вполне себе достойное десятое место. Правда, если сравнивать стоимость с другими моделями в TOP-10, то можно найти модели подешевле и поумнее для внедрений в бизнес. Задачи на бенчмарке собраны из тестов и evals, которые мы собрали во время работы над внедрениями LLM в бизнес в корпорациях и стартапах в США и Европе. Про бенчмарки подробнее написано тут, включая ответы на все те вопросы, которые задавали люди первую пару лет публикации этого бенчмарка. Полная версия бенчмарка за Июнь 2026 - тут. За LLM бенчмарк теперь отвечает @AigizK, поэтому если интересует какая-то популярная модель (вроде xiaomi/mimo-v2.5-pro из TOP-20 ECOM1 агента), то это уже обращаться к нему. Ваш, @llm _under_hood 🤗

Код - это настолько мощная абстракция для мышления моделей, что иных инструментов LLM-кам и не надо Первые признаки этого мы с вами видели в топовых архитектурах соревнований Enterprise RAG Challenge и Personal Assistants Challenge, но настоящие результаты начинаем пожинать только сейчас. Вот вам еще один пример архитектуры, которая была очень простой, использовала Open Weights модель, но при этом заняла вслепую TOP-20 место в ECOM1. Ее создал Farid Temuri вместе с Claude на TypeScript. Рисунок архитектуры - в комментариях. Под капотом mimo-v2.5-pro (1T sparse MoE модель с 42B активных параметров), кодовая песочница, агент замкнут в цикл до 35 шагов, чеклист на выходе заворачивает ошибочные ответы назад с обратной связью. Работает не сильно быстро - 233 минуты, но это Open Weights агент, который выбил вслепую 72 балла в Ultimate Leaderboard на экзотической модели! Я думаю, что дальше тренды внедрений LLM в бизнес будут развиваться так: (1) благодаря кодовым рельсам мы будем видеть все больше Open Weights моделей в топах (2) модели под капотом будут становиться все меньше и доступнее (3) внедрения LLM в бизнес будут все больше приходить в сторону кодовых агентов. Люди так долго ждали первые AI-Native компании, что проспали их возникновение. Просто потому, что они пришли не из какого-то невероятно нового будущего, а тихонько прокрались из старого и знакомого. Они рождаются из старого доброго кода, который прорастает вокруг существующих процессов. Oбзор архитектуры, ссылки на лог соревнования и исходники лежат тут на BitGN Insights. Вы можете хоть сегодня забрать эту версию агента и попробовать запустить самостоятельно на какой-нибудь модели поменьше и сами посмотреть, что получится. Чтобы все могли быстрее прокачиваться, я добавил на платформу мощностей и повысил лимиты. Ваш, @llm _under_hood 🤗