Новые LLM в reasoning бенчмарке на бизнес-задачах

- o3-mini и o4-mini очень хороши
- gemini flash preview в thinking режиме заняла третье место
- версии gpt-4.1 (базовая и мини) достаточно хороши, чтобы их использовать из коробки вместо 4o.

OpenAI продолжает лидировать, но Google прямо последовательно дышит в спину. А если учитывать, что OpenAI зависит от NVidia + Microsoft, а Google обучает на своих TPU процессорах, то будущее прямо интересно.

Плюс Google, в отличие от OpenAI, периодически выкладывает открытые модели для использования. За них стоит поболеть отдельно.

Ваш, @llm_under_hood 🤗

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

PPS: А прямо сейчас у меня открыто окно SAP и я выстраиваю reasoning workflow агента для автоматического заполнения Purchase Orders в соответствии с внутренними требованиями компаниями. И шаги из этого процесса пойдут в RPA колонку данного бенчмарка.

Наш чатбот популярен, но как жить дальше?

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

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

При этом у чат-бота нет нормальных тестов на весь функционал и каждый релиз как лотерея. Просто потому, что фич и сценариев использования так много, что нельзя нормально автоматически оценить качество всех бесед. Да и не понятно, как это делать. Статистика об использовании какая-то собирается, но доступа у команды разработки у ней нет, ибо прода находится в другом контуре безопасности.

А еще, поскольку система гибкая и локальная, то приходится держать GPU на терабайты VRAM для мощных моделей. Счета не радуют.

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

Сегодня мне понадобилось ровно два часа, чтобы поменять команде этого чат-бота перспективу с "прибыльное, но беспросветное болото" на "уууу, как тут круто можно сделать". Смотрите самое важное.

В “Ринат не делает чат-ботов” я уже описывал возможность попадания в такую ситуацию. Если уж попали, то для движения дальше нужно перевернуть перспективу и пройтись по пунктам из “Как системно внедрять LLM в бизнес без галлюцинаций?”

Достаточно понять, что у нас есть популярный и гибкий инкубатор идей по использованию AI в компании. Люди им пользуются и экспериментируют. Да, он подглючивает, но это не страшно.

Дальше нужно проанализировать те данные, которые у нас уже есть.

Берем историю всех бесед пользователей и смотрим, а какие паттерны использования есть чаще всего? Можно просто прогнать все беседы через классификатор на 100 категорий и посмотреть так.

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

Заодно можем и оптимизировать промпты под задачу и переключить на модели попроще. У нас же есть тестовый датасет, поэтому тут можно механически перебрать варианты.

Продукт можно выкатить на той же платформе или просто классифицировать запросы пользователей и совпадающие направлять из чата в него.

А теперь смотрим внимательно на финт ушами. Мы взяли самый популярный паттерн использования. Он популярный, а значит - давал много нагрузки на большие модели. И теперь эта вся нагрузка уйдет на специализированный продукт, который использует оптимизированные промпты и модели. Так мы не только сделали фичу более надежной для широкого выкатывания, но и оптимизировали общую загрузку и порезали косты.

Сделали? Заново смотрим на остальные запросы пользователей в истории переписок и выделяем следующий паттерн. А чат-бот можно оставить экспериментальной площадкой для всех новых идей.

Самое интересное, что эта стратегия ложится на существующую концепцию Innovation Incubator, поэтому можно переиспользовать процессы и методологии для организации работы (data-driven product development + lean startups).

А вам приходилось встречать подобные ситуации?

Ваш, @llm_under_hood 🤗

История про AI R&D Lab Pass

У меня есть несколько клиентов-компаний, которые внедряют LLM в бизнес в EU/USA. Им хочется иметь доступ к актуальным инсайтам, ресурсам и связям AI R&D отдела, но без затрат времени и денег на создание такого отдела у себя.

По совпадению, я уже веду такой отраслевой AI R&D для бизнеса (Enterprise RAG Challenge, LLM Benchmark или курс по AI Assistants - это все примеры "выхлопа")

Поэтому с некоторыми компаниями мы можем договориться так. В рамках программы Explorer они получают доступ к новым инсайтам из моего отраслевого AI R&D в виде лекций, результатов публичных и приватных бенчмарков и важных новостей. Плюс они могут через меня разместить проблемы в Challenge или стукнуться напрямую к толковым специалистам для найма. Такой вот месячный абонемент в AI-лабораторию по цене одного дня работы внешнего консультанта.

Пост про “Как системно внедрять LLM в бизнес без галлюцинаций?” - это как раз выжимка из последней отгрузки в рамках программы. Я решил поделиться ею после того, как сегодня утром один AI Integration Lead выдал такой отзыв про наболевшее: “Вау, как хорошо, что мы не успели взяться за реализацию чат-бота для помощи по SAP процессам. Потратили бы несколько месяцев впустую. Теперь понятно, что можно сделать проще и быстрее”

Возможно и вам пригодится. А если уж выводы совсем кратко:

(1) осваиваем SO / CoT на практике (о важности чего в данном канале уже не нужно рассказывать)
(2) выбираем только те проблемы и варианты решений, где точность можно измерять при помощи тестовых датасетов. Бенчмарки под задачу - наши лучшие друзья.
(3) Domain-Driven Design и методологии из него - помогут выбрать легко решаемые варианты из всего потенциального набора проблем.
(4) Всегда опираемся на статистику самых успешных паттернов и кейсов в отрасли (см полный список), не повторяем ошибки других команд.

Ваш, @llm_under_hood 🤗

Как системно внедрять LLM в бизнес без галлюцинаций? Для engineering leads.

Что делать компании среднего размера, которая попробовала решить несколько проблем при помощи LLM, и результат им понравился. Но сейчас хочется самим внедрять AI для решения других задач. С чего начать и как системно двигаться дальше?

Обычно за этот вопрос отвечает AI R&D департамент, но не у всех компаний он есть в достаточном масштабе. Поэтому вот краткая выжимка советов от стороннего AI R&D отдела [1]

1️⃣ Нужно браться только за бизнес-проблемы, решение которых можно свести к инженерной задаче.

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

Например, Илья победил в Enterprise RAG Challenge r2 “просто” тем, что заранее подготовил тестовый dataset под задачу, методически перебрал варианты пайплайна и использовал наиболее удачный вариант в самом соревновании.

2️⃣ Иногда проблему нужно “покрутить” с разных сторон, чтобы увидеть решение, которое сводится к инженерной задаче.

Например, в компании есть полсотни документов, которые описывают разные SAP процессы. Хочется, чтобы сотрудники могли быстро найти нужный процесс по запросу.

Решение в лоб - загрузить все документы в RAG и задать вопрос в чате - по очевидным причинам у компании “не взлетело”. Иногда ответы правильные, иногда - чушь.

Как быть? А сесть и посмотреть на схожие варианты решений из тех, которые взлетели у других компаний. Выбрать те, для которых можно собрать тестовый dataset с возможностью быстрой оценки.

Какой самый наглядный и близкий пример? Да тот же Enterprise RAG Challenge r2. Поэтому переделываем интерфейс системы из чата - в поисковик. В ответ на запрос пользователя о задаче, система должна найти пару документов, которые содержат ответ, указать на конкретные страницы.

Тестовый dataset - набор запросов пользователей на вход и конкретные страницы, которые нужно найти среди всего этого. Как только его разметим, можно начать перебирать варианты реализации, начиная с того, что попроще и есть под рукой. Начиная с Azure Cognitive Search до Query Expansion и FTS поиска по документам.

3️⃣ Бизнес никогда не будет оглашать весь ассортимент проблем. Они будут озвучивать только те, которые на их взгляд решаются при помощи AI. Чтобы увидеть весь список (и выбрать из него простые задачи) - нужно говорить с бизнесом и экспертами напрямую. Domain-Driven Design и методологии из него в помощь.

4️⃣ Не нужно оптимизировать весь бизнес-процесс целиком. Смотрим на каждый процесс, как на последовательность шагов.

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

Не нужно пытаться делать систему, которая будет “кушать” все PDF и давать ответы на “где будет стоит дешевле распечатать 200 визиток для 10 человек, из них 2 набора на плотной бумаги и с тиснением”. Тут замучаешься как собирать тестовый dataset, так и реализовывать логику с математикой.

Смотрим на процесс в целом и различаем скучную автоматизируемую рутину (mundane) и когнитивно сложные вещи (creative).

Mundane - автоматизировать, Creative - оставить людям.

В данном случае, можно автоматизировать процесс выгрузки всех цен по всем услугам по всем поставщикам в один единственный Excel файл со ссылками. И отдел маркетинга сможет просто искать в нем нужные позиции (по онтологии), сразу видеть цены и условия, а при необходимости и открывать исходные документы для перепроверки.

5️⃣ Обязательно читаем и проникаемся SO / CoT - без этого никуда. Пока его на практике не освоили, ни за какие проекты не беремся. Потом Router + Query Expansion. Logit Bias раскраска - тоже, для вырабатывания интуиции.

Ваш, @llm_under_hood 🤗

[1] Конекст про AI R&D - следующим постом

раскручивать вовсе не обязательно. Достаточно посмотреть 20 минутное видео по ссылке в посте, там все очень хорошо изложено

Вот это 20 минутное видео я разослал всем командам, которые я курирую в области внедрения AI в бизнес, чтобы они обязательно его посмотрели. YouTube

Я это видео упоминал в прошлом посте, но там оно могло затеряться.

Если кратко, то всякие агенты и прочие архитектуры с LLM под капотом могут очень много. Это обусловливает весь хайп. Достаточно просто сделать на коленке очень классный прототип, который даст правильный ответ на сложный вопрос.

Проблема в том, что бизнесу обычно нужна надежная система, которая будет стабильно давать правильные ответы на сложные вопросы. И разработка такой системы требует совершенно иных подходов. Это уже не capability engineering, а reliability engineering.

Люди, которые работают с распределенными системами знают, что, скажем, очень просто добиться работы серверной системы (аптайма) в 90% или даже 99%. Но требуется совершенно иной инженерный подход для повышения аптайма до 99.999%.

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

Как раз про стабильность систем, способы оценки и рассказывает это видео.

- Evaluating Agents is hard
- Static benchmarks can be misleading
- LLM systems are about reliability engineering, not capability engineering

Очень советую выделить 20 минут времени для его просмотра. Это поможет сэкономить гораздо больше времени на проектах в будущем

https://www.youtube.com/watch?v=d5EltXhbcfA

Ваш, @llm_under_hood 🤗

7 выводов о внедрении AI в бизнес на примерах крупных компаний

TLDR; начинаем со сбора evals

Если кто знает больше всего про то, как внедрять OpenAI в бизнес, так это сама OpenAI. У них есть отчет "AI in the Enterprise" (PDF) про выводы по внедрению AI в 7 очень крупных компаниях.

Самое интересное, на мой взгляд - это их описание парадигмы, которая отличает AI разработку от традиционного софта:

Использование AI — это не то же самое, что разработка программного обеспечения или развертывание облачных приложений. Наибольшего успеха достигают компании, которые воспринимают AI как новую парадигму. Это ведёт к формированию экспериментального мышления и итеративного подхода, позволяющего быстрее получать результаты и добиваться большей поддержки со стороны пользователей и заинтересованных сторон.

А второе интересное - упор на "Start with evals" в первом выводе по кейсу Morgan Stanley. Начинаем проекты со сбора тестов/бенчмарков для оценки работы моделей.

Отсюда еще следует - если в проекте нельзя просто и быстро протестировать качество системы с LLM под капотом, то следует сильно подумать, стоит ли за такой проект браться.

@sergeykadomsky в комментариях упомянул видео на тему, что разработка систем с LLM под капотом - это reliability engineering, а не capability engineering. Лучше и не скажешь! Video: Building and evaluating AI Agents 

Сами выводы (каждый идет с небольшим рассказом о кейсе)

01. Начинайте проект с evals - Morgan Stanley (financial services)
Используйте систематический подход для оценки того, насколько модели соответствуют вашим задачам.

02. Встраивайте AI в свои продукты - Indeed (крупнейший сайт вакансий)
Создавайте новые клиентские сценарии и более персонализированные взаимодействия.

03. Начинайте сейчас и инвестируйте заранее - Klarna (платежная система)
Чем раньше вы начнёте, тем быстрее будет расти отдача от инвестиций.

04. Настраивайте и адаптируйте модели - Lowe’s (home improvement)
Точная настройка моделей под ваши конкретные задачи значительно увеличит их эффективность.

05. Передайте AI в руки экспертов - BBVA (banking)
Люди, непосредственно работающие с процессом, лучше всего смогут улучшить его с помощью AI.

06. Уберите препятствия для разработчиков - Mercado Libre (ecommerce and fintech)
Автоматизация процесса разработки программного обеспечения значительно повысит отдачу от AI.

07. Ставьте амбициозные цели по автоматизации - OpenAI (LLM обучают)
Большинство процессов содержат рутинные задачи, идеально подходящие для автоматизации. Ставьте высокие цели.

Исходный отчет про AI in the Enterprise: PDF

Ваш, @llm_under_hood 🤗

Нас не волнует то, чего мы не знаем. LLM тоже

На фотографии - McArthur Wheeler, который в 1995 году ограбил два банка. Он это делал даже без маски, т.к. вымазал лицо в лимонном соке и был уверен, что это сделает его невидимым для камер.

Логика? С помощью лимонного сока можно писать невидимый текст на бумаге, значит и человека это тоже сделает невидимым.

Два исследователя так впечатлились этим примером, что провели исследование. Их звали Джастин Крюгер и Дэвид Даннинг, а синдром назвали Эффектом Даннинга — Крюгера: Нас не волнует то, чего мы не знаем.

Если бы это было не так, то люди бы до сих пор сидели на деревьях и боялись спуститься на землю. А вдруг съедят? Но для эволюции имеют значение не те миллионы, которых ожидаемо слопали, а те единицы, которым повезло выжить и оставить потомство.

Какое отношение это имеет к LLM?

LLM - это модели, которые заточены на то, чтобы выдавать наиболее приятные для человека ответы. По смыслу там средняя температура по больнице, главное не вглядываться в детали.

LLM при генерации ответа не волнует, можем ли мы проверить их ответы на ошибки. Языковые модели просто делают свою работу и генерируют правдоподобное полотно текста.

Скажем, новая Llama 4 делала это так приятно, что на LLM Арене заняла второе место после выхода. Правда потом выяснилось, что это просто был тюн под человеческие предпочтения (что говорит многое и про этот релиз Llama 4, и про бенчмарк в целом, и про поведение людей).

В общем, какие выводы?

(1) LLM способны усиливать как человеческий ум, так и человеческую глупость. Второе проще - достаточно выдать ответ в той области, где читающие не являются экспертами. А они и не заметят!

(2) Современные MCP/A2A, как LangChain на стероидах, упрощают интеграцию всевозможных систем c LLM. Поэтому ереси будет встречаться много. А потом срабатывает принцип Альберто Брандолини:

The amount of energy needed to refute bullshit is an order of magnitude bigger than that needed to produce it.

(3) Если в продукте с LLM под капотом не упоминается слово Accuracy в контексте цифр и доказательств, то это умножитель Даннинга — Крюгера. Бегите.

(4) Хотите, чтобы ответ LLM нравился людям? Попросите отвечать как позитивный подросток с кучей emoji.

Ваш, @llm_under_hood 🤗

Cекретная Quasar Alpha модель довольно неплоха. Погадаем, кто это?

У модели 8 место в моем бенчмарке на текущий момент.

Пока не совсем известно, кто это может быть, но мы можем применить дедукцию)

Смотрите, у модели есть нормальный Structured Output, которым она умеет пользоваться. Это сразу сужает круг подозреваемых:

(1) OpenAI
(2) Fireworks SO
(3) Mistral

Кстати, Google не стоит и близко, т.к. их Structured Output - это не JSON Schema, а огрызок от OpenAPI в версии VertexAI API. Он бы мой бенчмарк не вытащил.

FireworksAI можно вычеркивать смело, новые модели - это не их формат.

Остаются только OpenAI и Mistral. OpenAI слишком крупный для рекламной компании с OpenRouter - это не их профиль, а вот для небольшой французской компании Mistral - формат подойдет. Плюс, у них давно не было толковых релизов.

Да и, если смотреть на supported parameters Quasar, то совпадений больше с предыдущими моделями Mistral, нежели с OpenAI. Профиль latency + throughput тоже похож.

Так что я думаю, что секретный Quasar - это новая французская моделька. Если это так, то их стоит поздравить с хорошим результатом!

Кстати, судя по профилю latency - модель относительно небольшая. То, что она так высоко забралась делает ее интересной и потенциально недорогой.

Ваш, @llm_under_hood 🤗

Google: Agent2Agent Protocol (A2A)

Google захотела сделать свой MCP протокол, только с крупными компаниями. Готово.

Назвали его A2A (Agent2Agent). Это открытый стандарт для обмена информацией между ИИ-агентами, работающими в разных системах. Он использует технологии HTTP, SSE и JSON-RPC для упрощения интеграции в существующую инфраструктуру.

Основные моменты:
(1) Dynamic Capability Discovery - агенты обмениваются данными через JSON-Agent Card, что позволяет выбирать подходящего исполнителя задачи.

(2) Task-Centric Communication - протокол работает с задачами, у которых есть свой жизненный цикл. A2A поддерживает как быстрые операции, так и долгосрочные процессы с обратной связью и уведомлениями.

(3) Security (за что критиковали MCP) - продуманы средства аутентификации и авторизации для защиты данных.

(4) Мультимодальность - обмен информацией в виде текста, аудио или видео.

В теории, общее назначение A2A - упростить автоматизацию и интеграцию процессов в корпоративных системах. Однако на HN люди уже высказывались насчет сложности протокола и его влияния на контроль над данными. Мол, нагородили всякого, лишь бы рынок отжевать.

Мне кажется, с такой компанией оно может и взлететь. Но из-за сложности и непредсказуемости систем лететь будет так себе.

Почитать доки можно тут.

Ваш, @llm_under_hood 🤗

Исключительный повод написать про квантизацию (сжатие) моделей

Про квантизации я обычно не пишу, т.к. в бизнес задачах их практически не используют [1].

Но Google Gemma-3-27B стала исключением. Это сама по себе хорошая модель, которая еще и внезапно неплохо умеет в reasoning c SO CoT. Она весит 55GB и при загрузке в GPU в bf16 формате потребует ~ 60GB VRAM для текстовых задач. Это значит, что она влазит в одну H100 80GB.

Народ, естественно, начал перепаковывать эту модель в всякие хитрые квантизации, чтобы запускать на карточках поменьше.

А потом Google сделали ход конем и выпустили официальный google/gemma-3-27b-it-qat-q4_0-gguf. Эта квантизация условно использует не два байта на один параметр, а в четыре раза меньше (~4 бита на параметр), что транслируется в ~3x экономии памяти.

Фишка и отличие здесь в том, что Google использовали Quantisation Aware Training (QAT), которая позволяет пожать модель без особой потери качества.

Если раньше у меня были большие надежды на версии qwen-2.5 для умных локальных систем, то сейчас еще больше нравится Gemma-3 (27B и 12B). У них выхлоп на размер сильно больше, думать умеют, поддержка языков заявлена хорошая, а теперь еще и появилось больше способов запускать на разном железе.

Возможности для стартапов с локальными моделями прямо подскочили!

Ваш, @llm_under_hood 🤗

[1] Квантизации могут экономить память GPU-шек за счет сжатия параметров , но при этом негативно влиять на точность и скорость ответов. Чем сильнее и хитрее пожали, тем больше эффект. И при этом еще и требуется, чтобы такую хитрую квантизацию нормально поддерживал софт и были люди с опытом.

bf16 за квантизацию можно не считать, да и fp8 тоже (если он делается при помощи QAT и запускается нативно на GPU последних поколений)

LLM Benchmarks - прогресс у Google

За месяц накопились новые бенчмарки. Поэтому вот сразу пачка обновлений.

Gemini-2.5-pro-preview - это платная и самая большая модель Google. Она так хороша, как про нее говорят. В моем LLM бенчмарке на продуктовых задачах она побила OpenAI o1 и Anthropic Claude 3.7 Sonnet, заняв второе место. При этом она работала без Structured Outputs (ибо у Google он пока реализован шиворот навыворот)

DeepSeek-V3-0324 - это новая версия DeepSeek Chat (не путать с r1). Они смогли последовательно улучшить качество предыдущей chat версии. Прогресс не стоит на месте. Посмотрим, как у них будет дальше с новыми моделями.

Llama 4 модели - появились на радаре, но пока не обладают выдающимися способностями. Но это типичная картина, которая повторялась со всеми версиями Llama. Meta выпускает мощные foundational модели, которые потом тюнятся под конкретные задачи. Ждем r1 distill.

Gemma-3-27B-it - а вот тут уже очень интересно становится. Эта локальная мультимодальная модель от Google Deepmind. Это первая модель такого небольшого размера, которая забралась так высоко. Заявляется контекст 128k, поддержка 140 языков и function calling.

Возможно благодаря последнему модель смогла вытянуть достойный результат без поддержки Structured Output. Лучше всего она показала себя в инженерных задачах на работу со сложным кодом.

Ее младшая сестренка - gemma-3-12b-it тоже отличилась и заняла место на уровне лучших моделей в пару раз больше.

Что-то такое интересное Google DeepMind нащупали, что дает им возможность клепать хорошие модели по всем уровням (еще и на TPU). Будем ждать от них новых релизов.

Ваш, @llm_under_hood 🤗


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

А как решалось AI+Coding упражнение про парсер?

(см описание тут)

Да все просто и быстро. Самое главное - думать как опытный и ленивый специалист. То есть, свалить максимум работ на AI. Humans decide, AI does mundane work.

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


Help me to identify the most efficient and error-prone way to implement this parser. Don't code, just think and plan from the perspective of a very experienced pragmatic software engineer with 20 years of experience in shipping systems to production


Оно выдаст что-то годное:

1. Clarify Requirements and Edge Cases
2. Choose the Right Parsing Strategy
3. Clearly Define Parser Responsibilities
4. Implement Parsing in Phases (Iterative and Incremental)
5. Develop a Robust Testing Strategy. Tests are critical—write them first!
6. Error Handling and Reporting
7. Implementation Quality and Maintainability
8. Iterate with Feedback

Подсветка моя. Дальше действуем по плану. Начнем с тестов. Если спросить у AI идеи про тесты (чтобы попроще и попрагматичнее), то оно укажет на такой абзац в тексте:


The document below describes a simple text format that can be deterministically parsed into JSON objects. This document is also a test suite! Code admonitions always come in pairs: first input and then json.


Нам даже не надо писать тесты (что сделал каждый участник экспериментальной группы), достаточно просто распарсить этот текст и достать пары input-expected.

Поэтому, сначала подчистим текст в markdown, который любит любой AI:


Carefully read this spec. It lost its markdown formatting, please fix and return it.


Если LLM не осиливает весь объем сразу, то можно временно переключиться на модель с reasoning или просто спеку кусками вставлять.

Кстати, а что еще нам AI советовал? Clarify Requirements and Edge Cases


Check this spec for any contradictions or mistakes. For each - suggest a fix. Use your best judgement

Вот тут AI и найдет грабли, про которые я предупреждал. Можно поправить, а можно оставить так.

Ладно, читаемый текст в формате md есть, “пишем” тесты:


This is the spec that I have saved in file spec.md. Please write me python parser to read this spec and extract all code blocks.


Оно напишет извлекатор, который можно красиво обернуть вручную (Copilot) в тестер. Он будет доставать текст из файла, разбирать input и сравнивать его с ожидаемым результатом. Все.

А потом финальный цикл разработки:


You are an experienced and pragmatic software engineer with two decades of experience. Write me a recursive descent parser that will implement function `def parse(input: str) → Block` and will follow this spec:


Вставляем результат в код и смотрим. Если вдруг какие-то тесты не проходят - кидаем код парсера, спек и текст ошибки в ChatGPT/Claude и просим поправить.

У меня при проходе по этому workflow с ChatGPT все тесты стали зелеными за пару итераций.

А у вас как быстро сходятся все тесты?

Ваш, @llm_under_hood 🤗

Как заставить AI писать качественный код?

Нужно просто мыслить масштабно. Сейчас объясню)

Я знаю, что модели уже давно способны писать качественный код. Просто они как джинн с тремя желаниями. Нужно правильно уметь формулировать свои требования и хотелки, даже просто разбивать задачу. AI - это инструмент, с которым надо набить руку.

В рамках эксперимента по обучению AI+Coding разработчиков одной компании, я увидел, что для этого умения требуется две вещи:

(1) насмотренность - чтобы знать паттерны того, что и как нужно просить у моделей
(2) практика - чтобы можно было оперировать этими паттернами не задумываясь.

Проиллюстрировать это может помочь такое практическое задание.

Нужно написать качественный код парсера бизнес-документации на основе вот этого требования. Чем быстрее, тем лучше. Язык не имеет значения. Но вы должны быть уверены в качестве этого кода [1] Максимальное время - 4 часа.

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

После такого простого упражнения один из участников (с кучей опыта разработки сложных систем) написал:

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

В общем, нет никакой магии в том, чтобы использовать AI для написания качественного кода. Нужна просто практика и насмотренность на разные паттерны использования. Кто-то это назовет "мыслить масштабно". Можно начать с упражнения выше.

Ваш, @llm_under_hood 🤗

[1] Если вдруг во время выполнения задания встретите очередную пасхалку - так и надо. Use your best judgement.

Llama 4 вышла - MoE по 17B на эксперта

Пока в мире гадают, что это за модель Quasar на OpenRouter, Meta выпустила четвертую версию Llama

Читать тут. Любоваться тут.

Модели Llama 4 — это мультимодальные MoE модели, оптимизированные для многоязычных задач, программирования, вызова инструментов и создания автономных систем (агентов). Знания - по август 2024.

Llama 4 Scout:
- Поддерживается ввод текста и до 5 изображений.
- Поддерживает арабский, английский, французский, немецкий, хинди, индонезийский, итальянский, португальский, испанский, тагальский, тайский и вьетнамский языки (понимание изображений — только на английском).
- 16 экспертов по 17B
- Может работать на одном GPU (при использовании INT4-квантованной версии на одном GPU H100).
- Максимальная длина контекста: 10 млн токенов.

Llama 4 Maverick:
- Мультимодальность
- Поддерживает те же языки, что и Scout (понимание изображений — только на английском).
- 128 экспертов по 17B параметров
- Максимальная длина контекста: 1 млн токенов.

Хотя общее число параметров составляет 109B и 400B, во время вычислений активны только 17B, что уменьшает задержки при выводе и обучении. Это очень неплохо должно лечь на Apple Silicon!

Ваш, @llm_under_hood 🤗

SO CoT - самый полезный паттерн при создании продуктов с LLM под капотом

Так выходит, если судить по комментариям в моем прошлом опросе.

Я обещал расписать самый полезный паттерн постом в канале. Поскольку сам ответ не влазит в масштаб и формат поста, вот вам две статьи с более подробным описанием и примерами:

- Structured Output (SO): https://abdullin.com/structured-output/
- Custom Chain of Thought (SO CoT): https://abdullin.com/custom-chain-of-thought/

Ваш, @llm_under_hood 🤗

Какой паттерн из курса вам пригодился больше всего?

Если вы прошли мой курс по AI Ассистентам или проходите его, напишите, пожалуйста, какой паттерн из курса вам пригодился больше всего? REPL, Search итп. И чем он помог?

Я потом распишу подробно самый полезный паттерн отдельным постом в канале, а ответы на самые частые вопросы - интегрирую обратно в курс.

Ваш, @llm_under_hood 🤗

Кейсы: Структурированное извлечение данных из документов, типичные проблемы и советы

Вчера консультировал компанию, которая занимается логистикой в Европе. Они пилят внутренний продукт с LLM под капотом.

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

Текущий статус - используют Google Gemini, которому скармливают страницы и просят извлечь ответ по структуре. Есть даже evaluation datasets. По ним видно, что точность пока недостаточна.

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

У меня было минут 30, поэтому быстро прошлись по их решению и сразу перешли к обсуждению того, как с этим работать. Мои советы были очень типичны - просто подсветить приоритет того, что нужно сделать в первую очередь:

(1) Закрыть Feedback Loop и сделать так, чтобы можно было очень быстро тестировать качество работы всего пайплайна после любого изменения. В идеале, если на выходе будет визуализация ошибок в виде heatmap.

(вот пример визуализации: https://labs.abdullin.com/res/ai-assistants-ru-S02M13-heatmaps.png)

Тогда можно будет повысить качество просто подбором параметров pipeline. Причем это будет делать не от балды, а осознанно - по паттернам ошибок.

(2) Выкинуть ненужный мусор из промпта и начать использовать SO/CoT на всю катушку. У них был текстовый промпт, который не использовал ни Literals (вместо этого добавили вручную правило в текст) ни встраивал цепочки рассуждений перед проблемными полями. Из-за этого точность была сильно хуже того, что можно было получить.

(3) Следить за Signal vs Noise и декомпозировать, если сложные задачи. Но извлечение данных - это обычно задача простая.

И, в принципе, все. Этих вещей достаточно для того, чтобы начать двигаться в правильном направлении с технической стороны.

А одной команде это и вовсе помогло решить полностью конкретную проблему в инструменте для командной работы. Было:

Оно по сути работает, но надежности добиться не получается никак… Причем иногда оно стабильно работает неделями, а потом чето рандомно ломается) Довольно плохо слушает инструкции, даже жесткие. Модели разные пробовали, лучше всего на гпт 4о.

Подскажи пожалуйста, в нашем кейсе реально добиться надежности или пока технологически ограничены?


После подсветки приоритетов команда сфокусировалась на главном и быстро получила результат:

Да действительно так все и оказалось как ты говорил.

Нормальный промпт, SO+checklist показали приемлемую надежность в ответах даже на датасете со сложными переменными даты и времени.

Спасибо 🤝

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

Кто-нибудь еще валидирует ошибки не одной accuracy, а интересной таблицей или графиком? Поделитесь скриншотами своих визуализаций!

Ваш, @llm_under_hood 🤗

Клуб по интересам - SAP + AI R&D

Идея AI R&D в области автоматизации бизнес-процессов в SAP выстрелила лучше, чем я ожидал.

SAP - это как 1C, только гораздо масштабнее и сложнее. Им пользуются почти все крупнейшие компании в мире.

Причем не только со стороны разработчиков и команд (т.к. это интересный и сложный кейс для внедрения AI агентов/операторов в крупных компаниях), но и со стороны компаний, которые с этим SAP работают.

Поэтому сейчас начинаем процесс сбора кейсов использования SAP, где есть самый обычный бизнес процесс, который ну очень очень хочется хоть как-то автоматизировать. Например: добавление нового фрилансера в систему, добавление инвойса, согласование табелей рабочего времени или обработка закупочных заказов.

Собирать кейсы будем в таком формате, который сделает удобным создание отраслевого бенчмарка для операторов и агентов. А потом - подчистку специфики и запуск открытого Enterprise RPA Challenge на эту тему (как мы это с вами сделали с RAG-ами)

Про формат сбора кейсов я потом напишу. Если кратко, то понадобится несколько скриншотов интерфейса (секреты можно и нужно замазывать), заполненный вопросник про бизнес-процесс и контакт эксперта, который может ответить на вопросы.

Как ни странно, это как раз та конкретика и движуха, которой не хватает ни AI R&D командам ни даже самому SAP и его партнерам. Ну а те компании, которые пришлют подходящие кейсы - попадут в этот небольшой клуб по интересам.

Пока все предварительно. Если потенциально интересно поучаствовать или есть вопросы - пишите в комментарии. Лучше сразу упоминать отрасль и тип бизнес-процесса. Имена и названия - не обязательно)

Ваш, @llm_under_hood 🤗

Новый кейс на подходе - автоматизация бизнес-процессов

У меня давно не было разборов новых кейсов продуктов с LLM под капотом. Все потому, что пока идут в основном вариации известных кейсов (оглавление тут), а принципиально новые занимают какое-то время.

Cейчас начинает вырисовываться интересный паттерн - автоматизация бизнес-процессов в компаниях через выхлопную трубу UI. Эту тему уже подробно обсудили в чате моего курса по AI Assistants, поэтому интересно вынести ее на открытое обсуждение.

Проблема своей кажущейся нелогичностью очень похожа на историю с OpenRouter.

Итак, во всех крупных компаниях есть довольно скучный корпоративный софт. Чем крупнее компания, тем более вероятно, что этот софт сделан на базе SAP (т.к. альтернатив ему практически нет, разве что Oracle ERP Cloud или MS Dynamics 365).

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

И сейчас компании начинают изучать возможность автоматизации ручных процессов в SAP и подобных системах при помощи решений на базе Operator (как у OpenAI) или MCP серверов. Первое в качестве интерфейса использует агентов в связке с computer vision моделями, второе - специализированные инструменты и агентов. Наверное, работающее решение будет где-то посередке.

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

А еще можно просто подождать следующие раунды ERC. Там я постараюсь отразить боль кейса автоматизации корпоративных процессов в простом challenge.

Кому-то уже приходилось сталкиваться с SAP/MS Dynamics/1С или чем-то похожим?

Ваш, @llm_under_hood 🤗

Зачем вообще нужен OpenRouter? Продуктовый ответ

Вчера в канале мы обсуждали вопрос про аггрегатор моделей OpenRouter. Он предоставляет доступ к разным провайдерам LLM по одному API. У него есть немало глюков и проблем.

Например, я только вчера им в discord пожаловался, что у них далеко не все модели с заявленным Structured Output его реально поддерживают. Они обещали посмотреть, но вряд ли кардинально исправят.

Ну как таким пользоваться? Зачем, вообще, люди деньги платят за такой продукт?

Чтобы за LLM продукт платили деньги - он не должен быть технически идеальным.

В обсуждении к посту люди писали свои причины использования OR, например:
(1) OR повышает надежность. Например, если Anthropic ляжет (что бывает чаще, чем ожидают), то OpenRouter автоматически переключится на Bedrock или Google Vertex
(2) Они берут на себя головную боль по интеграции и нормализации новых провайдеров к единому стандарту. Апдейты придут туда быстрее, чем в LiteLLM. А если у какого-то провайдера глюки - переключат временно на другого.
(3) Всякое мелкое - доступ к новым моделям без ожидания появления их в tier, нормальные rate limits, распределение нагрузки между провайдерами, автоматический выбор провайдера подешевле итп.

И самая главная killer feature: адская экономия времени крупных компаний. И это, одновременно, часть без LLM совсем.

Например, если в компании 10 разработчиков, которым нужно 10 разных API для отладки, тестирования и failover, то не нужно заводить 10 аккаунтов, добавлять туда карточки, отслеживать расходы с правами доступа и каждый месяц подшивать по 10 или более инвойсов в бухгалтерию. Заплатили один раз, раздали доступы, проставили лимиты и все. Только одним этим компания сэкономила 10 часов возни разных людей в месяц.

Скажем, умножаем 10 на часовую ставку в 40 EUR, получаем экономию в 400 EUR. И это только легко измеримая часть. Чем крупнее компания, тем больше процессов будет затронуто и больше реальная экономия времени.

Понятно, что ниша OpenRouter не такая уж уникальная. Она лежит на поверхности и их много кто будет пытаться заменить, начиная с крупных облачных вендоров (Google Vertex, Amazon Bedrock итп).

Но интересен тут не сам OR, cколько признаки перспективной ниши для продукта с LLM под капотом - нужно искать там, где компании тратят время на решение скучных проблем. Причем проблемы настолько скучные, что там никто не предоставляет решения уже много лет, как бы эксперты не умоляли.

Почему так? А я полтора года назад в канале даже картинку на эту тему рисовал.

Ваш, @llm_under_hood 🤗

Повышение цен на курс “AI Assistants” c апреля

Мой курс про AI-ассистенты - о том, как обоснованно выбирать эффективные технические решения продуктовых задач на базе LLM - вышел 4 месяца назад.

С тех пор, как к нам присоединились первые участники, я добавил множество апдейтов - от практических заданий до видео о применении DDD в разработке LLM-driven продуктов.

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

Со следующего понедельника (31 Марта) мы повышаем цены на курс про AI Assistants.

Обещал предупредить заранее - выполняю)

Ваш, @llm_under_hood 🤗

Зачем вообще нужен OpenRouter?

OpenRouter - это аггрегатор моделей, которым я пользуюсь со второй версии своих бенчмарков. Он предоставляет единый API, через который можно вызывать разные LLM модели. Он пытается быть универсальным интерфейсом к разным провайдерам моделей, от OpenAI и DeepSeek до малоизвестных FireworksAI или Parasail.

Это не идеальный провайдер, у них есть глюки. Иногда что-то падает. В февральском отчете про LLM Benchmarks я рассказывал про глюки с reasoning режимами. Пока я писал январский отчет, нашел другую ошибку с их инфраструктурой.

Тем не менее, я продолжаю пользоваться OpenRouter. Если почитать обсуждения вокруг Claude Code, то там люди и компании умоляют добавить поддержку использования Sonnet именно через OpenRouter, потому, что без этого им никак.

А вот теперь важный вопрос, который очень близок к теме чата и канала - про продукты с LLM под капотом.

Что заставляет людей и компании пользоваться таким довольно глючным LLM сервисом? Казалось бы - бери и подключайся к провайдерам напрямую. Если хочется сэкономить время, то есть LiteLLM, который позволяет подключаться к разным провайдерам напрямую. У них более 100 интеграций.

Иными словами, какую такую проблему решает OpenRouter, что компании в Европе и США закрывают глаза на технические косяки с юридическими граблями и радостно им пользуются?

Это очень важный вопрос. Он близок к другому вопросу - “Какие продукты с LLM под капотом надо пилить, чтобы компании с удовольствием платили за них деньги? И чтобы не было риска, что OpenAI в один день добавит фичу, которая убъет мой стартап?”

Есть идеи?)

Ваш, @llm_under_hood 🤗

Deepseek Chat V3 0324 - есть прогресс

Новая версия DeepSeek Chat v3 (не путать с r1 моделями) стала заметно лучше своей предыдущей версии.

Причем, ее пока в Fireworks через OpenRouter не выкатили, поэтому тестировал я ее без поддержки в виде Structured Outputs. Не было ни одной ошибки валидации даже в очень сложных онтологиях.

Понятно, что модель сама по себе относительно бесполезная - такую локально запускать мучительно, а качество получше можно получить из r1. Но тем не менее прогресс в семействе chat v3 наблюдать приятно.

Новый Google Gemini, говорят, чрезвычайно хорош. Но пока OpenRouter возвращает сплошной RESOURCE_EXHAUSTED, поэтому тесты подождут.

Ваш, @llm_under_hood 🤗

PS: Бенчмарк пока еще черновой. Туда загружено только 20% кейсов. Прочитать про мой подход к бенчмаркам можно тут. Там есть и FAQ со всеми вопросами, которые мне задают последние полтора года.

Исходники лучшего решения ERCr2 и лонгрид на хабре

Если вам хочется заняться чем-то интересным на этих выходных, можно глянуть эти ссылки и понять, что именно скрывается за RAG архитектурой "Dense retrieval combined with LLM reranking and SO CoT":

- Хабр: Как я победил в RAG Challenge: от нуля до SoTA за один конкурс
- Github: IlyaRice/RAG-challenge-2

Если точнее, Илья - один из двух победителей в призовом раунде ERCr2 и победитель по очкам всего соревнования. И еще он занял первое место используя локальную LLM от IBM.

Круто, что он открыто рассказывает про весь процесс и делится исходниками. Если что, можно задавать ему вопросы в комментариях на Хабре или прямо тут!

Пожелаем ему побольше таких побед - с детальнейшими лонгридами и открытыми исходниками. Это реально помогает двигать вперед State of the Art решения практических задач.

Ваш, @llm_under_hood 🤗

Формат третьего раунда ERC - приземляем наш R&D

Итак, смотрите. Во втором раунде Enterprise RAG challenge мы искали ответы на вопросы в сотне годовых отчетов. Обнаружили, что если оценивать не только сам ответ, но и наличие доказательств, то вырисовывается интересная картина по поводу R/G scores. А еще получили понимание того, какие архитектуры и подходы справляются в таких RAG задачах лучше всех (см таблицу с обзорами https://abdullin.com/erc#r2)

Чего по отзывам не хватало в нашем R&D:
- оценки качества извлечения данных из графиков и таблиц
- наличия заранее готового evaluation pipeline
- формулировки задания, которая более приближена к реальным проблемам бизнеса
- заранее подготовленного стенда для оценки результатов (каждый писал систему оценки самостоятельно)

В третьем раунде можно сделать поинтереснее.

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

Общий формат соревнования будет тем же самым - нужно будет автоматически дать ответы на набор сгенерированных вопросов по этим документам, сопроводив их ссылками на подтверждающие факты. Вместо ссылки на номер страницы, как это было во втором раунде, надо будет приводить доказательство с указанием на конкретный элемент документа в рамках семантической схемы (она похожа на то, как Docling извлекает структуру).

Например, если ответ в таблице (а таких документов станет больше) - нужно будет привести название строки, столбца и конкретное значение. Если ответ на графике - примерный bbox. Если ответ - это пункт в контракте, то номер пункта и его текст. Так мы будем проверять, насколько правильно RAG находит исходные данные.

Дальше начинается самое интересное. Мы вместе разработаем модульный стенд для прогона всего пайплайна и оценки результатов, опубликуем его заранее с набором данных для оценки. Каждый сможет взять код, форкнуть, попробовать что-то улучшить и сразу посмотреть на результаты. Это было то самое конкурентное преимущество, которое помогло Илье занять первое место во втором раунде.

В итоге прокачивать базовый пайплайн можно будет в трех категориях:

(1) Extraction - улучшать то, как система структурированно извлекает данные из страниц
(2) Retrieval - делать извлеченные данные более релевантными
(3) Generation - прокачивать reasoning системы, чтобы она приходила к правильным ответам

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

Естественно, что все результаты, ссылки на отчеты участников и их форки будем публиковать открыто.

Что скажете насчет такого варианта?

Ваш, @llm_under_hood 🤗

Сегодня я запускаю новый эксперимент. Это курс AI+Coding для одной компании.

Какую проблему мы пытаемся решить? Во множестве компаний есть свои IT отделы с разработчиками. Это компании с обычной классической разработкой, без всяких агентов, LLM-ок или RAGов. Эти компании слышат про то, что разработчик может работать на 13.2% быстрее и эффективнее, если использует Cursor или Copilot [1]. Естественно, что им хочется такое к себе - это же снижает издержки и повышает прибыльность. Они даже готовы обучать сотрудников новым фишкам и давать новые инструменты.

В чем проблема? А в том, что дальше начинается самое интересное, которое покажется чистой чертовщиной для большинства читателей этого канала. Разработчики не хотят напрягаться и осваивать новые AI инструменты. Им и так хорошо. Рабочие места защищены, уволить особо не могут, компания прибыльная. Зачем напрягаться?

А без практики работы с AI инструментами в разработке - толка не будет. Нужно попробовать, прощупать слабые и сильные стороны, сделать привычкой. Самое важное - нужно адаптировать свой личный подход к разработке, который складывался последние 5-20 лет. Адаптировать и снова практиковать. Все это - систематически.

И вот этот тренд "не хочу напрягаться" я хочу попробовать преломить в одной отдельно взятой компании - поменять изнутри перспективу на AI Coding c “ну, интересно, но времени нет и напрягаться не хочется” на “ооо, на перерывах все только и говорят, как легко и удобно стало кодить, попробую-ка и я освоить новый инструмент, чтобы от коллег не отставать”.

А начнем мы с маленькой экспериментальной группы. 6 человек из компании в 150 человек. Эксперимент займет 2-3 месяца. Пройдемся по материалам из моих вебинаров по AI Coding, отработаем каты и практические упражнения, освоим новые инструменты, сделаем разработчиков супер-звездами в компании и попробуем силы на пилотном проекте.

Посмотрим, что из всего этого выйдет.

Ваш, @llm_under_hood 🤗

—-
[1] Статистику я взял с потолка. На самом деле буст в 10 раз легко, если правильно ставить задачи.

Все архитектуры Enterprise RAG Challenge

Какие RAG архитектуры работают лучше всего с бизнес-документами?

Вот вам обновленный и интерактивный leaderboard по результатам второго раунда Enterprise RAG Challenge: https://abdullin.com/erc/. Можно кликать на команды и читать про детали их решений на основе заполненных опросников. Если у команды было несколько экспериментов, то в карточке они тоже будут упомянуты.

В итоге у нашего коммьюнити получилось мощное исследование разных RAG архитектур на практической бизнес-задаче!

Причем, leaderboard с деталями решений - это далеко не последний результат. Я попозже дополню эту таблицу ссылками на посты и исходники, которые мне присылают.

А еще мы потихоньку начинаем планировать третий round. Его в итоге обсуждений решили сделать более организованным, чтобы выхлоп от R&D был интереснее и полезнее для всех в нашем комьюнити.

Идея простая - учимся на своих ошибках и двигаемся дальше.

В первом раунде мы обнаружили, что решения на базе SO / CoT легко занимают первое место. Вывод - сделаем генератор вопросов менее предсказуемым, чтобы SO/CoT жизнь маслом не казалась.

Второй раунд - многие использовали SO/CoT без векторов, но в итоге победило решение Ильи. Он заранее собрал инфраструктуру для оценки своего пайплайна и перебрал варианты его настройки на основе тестового набора данных.

Вывод - заранее соберем нормальную инфраструктуру для оценки пайплайнов и опубликуем ее вместе с тестовыми данными для всех желающих. Чтобы каждый мог быстро ставить разные эксперименты и оценивать их результаты.

И посмотрим, что получится в третьем раунде. Ведь интересно же, правда?)

Ваш, @llm_under_hood 🤗

--
- Пост про победителей

Mistral Small 3.1 24B - не революция, но планку поднимает

Эта новая модель от Mistral по своим оценкам на бенчмарке очень похожа на предыдущую версию 3.0 от 25 января. Только она немного лучше во всем, и это прекрасно - прогресс не стоит на месте. Обогнала qwen2.5-32b-instruct и догнала qwen-2.5-72b-instruct, а это многого стоит.

Mistral Small 3.1 24B можно скачать и запустить у себя (лицензия Apache 2.0). Mistral упоминает запуск на одной RTX 4090 или Маке с 32GB (естественно, с квантизацией).

Получается в итоге неплохая модель довольно редкого размера - 24B. Интересная вещь.

Ваш, @llm_under_hood 🤗

PS: Бенчмарк пока еще черновой. Туда загружено только 20% кейсов. Прочитать про мой подход к бенчмаркам можно тут. Там есть и FAQ со всеми вопросами, которые мне задают последние полтора года.

Новую PDF распознавалку от IBM подвезли - SmolDocling

Это vision LM в 256M. Говорят, что работает лучше Qwen2.5VL, но не со всеми языками. Импонирует то, что модель извлекает не просто текст, а сразу структуру.

Что там под капотом?

- Это vision LM со специальными токенами для элементов markdown
- Основана на SmolVLM-256M — самой компактной vision LM.
- Обучена на страницах и транскрипциях Docling (с использованием нового формата DocTags для лучшего отображения элементов и их местоположения).
- Читает документ за 0.35 секунды (на A100) при использовании 0.5 GB VRAM.
- Доступна в Hugging Face transformers и vLLM.

Модельку качать тут, пробовать тут.

Кто-нибудь уже пробовал на своих задачах?

Ваш, @llm_under_hood 🤗

PS: Whitepaper: https://arxiv.org/html/2503.11576v1

Можно ли использовать LLM для оптимизации промптов?

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

Казалось бы, что может быть сложного в том, чтобы задать вопрос:

Эй, ChatGPT, вот тебе исходный промпт и вот результаты его работы. Перепиши промпт так, чтобы этих ошибок больше не было.

А потом просто автоматизировать процесс перебора вариантов.

Проблема в том, что в итоге будет ерунда и каша. LLM по своей природе усредняют ответы, чтобы понравиться среднему читателю. Их к этому приучили через RLHF. На скриншоте пример того, как ChatGPT o1 pro пару минут назад у меня банально скатилась в китайский, настолько она старалась сгладить логические углы.

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

Поэтому лучше работает, когда мы даем мощной LLM материал для размышлений и просим ее проанализировать ошибки. А потом глазами просматриваем результаты и сами изменяем промпт.

Получается в итоге тот же паттерн "Human in the Loop", даже для оптимизации логических блоков. Как без него обойтись в разработке систем с LLM под капотом - я пока не знаю.

Ваш, @llm_under_hood 🤗

Benchmark Gemma-3-27B-Instruct - даже лучше QwQ-32B

Модель уверенно побила все версии Qwen, кроме Max. А еще эта локальная модель чуть лучше claude-3.5-sonnet!

И при этом ее я тестировал в reasoning бенчмарке без костылей в виде Structured Output (ибо на OpenRouter пока нет платных с поддежкой SO).

У нее очень хороший уровень Code. Compliance и BI слабые (но там без CoT/SO модели вывозят плохо). В среднем reason - удивительно хороший для модели такого размера.

Надо будет присмотреться к младшим версиям, как их выложат в платной версии и с SO.

В целом, похоже, что прогресс упорно не стоит на месте. Небольшие модели все хорошеют.

Ваш, @llm_under_hood 🤗

PS: Бенчмарк пока еще черновой. Туда загружено только 20% кейсов. Прочитать про мой подход к бенчмаркам можно тут. Там есть и FAQ со всеми вопросами, которые мне задают последние полтора года.

Можно запускать новые Enterprise RAG эксперименты!

49 человек попросило запустить заново Enterprise RAG Challenge Submission API, чтобы можно было поставить еще несколько экспериментов.

Он запущен по новому адресу - https://rag.abdullin.com

Можете отправлять свои новые эксперименты туда. Только, пожалуйста, не забывайте заполнять форму с протоколом эксперимента. Так мы сможем потом подвести итоги и проанализировать.

Самый интересный сейчас момент - это полностью локальные системы, у которых локально работает все - parsing/OCR, embeddings (если они есть) и LLM. В Leaderboards у нас пока помечены как локальные системы только те архитектуры, в которых LLM локальный. Я потом постараюсь добавить колонку для Fully Local.

Кстати, я прошелся по части Local submissions и отфильтровал те, у которых точно есть облачный компонент. Обновил тут https://abdullin.com/erc/. Позже пройду мелкой гребенкой.

Если верить цифрам R-Score/G-Score, узкое место полностью локальных систем - это retrieval. Если в облаке openai large embeddings творят чудеса, то с локальными системами еще предстоит разобраться.

Разные варианты retrieval в Enterprise RAG Challenge уже изучали Valerii и Илья (см https://t.me/neuraldeep/1348 в NeuralDeep).

Мне кажется перспективным направлением решение Dmitry Buykin. Оно работает в облаке, но вместо embeddings использует онтологии с SO/CoT чеклистами. Теоретически тут “R Score” может упасть не так сильно при переносе на локальные модели.

Ваш, @llm_under_hood 🤗

PS: Если останется интерес, то можно попробовать через пару месяцев прогнать новый раунд ERC. С тем же генератором вопросов, но с новыми файлами.

Финальные результаты Enterprise RAG Challenge

- Team Leaderboard - оценивает команды (берется лучшее решение каждой команды)
- SotA Leaderboard - оценивает все эксперименты, которые прислали команды вместе с заполненным опросником.

Колонки:
- Hours - сколько часов прошло между публикацией вопросов и генерацией ответов командой
- R - Retrieval Score. Max: 100
- G - Generation Score. Max: 100
- Score - Final score (R/3+G). Max: 133
- AI - команды использовали наш AI Research (мой курс, работа в TimeToAct или комьюнити 🤗)
- Lcl - использовались модели, которые можно запустить локально

Картинки в оригинале лежат тут: https://abdullin.com/erc/. Позже я туда добавлю ссылки на все отчеты и посты участников, сделаю расширенные таблицы на основе опросников (с фильтрациями)

Спасибо всем за участие - было очень круто! У нас вместе уже получилось продвинуть вперед SotA по построению RAG систем с LLM под капотом. Первые инсайты я опубликовал раньше, но основной анализ еще впереди.

Ваш, @llm_under_hood 🤗

Benchmark qwen/qwq-32b - она может и больше!

Итак, новая qwen/qwq-32b на моем reasoning бенчмарке показала себя лучше, чем qwen-2.5-72b-instruct и предыдущие 32B версии от Qwen.


┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━┓
┃ Model ┃ Score ┃
┡━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━┩
│ openai/o3-mini-2025-01-31 │ 76% │
│ anthropic/claude-3.7-sonne… │ 70% │
│ openai/o1-2024-12-17 │ 70% │
│ deepseek/deepseek-r1 │ 66% │
│ deepseek/deepseek-r1-disti… │ 60% │
│ .... │ │
│ >> qwen/qwq-32b << │ 40% │
│ qwen/qwen-2.5-72b-instruct │ 39% │
│ qwen/qwen2.5-32b-instruct │ 36% │
│ qwen/qwen-2.5-coder-32b-in… │ 36% │


Это уже очень хорошо. Но есть нюанс - эта модель может больше, если бы ей не мешал разброд и шатание с интерфейсами вокруг reasoning моделей.

Смотрите, для простоты бенчмарка, я преимущественно тестирую модели через OpenRouter через интерфейс OpenAI SDK. Этот подход работает прекрасно для обычных моделей. Можно даже использовать Fireworks провайдера, который поддерживает нормальный Structured Output.

В теории - подаем промпт в OpenAI SDK вместе с ожидаемой схемой и получаем ответ в виде объекта. OpenRouter передаст все в Fireworks и вернет ответ.

На практике же все взрывается с ошибкой Error: 'NoneType' object is not iterable в глубине OpenAI SDK. А все почему? Да провайдеры не могут договориться и определиться, как нужно получать у модели reasoning, а как результаты вычислений. Более того, они просто не знают, чего ожидать от своей модели.

В итоге, когда я просил reasoning модель подумать и ответить в виде схемы (и отправлял схему), причем в схеме уже было место для Chain of Thought, то qwen/qwq-32b просто выдавала свои размышления с ответом в think, а сам response оставляла пустым. Прослойка в виде OpenRouter/Fireworks такого не ожидала. В итоге мне приходил такой ответ:


{
"choices": [
{
"finish_reason": "stop",
"index": 0,
"logprobs": null,
"message": {
"content": "",
"reasoning": "{ \"chain_of_thought\": [ \"To determine how many ...",
"refusal": null,
"role": "assistant"
},
"native_finish_reason": "stop"
}
],


Ну а текущая OpenAI SDK не знает про поле reasoning, она ждет content по схеме. Пришлось переписывать клиента, чтобы автоматически разрешать такие проблемы.

А почему я говорю, что модель могла бы и лучше?

Да потому, что в паре простых вопросов мне приходил ответ, где внезапно reasoning текстом, а content - это не StructuredOutput, а markdown. То есть тут поведение не только нестабильное, но и constrained decoding не пахнет.


{
"choices": [
{
"finish_reason": "stop",
"index": 0,
"logprobs": null,
"message": {
"content": "```json\n{\n \"short_thought_steps...```",
"reasoning": "Okay, let me figure...",
"refusal": null,
"role": "assistant"
},
"native_finish_reason": "stop"
}
],



Возможно новый стандарт ResponseAPI от OpenAI позволит исправить этот бардак и задать нормальный стандарт работы с reasoning моделями и SO. Но это займет какое-то время.

А пока можно только порадоваться за qwen/qwq-32b, которая подняла планку качества 32B моделей невзирая на путаницу в интерфейсах.

Ваш, @llm_under_hood 🤗

PS: А вот как эта модель правильно отработала задачку про код (закидав проблему токенами). Sonnet 3.5 и 3.7 (без thinking) именно с этой задачкой не справился: Chain of thought.

Первые инсайты из Enterprise RAG Challenge r2

Мы с вами их обнаружили вместе!

Во-первых, качество извлечения документов важно для точности. Тут внезапно хорошо себя проявила библиотечка Docling от IBM (даже за пределами WatsonX AI Track).

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

Смотрим на архитектуру Ильи, которую он запускал на разных моделях.

PDF parsing with heavily modified Docling library + Dense retrieval + Router + Parent Document Retrieval + SO CoT + SO reparser


o3-mini R: 83.8 │ G: 81.8 │ Score: 123.7
llama3.3-70b R: 83.9 │ G: 72.8 │ Score: 114.8
llama-3.1 8b R: 81.1 │ G: 68.7 │ Score: 109.3

R - Retrieval score
G - Generation score


Видно, что по мере снижения размера модели, у нас снижается качество ответов. Но оно падает не так быстро, как можно было бы ожидать. Я думаю, что это все благодаря качественно сделанной Retrieval части - она “облегчает” работу LLM на финальных этапах.

В-третьих, в топовых решениях часто используются reasoning паттерны на основе SO CoT (Structured Outputs + Chain of Thought == Custom Chain of Thought). Причем они работают даже там, где SO нет и впомине (только нужно использовать Schema Repair).

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

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

---
- Победители Enterprise RAG Challenge r2
- Табличка с результатами (лучший результат от каждой команды)

Ваш, @llm_under_hood 🤗

Победители Enterprise RAG Challenge!

Я поздравляю всех победителей и участников. Мы сейчас не только классное соревнование устроили, но и сделали прямо громадный research по практическому сравнению эффективности разных архитектур на конкретной бизнес-задаче. Плюс получили живой опыт работы документами и PDF (кто бодался с отчетом на 1000 страниц - ставьте 🤝)

Отчеты, ссылки, посты, leaderboards, ground truth - все это мы будем выкладывать и дублировать в ближайшие недели.

Итак, победители. Теоретический максимум - 133 (100 за ответы и 33 за retrieval)

IBM WatsonX AI Track 🏆

3. nightwalkers - 356ef42c: 96.7.
Векторный RAG с deepseek-r1-distill-llama-70b и granite-embedding-107m-multilingual embeddings

2. A.Rasskazov/V.Kalesnikau - efabd48e: 109.3
multi_agent_ibm_openai - meta-llama/llama-3-405b-instruct, ibm/granite-embedding-107m-multilingual, text-embedding-3-small, gpt-4o-mini

1. Ilia Ris - 25fabf22: 120.3

PDF parsing with heavily modified Docling library + Dense retrieval + Router + Parent Document Retrieval + LLM Reranking + SO CoT + SO reparser + Majority vote (Self-Consistency); llm = llama-3.3 70b from IBM WatsonX

Main Track 🏆

3. hopeless - 6b0d78ba: 117.5
gpt-4o-2024-08-06
Dynamic Structured Output + SEC EDGAR Ontologies
Query Expansion with selecting indicators on CBOW similarity
Majority Selection for several runs (works for pages and final answers)
Chunking by pages only with focus on balancing pages vs tokens

2. Emil Shagiev - 0a878232: 121.6
gpt-4o-mini-2024-07-18, gpt-4o-2024-08-06, o3-mini-2025-01-31
1. Query Expansion
2. Search relevant pages using with fast and cheap LLM
3. Answer questions
4. Finalize answers

1. Ilia Ris - 320a7d36: 121.6
o3-mini
PDF parsing with heavily modified Docling library + Dense retrieval + Router + Parent Document Retrieval + LLM Reranking + SO CoT + Majority vote (Self-Consistency); llm = o3-mini

Еще раз поздравляю всех! SotA Leaderboard - в комментариях.

А вообще - что вам больше всего запомнилось в этом соревновании? Я думаю про третий раунд, уже с reasoning и поглубже в бизнес. Надо такое?

Ваш, @llm_under_hood 🤗

PS: Если еще хотите поучаствовать ради опыта в соревновании, то еще не поздно. Submission API я пока выключать не буду - пара команд попросила отсрочку до следующей недели.

Завтра в 10:00 по CET (UTC+1) я расскажу про победителей Enterprise RAG Challenge и новые инсайты. Встретимся в MS Teams. Ссылку на встречу выложим в discord, а видео - потом на Youtube.

А пока, для затравки, самый первый инсайт. Он очевиден, и я рассказывал про "signal vs noise" и на вебинарах и в курсе, но так наглядно я его увидел впервые.

Качество ответов RAG системы всегда будет ограничено качеством работы retrieval части. Если Retrieval тащит мусор или нерелевантную информацию в контекст - то это опускает максимальный предел точности всей системы в целом. Если Retrieval пропускает нужную информацию - тоже самое.

Посмотрите на Retrieval Score и Generation Score в таблице в комментариях. R-Score - оценивает то, насколько правильно найдены релевантные страницы. G-Score - насколько правильны в итоге ответы.

Напомню, что R-score я обычно своих систем считаю сурово. Изначально есть балл. За каждую ненужную цитату - минус 0.1, за каждую пропущенную цитату - минус 0.25.

Результаты Enterprise RAG Challenge показывают, что такой алгоритм оценки, внезапно, неплохо аппроксимирует теоретический потолок точности RAG системы. Практически всегда [1] G-Score ниже, чем R-Score. Это как если бы Retrieval часть задавала теоретический предел точности системы. А вот получится ли его реализовать - уже зависит от мощности модели и последнего reasoning шага. Signal-vs-noise на входном контексте этапа синтеза-генерации.

Отсюда следует и обратное. Если Retrieval Score хороший, но итоговые ответы - не очень, то что-то мы на самом последнем этапе недокрутили. Тут можно улучшить.

Побольше про это мы поговорим на объявлении итогов соревнования завтра. Приходите!

Ваш, @llm_under_hood 🤗

---
[1] "практически всегда", но не "всегда". За пределами TOP-25 есть примеры, где retrieval достает много мусора, но generation часть в целом находит ответы.

На чем запускать локальные модели?

В нашем комьюнити очень много людей и команд с практическим опытом локального разнообразных систем с LLM под капотом. Это видно по RAG решениям на ERC, обсуждениям в чате и представлениям в группе курса.

А давайте поговорим про то, как вы запускаете свои системы для пользователей? Речь не столько про запуск через ollama на ноутбуке, сколько про разворачивание системы для 5-30 одновременных пользователей (скорее throughput, чем latency).

- Какие модели используете?
- Как заводите Structured Outputs (если используете)?
- Какое железо и inference framework под капотом, с какими параметрами?
- Сколько tokens per second получается выжать и с какими контекстами.

Но, самое главное, как оно вообще вам на практике?

Ваш, @llm_under_hood 🤗

PS: Если кажется, что в комментариях дискуссия прервалась - она могла отвязаться от обсуждения и провалиться в чат канала: @llm_driven_products.

PPS: Если впервые заходите в чат, пожалуйста, не игнорируйте запрос от нашего бота. Он бдит, банит ботов и не понимает шуток.

Презентация «The Power of Context» от Stefan Gillich (директор AI GTM в Intel).

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

https://youtu.be/_2gPwGSSxs0

Ваш, @llm_under_hood 🤗

Самые популярные архитектуры в Enterprise RAG Challenge

Вот вам краткая выжимка того, что люди использовали во время Enterprise RAG Challenge round 2. Она сделана на основе анализа 55 описаний архитектур, которые заполнили команды.

🤗 Спасибо всем, кто участвовал и заполнял! 🤗

Key Takeaways

- RAG is near-universal. Almost every approach tries to solve the “long PDF → targeted answer” problem by chunking, storing embeddings, retrieving relevant sections, then letting the model “read” only those sections.
- Structured prompts (with JSON/Pydantic) were popular to ensure consistent outputs—particularly for numeric or Boolean questions that required a definite format.
- Chain-of-thought or multi-step reasoning is common, sometimes with multiple LLM calls for expansions, validations, or final re-checks.
- Performance + Cost trade-offs surfaced: several teams used “fast & cheap” LLMs for search or chunk-labelling, then a heavier model (e.g., GPT-4o) for final answers.

Most submissions combined:
- Document parsing (Docling, PyMuPDF, or similar),
- Vector or keyword-based retrieval (FAISS, Qdrant, BM25, etc.),
- Iterative LLM-based reasoning (chain-of-thought or agent-like flows),
- Structured response schemas (Pydantic or JSON).

Despite the variety of LLM families (OpenAI GPT-4o variants, Llama, Gemini, Qwen, DeepSeek, IBM Granite, Microsoft phi, etc.), the underlying RAG pipeline structure remained strikingly consistent: parse PDFs, embed or index them, fetch relevant chunks, and prompt an LLM to produce carefully formatted answers.

А то, насколько хорошо все эти архитектуры показали себя в рамках соревнования - мы узнаем уже в эту пятницу.

Ваш, @llm_under_hood 🤗

Бенчмарк OpenAI GPT-4.5 preview - не докручивает

Новый GPT-4.5 preview в моем reasoning бенчмарке внезапно показал себя всего лишь на уровне топового GPT-4o, что не очень много.

Я пока не буду делать поспешных выводов о качестве модели. Это preview версия, и все может сильно поменяться (у Google такое бывало не раз с preview версиями). Плюс сам бенчмарк довольно нишевый под бизнес задачи, и пока не заполнен кейсами до конца.

Давайте посмотрим, как эта модель думает и где подскальзывается.

Как я запускаю модели без Reasoning режима в бенчмарке? В StructuredOutput схеме у меня есть специальные "слоты" на размышления. В каждом тесте - своя схема. Эти слоты расположены таким образом, чтобы в процессе ответа помогать модели двигаться в правильном направлении. В итоге у нас получается паттерн Checklist/Custom CoT, который хорошо работает в бизнес-кейсах.

Один из тестов в новом бенчмарке - работа с кодом и доменными моделями. Дается здоровый файл с event sourcing aggregate для кредитной карты (баланс, транзакции, лимиты, KYC, авторизации итп) вместе со спеками. LLM задается вопрос о последствиях добавления новой фичи:

Which specs would fail, if I add a new feature to automatically block the card and decline any transaction above 1,000 (regardless of available credit)?

Посмотрим, как решает эту задачу GPT-4.5 preview - см short_thought_steps. Она смотрит список всех спеков, где идет речь о транзакциях больше $1000, проверяет их и дает варианты:


{
"short_thought_steps": [
"Review transaction-related specs.",
"Identify specs with transactions over 1,000.",
"Check if these specs expect successful transactions."
],
"failing_spec_names": [
"authorize_transaction_success",
"make_payment_success",
"close_card_success",
"close_card_fails_if_balance_not_zero"
]
}


Кстати, правильный ответ в данном тесте - сломаются спеки "authorize_transaction_success", "transaction_declined_over_limit"

Что говорит claude-sonnet-3.5 (без reasoning) в этом тесте? Модель анализирует глубже и дает более корректные выводы:


{
"short_thought_steps": [
"1. The new feature will block cards and decline transactions over $1,000",
"2. Need to identify specs that authorize transactions over $1,000 and expect success",
"3. Need to identify specs that assume a card stays active after a large transaction",
"4. Need to check specs that assume transactions are only declined for credit limit reasons"
],
"failing_spec_names": [
"authorize_transaction_success",
"post_transaction_success",
"transaction_declined_over_limit"
]
}


А что же делает deepseek-r1-llama-70b? Почему эта небольшая локальная модель по очкам работает лучше, чем GPT-4.5 и куча других моделей?

Этот тюн Llama-70B научился включать reasoning режим и думать тензорами, закидывая проблему токенами.

Она сначала подумает текстом, а потом в том же промпте выдаст правильный ответ. Пусть у нее нет выделенного reason режима (нельзя контроллировать в рамках одного промпта, сколько она думает), но изображает она его очень неплохо (см полный текст ответа).

В итоге финальные рассуждения правильны:


{
"short_thought_steps": [
"Identify specs where transactions exceed 1000",
"Check if these specs expect successful authorization",
"Determine if the new feature changes the expected outcome"
],
"failing_spec_names": [
"authorize_transaction_success",
"transaction_declined_over_limit"
]
}


Понятно, что это только один из примеров. Но в среднем по больнице такая картина сохраняется и на других тестах. GPT-4.5-preview пока не только проигрывает reasoning моделям (что ожидаемо), но и отстает от обычных моделей, которые могут изображать reasoning при наличии доступных слотов.

Ваш, @llm_under_hood 🤗

Если вы написали пост про свое участие в Enterprise RAG Challenge, киньте, пожалуйста, ссылку на него в комментарии сюда.

За opensource решений в Github - с меня пиво)

Я потом соберу сводную публикацию, чтобы ничего не упустить.

Ваш, @llm_under_hood 🤗

- Где найти толковых LLM-инженеров?
- Как найти хорошего консультанта, который знает про SO, reasoning и паттерны?
- Какой команде можно доверить приземление материалов из курса по AI ассистентам в процессы компании?

Вопрос интересный, особенно с учетом того, что поле деятельности довольно новое и все меняется достаточно быстро.

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

Можно вот прямо сейчас зайти в discord ERC и посмотреть, как люди на скорость анализируют PDF, обсуждают подходы и trade-offs. Обращайте внимание на автарки и ники - многие из них есть и в нашем чате.

Ваш, @llm_under_hood 🤗

PS: Похоже, хантить тоже уже начали 😁

AI and Context - директор AI GTM из Intel рассказывает интересное на Enterprise RAG Challenge

Прямая ссылка на MS Teams Video

Ваш, @llm_under_hood 🤗

PS: Если хотите узнать что-то у него про бизнес с AI в Европе - задавайте вопросы в чате в discord

Anthropic Claude 3.7 thinking - второе место!

Если вы очень любите Claude, то сделайте себе скриншот этого сообщения.

Anthropic Claude 3.7 в reasoning режиме вышла на второе место в моем бенчмарке! Она обогнала o1 в medium reasoning и "выбила" 100% в coding.

Reasoning parameters у этой модели: общий бюджет на ответ - 25k tokens. Из них 80% отводится под нативный reasoning. Плюс у модели еще есть слоты на размышления в рамках схемы ответа.

У Anthropic по-прежнему нет Structured Outputs, но с такими когнитивными способностями они ей и не нужны. JSON схема не была нарушена ни в одном случае.

Как я запускаю Reasoning модели без нативного SO? На вход подается с задачей описание схемы в виде кода (прямо pydantic текстом) и вручную написанный пример в JSON. Json schema я им не подаю, т.к. это обычно путает модели без SO на моих кейсах.

Предупреждаю, что 100% в coding у Claude 3.7:thinking будет не долго. У меня на подходе в бенчмарк набор тестов на разработку, анализ и исправление кода, в которых путаются все топовые модели. Поэтому оценки всех моделей позднее поедут немного вниз.

Ваш, @llm_under_hood 🤗

PS: Бенчмарк пока еще черновой. Туда загружено только 20% кейсов. Прочитать про мой подход к бенчмаркам можно тут. Там есть и FAQ со всеми вопросами, которые мне задают последние полтора года.

LLM Benchmark Anthropic Claude 3.7 - внезапно хорошо

Все знают, что Anthropic Claude очень плохо ведет себя на моих бенчмарках. В июле прошлого года две модели еще были в top 10, но потом их вытеснили более смышленые модели, которые не стояли на месте.

Но вот прошло время. Сменилась версия Claude и сменился сам бенчмарк - он теперь учитывает способность моделей к рассуждению.

anthropic/claude-3.7-sonnet на данный момент лучше всех моделей gpt-4o (запускал я его пока с дефолтовыми параметрами через OpenRouter). И это несмотря на то, что Anthropic до сих пор не поддерживает Structured Outputs!

Как я работаю с моделями без нормального SO? Отправляю им Pydantic схему прямо в виде питона, плюс отправляю JSON пример с заполненными полями. JSON Schema не отправляю - она только запутает модель, если ее специально не обучали.

Так вот, у anthropic/claude-3.7-sonnet не было ни одной ошибки в следовании формату на довольно нагруженных схемах! А когда модель точно следует формату (даже без перил в виде constrained inference), то расположение элементов в ответе как раз то, которое нам нужно. И если мы в схеме проложили свои чеклисты и CoT цепочки, то LLM будет на них опираться.

Схемы с онтологиями на 150 Literals я бы в Claude не стал отправлять (как это переваривает OpenAI или vllm+outlines/xgrammar), но что-то небольшое тут работает очень хорошо.

Ваш, @llm_under_hood 🤗

PS: Бенчмарк пока еще черновой. Туда загружено только 20% кейсов.

PPS: А почему не использовать instructor для моделей без SO? А вы видели его итоговый промпт? Он Claude совсем завалит.

В чате канала обсуждают компиляцию SO схем в OpenAI:

> Кстати я заметил то, что в последнее время, если передавать в opeanai довольно сложную схему - то он ооочень долго отвечает (вплоть до минуты)

Речь идет об эффективном использовании OpenAI на полную катушку, когда мы просим выдать ответ в виде определенной схемы Structured Output. Причем, в самой схеме прописывается прямо Custom Chain-of-thought или сложная онтология для анализа. Это экономит кучу промптов и повышает точность. А для своего reasoning - это вообще идеально.

OpenAI пока не догадались брать денег за компиляцию и выполнение сложных схем. Поэтому люди и используют SO на полную катушку, вплоть до отказов компилятора префиксных деревьев. Как с этим жить - обсуждают тут.

Кстати, локально такое тоже делается и работает хорошо. Чаще всего, vllm + outlines/xgrammar упоминается. А если запустить под капотом deepseek-r1-distill-llama-70B, то gpt-4o остается далеко за бортом.

Ваш, @llm_under_hood 🤗

PS: Если впервые заходите в чат, пожалуйста, не игнорируйте запрос от бота канала. Он бдит, банит ботов и не понимает шуток.

Enterprise RAG Challenge - тестовые данные и LLM для запуска бесплатно

ERC - это дружеское соревнование на лучший в мире RAG по годовым отчетам компаний. У нас уже больше 300 заявок, на keynote расскажет про раги в бизнесе директор Intel по области AI GTM, а IBM спонсирует дополнительный набор призов. Прочитать можно тут.

У нас уже готовы тестовые данные для подготовки к раунду (PDF и вопросы в новом формате): https://rag.timetoact.at/data/r2.0-test/ А в соседней папке 27 февраля появятся официальные данные для соревнования.

Submission API, куда надо будет отправлять свои ответы, развернут на https://rag.timetoact.at. Можно уже для тренировки попробовать сгенерировать ответы и загрузить их в это API.

Теперь, насчет LLM для запуска. IBM выделили отдельный набор призов для тех, кто создаст RAG систему на основе моделей из WatsonX AI. А на WatsonX у них есть из интересного модели вроде llama-3-3-70b-instruct, llama-3-405b-instruct, llama-3-2-90b-vision-instruct, mistralai/mistral-large и deepseek-r1-distill-llama-70b (ну и пучок embedding models). Список моделей есть тут плюс deepseek-r1-distill-llama-70b сверху.

Так вот, IBM думает предоставить бесплатный доступ к этим моделям для участников соревнования. Это пока не 100%, но попросить уже можно сейчас. Для этого надо зайти в дискорд в канал ibm-track и ответить на последнее сообщение от Daniel (IBM), попросив доступ к inference API WatsonX AI, кратко сказав, какие интересны модели и какая планируется архитектура.

Structured Outputs у них, к сожалению, нет, но c llama/mistral/deepseek и embedding моделями результат показать можно. deepseek-r1-llama-70B может отрабатывать CoT, если ее использовать через outlines или аналог.

Ваш, @llm_under_hood 🤗

Enterprise RAG Challenge - тестовый прогон 20 февраля

Завтра, 20 февраля в 12:00 UTC+1 / 14:00 MOW пройдет тестовый прогон Enterprise RAG Challenge. Это будет просто тестовая проверка всех систем. Я сгенерирую вопросы, выложу PDF, покажу запущенный Submission API/UI.

Если интересно задать свои вопросы и пообщаться, то приходите в discord (ссылка на него приходит после регистрации). Но это не обязательно. API и файлы останутся доступны и после, а ссылки я на них продублирую.

Ваш, @llm_under_hood 🤗

PS: Кстати, у участия в RAG Challenge или курсе по ассистентам есть побочный эффект - вас могут схантить к себе в команду. Были уже прецеденты. Так вот, не удивляйтесь, если произойдет такое:

Блин. Мне тут из-за тебя походу новую работу предложили

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

А еще в чате курса со вчерашнего дня висит такое объявление от стартапа - сейлсы, ходите осторожно там:

Ну вот найти бы продажника кто пошел и купил этот курс) Есть тут такие?)

Coding for AI - Как я быстро запускаю сервера с AI сервисами

Меня очень радует, когда в небольшой слайс времени и внимания получается упихнуть заметный объем работ за счет эффективного использования современных технологий. Сейчас как раз случился аналогичный пример - не могу не поделититься.

Итак, нужно быстро завести и запустить с нуля сервер с парой AI сервисов на разных языках, разными зависимостями, нормальным HTTPS, настройками network и SystemD? Чтобы все конфигурации были версионированы, применялись автоматически, а в случае проблем AI сервер можно было перезагрузить на любую предыдущую конфигурацию.

Плюс, естественно, надо дать доступ разработчикам к deployment pipelines, чтобы они могли сами выкатывать новые версии. И чтобы новые сервисы, DEV/PROD слоты втыкались в сервер без проблем, а сам AI сервер с потрохами можно было при желании перенести на другое железо или переупаковать в виртуальную машину.

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

Как все это делается?
- Разработчики заранее сами разрабатывают сервисы так, как им это удобно. Используют ChatGPT/Claude и их друзей. Один сервис на Python, другой в данном случае - Golang. Не суть столь важно
- Заводим виртуальную машину, где быстрее и проще, переключаем на NixOS.
- Кидаем ChatGPT в проект “DevOps Wizard” краткое описание сервисов, путей, необходимых ресурсов и просим одним файлом описать виртуальную машину.
- копируем выхлоп на 100 строчек, проглядываем глазами и запускаем команду nixos-rebuild switch. Через десяток секунд все будет развернуто, в OS установятся нужные зависимости, добавятся нужные ключи инженеров и переменные окружения, появятся SystemD слоты для запуска самих сервисов, Reverse Proxy получит HTTPS сертификаты и настроит раутинг, а порты - откроются.

В чем фишка? Проект “DevOps Wizard” - это просто типовая инструкция, которая велит LLM-ке подумать и написать аккуратную конфигурацию для NixOS. Там есть пара примеров разворачивания аналогичных систем просто для того, чтобы LLM-ка видела привычные правила форматирования и названия переменных.

Плюс поскольку все проекты уже спокойно укладываются в портфель из известных кейсов и паттернов, то и конфигурация достаточно типизированная (если только не нужно возиться с хитростями CUDA).

А если есть host.nix, то полностью перенастроить сервер на новую конфигурацию - это дело секунд.

Технология на базе NixOS настолько безотказная, простая и работающая (на моих кейсах), что все просто работает. Главный недостаток системы - по-своему упоротый синтаксис и относительная нишевость (админы обычно знают про Ansible, Chef или puppet). Но если бОльшую часть работы по возне с Nix DSL берет на себя LLM, а результаты налицо, то это мало кого волнует.

В итоге - одно удовольствие быстро разворачивать AI сервисы, если вдруг это надо срочно сделать самому.

А у вас есть свои примеры технологий, которые доставляют сплошную радость от использования?

Ваш, @llm_under_hood 🤗

AI in Coding или эксперимент с агентами

Если кратко, у нас на одном проекте стоит повторяющаяся задача. Нужно извлекать структурированную информацию из сайтов. Структура известна достаточно жестко, но сайты постоянно меняются. И каждый раз ходить по страницам, выбирать html, писать селекторы итп - надоедает.

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

Поэтому решили поставить эксперимент - выделить пару дней на попытку прототипирования таких агентов. Естественно, агенты для написания кода писались при помощи Claude/ChatGPT (ибо код давно уже почти никто не пишет - все разленились).

Задача не стояла “сделать”, а “пощупать и посмотреть, как далеко можно пройти за пару дней”. Это типичный timeboxing из стартапов.

Вот финальный протокол эксперимента:

Короче с агентами, в упрощенном виде все работает. Делаю так. Есть несколько агентов, которые заточены делать определенную функцию:

(1) поиск селектора для каталога - в итоге очень замудрено и проще его самому достать и передать, поэтому потом откажусь.
(2) генератор кода, который из html кода строки генерирует конвертер в json
(3) генератор кода, который делает next page, то есть переключает pagination

Агенты пишут самостоятельно эти генераторы (for loop) и при этом приводят к определенному интерфейсу.

Далее айдеру у себя в коде говорю, что надо уже написать полный парсер каталога, передаю ему интерфейсы инструментов, которые написали агенты, говорю про селекторы. Он уже потом генерирует код. Эту часть можно так же автоматизировать через агента, но хватит с меня экспериментов 😂

По сути, все это в разы быстрее можно было делать напрямую через aider. Но, если условно стояла бы задача “вот 100 клиентов, делайте”, то можно было запустить генератор по массиву и пойти пить чай.

Айгиз есть в чате канала, можно задавать ему там вопросы в обсуждении этого поста.

Ваш, @llm_under_hood 🤗

PS: Если впервые заходите в чат, пожалуйста, не игнорируйте запрос от бота канала. Он бдит, банит ботов и не понимает шуток.

Как работать с информацией при построении своих RAG систем?

Я сейчас собираю материал для дополнительного видео к курсу, чтобы ответить на вопрос "Ну собрали мы онтологию для поиска информации по ответу пользователя, а дальше что?" И нашел фотографию, которая наглядно описывает весь процесс.

Раньше так люди исследования вели и книги писали! И умудрялись умещать кванты знаний в странички блокнотов и библиотечные карточки. Zettelkasten растет оттуда (и немного - Obsidian). И вот эта концепция манипулирования большими объемами информации через небольшие структурированные ссылки, цитаты и заметки как раз идеально ложится на работу с текстовыми LLM.

Разве что мы теперь можем не по десятку карточек в минуту перетасовывать теперь, а по десятку тысяч.

Ну а Domain-Driven Design как раз описывает процессы копирования человеческих процессов подобных данному в цифру. DDD уделяет очень много внимания языку и смысловым концепциям (Ubiquitous Language, Bounded Context, Context Mapping итп) и LLM-ки обучены хорошо работать с человеческим миром через языки.

Использование DDD + LLM для отражения подходящих человеческих процессов в цифре - это весьма мощный и удобный инструмент.

Ваш, @llm_under_hood 🤗

Enterprise RAG Challenge: Updated question generator

Новая версия опубликована тут. Она использует расширенный dataset с метаданными всех PDF (извлечены при помощи gpt-4o-mini + SO) - dataset_v2.json. Он добавлен в repository, чтобы можно было генерировать вопросы локально. А сами PDF файлы под задачу уже выложим во время RAG Challenge.

Обращаем внимание на схему ответа:


class SourceReference(BaseModel):
pdf_sha1: str = Field(..., description="SHA1 hash of the PDF file")
page_index: int = Field(..., description="Physical page number in the PDF file")


class Answer(BaseModel):
question_text: str = Field(..., description="Text of the question")
kind: Literal["number", "name", "boolean", "names"] = Field(..., description="Kind of the question")
value: Union[float, str, bool, List[str], Literal["N/A"]] = Field(..., description="Answer to the question, according to the question schema")
references: List[SourceReference] = Field([], description="References to the source material in the PDF file")


class AnswerSubmission(BaseModel):
answers: List[Answer] = Field(..., description="List of answers to the questions")
team_email: str = Field(..., description="Email that your team used to register for the challenge")
submission_name: str = Field(..., description="Unique name of the submission (e.g. experiment name)")


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

В начале следующей неделе я выложу информацию по submission API, а в четверг можно будет сделать тестовый dry run.

Ваш, @llm_under_hood 🤗

Старожилы канала поймут и этот мем и вот этот комментарий в чате:

Нам схема с русскими подписями в кейсе + 8% к точности дала

Ваш, @llm_under_hood 🤗

PS: Если впервые заходите в чат, пожалуйста, не игнорируйте запрос от бота канала. Он бдит, банит ботов и не понимает шуток.

Enterprise RAG Challenge - новости

(1) Мы уже получили более 220 заявок на участие во втором раунде! Было бы больше, но вчера в Кёльне была авария у провайдера, и сайт всей группы прилег. А так в день 5-7 новых регистраций приходит.

(2) IBM присоединились к Challenge. Для тех, кто пилит решения на IBM WatsonX будет отдельный Leaderboard, призы и поддержка от экспертов IBM. Кстати, у них на платформу завезли deepseek-r1-llama-70B, который пока держится на 4м месте моего reasoning бенчмарка. Поэтому если кто-то уже работает с IBM, то есть все шансы показать достойный результат.

(3) Я прямо сейчас занимаюсь обновлением question генератора для второго раунда. Скорее всего, уже завтра в github выложу обновленную версию и начну в дискорде отвечать на все вопросы. Потом на следующей неделе хочу запустить все API и провести dry run для всех желающих. Со временем пока не определился - whenever ready.

Регистрироваться можно тут.

Ваш, @llm_under_hood 🤗

PS: Я с IBM напрямую не работал - терпения не хватило разбираться в их UX и процессах, поэтому сам подсказать ничего не смогу. Но эксперты смогут помочь - завели отдельный ibm-track канал на дискорде.

Что лучше - ставить вопрос в промпте до текста или после текста?

В прошлом посте про новые бенчмарки я написал:

Кстати, обратим внимание, что я вопрос ставлю до исходников файла. Это мне портит кэш, зато позволяет в среднем облегчить жизнь моделям и повысить качество на несколько процентов.

На что в чате возник резонный вопрос:

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

Это гипотеза, а гипотезы можно и нужно проверять. Поэтому я взял текущие coding задачи (там больше всего контекста) с вопросом до кода и добавил туда второй вариант промпта - чтобы вопрос был в конце. Плюс сделал градацию ошибок более плавной, как в других категориях. И добавил "Averages" внизу.

Итак, категория prefix - это точность моделей на задачах с вопросом в начале. Postfix - точность моделей на тех же задачах, но вопрос идет в конце.

Пока вышло, что в среднем по моделям промпты с вопросом в самом начале набирали 62%, а промпты с вопросом в конце - 55%.

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

А пока можете предварительно посмотреть, как ведет себя ваша любимая модель, если ставить вопрос в начале или в конце промпта.

Ваш, @llm_under_hood 🤗

Пример из теста на работу с кодом в новом reasoning бенчмарке

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

Вот пример простого теста на понимание кода:

Which specs would fail, if I add a new feature: after authorizing any transaction larger than 3000, the system automatically blocks the card due to “Large Transaction Risk.” We do not add new event type, just extend the existing command handler.

Source code:

Кстати, обратим внимание, что я вопрос ставлю до исходников файла. Это мне портит кэш, зато позволяет в среднем облегчить жизнь моделям и повысить качество на несколько процентов.

Файл-исходник к этой задаче во вложении в первом комментарии. Там очень простой event-driven aggregate состояний для кредитной карточки вместе со спецификациями на желаемое поведение. В реальности, кстати, такая логика на порядки сложнее.

Скажем, Claude Sonnet 3.5 отвечает на вопрос так:


{
"short_thought_steps": [
"1. New feature: block card if transaction > 3000",
"2. This affects authorize_transaction command",
"3. Current specs that test large transactions:",
"4. 'authorize_transaction_success' tests 2000 amount - would pass",
"5. But any spec testing transactions > 3000 would fail",
"6. Looking for specs with large transactions..."
],
"failing_spec_names": [
"authorize_transaction_success"
]
}


Кстати, смотрим внимательно, на 4-м шаге LLM-ка мыслила правильно, но потом что-то у нее пошло не так.

А вот o1 отвечает на этот вопрос с подвохом правильно:


{
"short_thought_steps": [
"Check specs that authorizeTransaction with amounts > 3000",
"No spec has an authorization > 3000",
"Hence no test scenario triggers the new block logic",
"No spec fails"
],
"failing_spec_names": []
}


Кстати, еще на этот вопрос отвечают правильно только o3-mini и microsoft phi-4 (из моделей, которые добавлены в бенчмарк на данном этапе).

Ваш, @llm_under_hood 🤗

Deepseek V3, Qwen-Max/Plus/Turbo в бенчмарке v2

Продолжаю портировать тесты из AI кейсов во вторую версию моего личного бенчмарка LLM на бизнес-задачах.

Добавил Deepseek V3 (aka deepseek-chat), который на reasoning задачах держится удивительно хорошо, только чуть хуже DeepSeek r1. Он на полную катушку использует слоты для reasoning в checklists/CoT. А Structured Output в исполнении Fireworks помогает придерживаться схемы.

Да, в новом бенчмарке у каждой модели теперь есть возможность пройти по custom chain of thought, который оптимизирован для конкретной задачи. И это дается вдобавок к внутренним reasoning tokens, которые есть у новых моделей.

Модели могут отказаться использовать возможность для размышления и сэкономить tokens. Но те, кто следуют - повышают свою точность.

Мы эти подходы достаточно давно используем во всех новых проектах для буста качества (в обмен на небольшое количество с пользой потраченных tokens), поэтому в бенчмарке большая часть тестов уже идет с таким reasoning.

Еще добавил gemini-2.0-flash, Qwen-Max/Plus/Turbo.

Но в целом добавление новых моделей сейчас не в приоритете. Сейчас важнее добавить как можно больше разных кейсов, чтобы стабилизировать оценки.

Ваш, @llm_under_hood 🤗

PS: Бенчмарк личный, закрытый, в черновой версии. Кому хочется стабильности и разных моделей см полтора года отчетов по не-reasoning бенчмарку LLM на бизнес задачах.

PPS: blur буду убирать по мере стабилизации бенчмарка

Курс “LLM под капотом: выбираем эффективные технические решения для AI-ассистентов”

С когортами поработали, апдейты добавили, приглашения к покупке по листу ожидания разослали, и вот теперь курс можно купить на моей странице https://abdullin.com/ai-assistants-course.

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

А тем, кто только планирует, — курс открыт для покупки, он в записи. Можно изучать материалы в своём темпе и применять на практике.

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

Присоединяйтесь, будет интересно!

Ваш, @llm_under_hood 🤗

Краткая история использования ChatGPT o1 pro для создания ассистента

С утра мне в голову пришла идея - а что, если создать свою ChatGPT, которая будет хранить заметки и списки вещей для поездок? Чтобы можно было просить компилировать списки из старых поездок и сверяться с ними голосом во время сборов.

Хотелось именно пройти весь путь от начала до конца, чтобы посмотреть, как можно интегрировать красивых голосовых ассистентов под рукой со своим API. Но руки были частично заняты сборами, поэтому работу свалил на ChatGPT.

Запустил новую сессию и в течение дня уточнял задачу и критиковал результаты. Один пункт - один запрос.

(1) Начал с запроса о минимальном API для бэкенда заметок и списков: нужны основные методы и эндпойнты.
(2) Посмотрел результаты и уточнил, что не требуется «голый CRUD». Предпочтение — «LLM-friendly» методы, ориентированные на логику, плюс заранее определённые теги.
(3) Попросил рассмотреть идею объединить заметки и списки в единую сущность. «Комментарии» станут обычными пунктами со специальным статусом, а хранение будет через виртуальную файловую систему. Естественно, переписать все под новую парадигму.
(4) Неплохо. А если добавить иерархические идентификаторы (в стиле «1.1.1»), чтобы каждый список был древовидной структурой?
(5) Так, а теперь добавим логику транзакций. Пусть LLM может отправлять в API все изменения одним батчем с откатом при ошибке.
(6) Напиши-ка мне пример реализации на Python (в одном файле) с Pydantic и тестами на pytest.
(7) Ничего так. Но лучше переписать в Go, с хранением списков в памяти и JSON-файлах, используя метод ApplyTransaction.
(8) ядро есть, теперь оберни все в API, а данные сохраняй на диск
(9) А теперь нужно это все описать в виде документации для LLM-ассистента — как тот может считывать списки, добавлять или изменять пункты, менять статус, всё через один транзакционный вызов.
(10) А теперь сделай мне OpenAPI спецификацию, я ее загружу в CustomAction.
(11) Финальный аккорд - собери выжимку разговора за день — этот список тезисов и последовательность шагов, чтобы передать общую картину разработки бэкенда для персонального ассистента.

В промежутке между 10 и 11 я еще скомпилировал бинарь, запустил его на сервере и вытащил его по секретному url. Этот url вместе с инструкцией вставил в CustomAction и добавил в своего ChatGPT. Написал только 3 строчки кода - handle_path в прокси сервере.

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

Ваш, @llm_under_hood 🤗

o3-mini в бенчмарке на втором месте, добавил hard mode

Продолжаю портировать задачи из кейсов во вторую версию моего личного бенчмарка LLM на бизнес задачах. В этот раз я догрузил в него часть самых изуверских задачек из доклада про text-to-sql c Neo4j конференции. В итоге "потолок" для o1 (medium reasoning) просел до 67%. И это несмотря на то, что у всех моделей есть две возможности подумать в рамках своего reasoning - сначала свободный CoT, а потом еще наиболее эффективный checklist.

Кстати, свежая o3-mini пока закрепилась на втором месте.

Второй интересный момент. Llama 405B - 49%, а DeepSeek r1 с его 37/671B MoE параметрами - только 53%. Как видим, прогресс не такой уж большой.

Там еще рядом интересно примостилcя дистиллят r1 на базе Llama 70B c 50% точности, что уже интереснее. Если раньше базовые Llama хорошели после тюнов на OpenChat, то теперь пойдет мода на дистилляты. А еще больше очков этой модели дает то, что пока она у меня справляется с задачами без Structured Outputs (на Fireworks не завезли пока).

Замазанные колонки пока можно игнорировать - туда портировано слишком мало кейсов, чтобы были стабильные цифры. Потом открою.

SO - в Features - Structured Output (response schema), который можно из коробки уже найти у большинства моделей. Если так дело пойдет, то через пару месяцев можно просто будет перестать тратить время на модели без поддержки SO.

Costs пока не считаю, чтобы заранее не плакать. Но стоимости там должны заметно подрасти из-за cot/reasoning tokens, если сравнивать с первым поколением бенчмарка.

Ваш, @llm_under_hood 🤗

PS: Бенчмарк личный, закрытый, в черновой версии. Кому хочется стабильности см полтора года отчетов по не-reasoning бенчмарку LLM на бизнес задачах.

Ловите второе preview бенчмарка v2 c Mistral 3 и DeepSeek-Llama-70B

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

Тесты в нем собраны из проектов внедрения AI/LLM в бизнес задачах за последний год. Первоначальная задача бенчмарка - оценивать потенциал моделей для разворачивания систем с LLM под капотом на них.

Важно: плохая оценка на текущей стадии говорит не о том, что модель плохая, а просто что она не осилила все задачи за один промпт. На текущей стадии сбора бенчмарка я пока постепенно добавляю cамые сложные задачи из кейсов, а самые простые - выкидываю. Задача сейчас - набрать запас прочности бенчмарка, чтобы не было, как с первой версии, когда все топовые модели толпились на уровне выше 95%.

Попозже в бенчмарк добавится разбивка логических шагов на мелкие, классификация способностей по колонкам (как в первой версии), а некоторые тесты будут открыты. Думаю, весь процесс займет несколько месяцев.

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

Пара интересных инсайтов:
(1) дистиллят DeepSeek r1 llama-70B пока выглядит очень бодро. Но его обязательно нужно использовать со structured output
(2) Microsoft Phi-4 бодра, но JSON Schema в сыром виде не понимает, подавай ей примеры. Да и вообще, это применимо к моделям без нативного Structured Output в целом.
(3) Llama 3.3-70B тоже держится очень бодро. Она не так уж сильно отстает от r1-Llama-70B

Ваш, @llm_under_hood 🤗

Что мы хотели знать про DeepSeek r1, но стеснялись спросить?

(1) Правда ли, что DeepSeek r1 лучше o1?

Вот никаким боком. Болтает, может, и приятно, но на конкретных бизнес-задачах он на уровне между 4o и 4o-mini. Да, это предварительные результаты бенчмарка v2 (см. рисунок 1). Да, там есть возможность поразмышлять вволю. Да, DeepSeek пользуется этой возможностью и размышляет только так.

(2) Правда ли, что DeepSeek r1 настолько дешевле o1? Как у них экономика сходится?

А тут начинаются интересные нюансы, про которые журналисты не всегда упоминают. Идем в Wiki статью про DeepSeek.

DeepSeek - это китайская лаборатория искусственного интеллекта, которая разрабатывает большие языковые модели с открытым исходным кодом. DeepSeek в значительной степени финансируется китайским хедж-фондом High-Flyer, основанным и управляемым Лян Вэньфэном из Ханчжоу, Чжэцзян.

А из этого следует два вывода:

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

А если мы пойдем на OpenRouter и сравним цены на DeepSeek от разных конкурентов (модель же любой может хостить), то получится интересная картинка (см рисунок 2). DeepSeek хостят ее с крошечным контекстом, никаким throughput и вообще не в силах продолжать этот аттракцион невиданной щедрости (желтый статус - качество просело).

TLDR; модель потенциально интересная, но не это не настолько переворот, как про это пишут. А в бизнес-задачах даже не самая оптимальная (не забываем про размер). Можно получить качество лучше просто разбив workflow на несколько небольших логических шагов для модельки послабее.

Ваш, @llm_under_hood 🤗

Используйте reasoning модели, чтобы улучшать архитектуры своих проектов с LLM под капотом.

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

Этим можно пользоваться, заменяя небольшой R&D отдел - вычитывать новые статьи и примерять идеи из них на свои решения.

(1) в контекст модели загружаем архитектуру текущего решения с LLM под капотом - свои мысли вперемешку с кусками кода. И просим сделать сухую выжимку. Повторять, пока не будут подсвечены нужные нюансы.
(2) потом в контекст грузим интересную статью, например, whitepaper про DeepSeek R1. Просим внимательно прочитать в контексте архитектуры текущего решения и предложить простые способы улучшения архитектуры, которые можно быстро проверить.

В ответ можно получить что-то вроде:

Your existing approach already follows many best practices in structured reasoning: ...

Borrowing from DeepSeek-R1’s lessons—especially the self-check “reflection” and using a simple reward or rating for partial coverage—can help you tighten feedback loops. And adding short extraction or “evidence snippet” steps can make your system’s findings easier to read and trust. Each idea above is relatively small-scale to implement but can unlock smoother or more transparent user experiences, aligned with the paper’s spirit of reinforcing better chain-of-thought.

Это выжимка из ответа. Детальный proposal со всеми идеями по улучшению развернулся на 3 страницы. И ведь дело говорит.

Ваш, @llm_under_hood 🤗