llm_under_hood | Неотсортированное

Telegram-канал llm_under_hood - LLM под капотом

12420

Канал про разработку продуктов на базе LLM/ChatGPT. Выжимка важных новостей и разборы кейсов.

Подписаться на канал

LLM под капотом

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

У меня давно не было разборов новых кейсов продуктов с 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 🤗

Читать полностью…

LLM под капотом

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

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

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

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

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

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

Ваш, @llm_under_hood 🤗

Читать полностью…

LLM под капотом

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 со всеми вопросами, которые мне задают последние полтора года.

Читать полностью…

LLM под капотом

Формат третьего раунда 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 🤗

Читать полностью…

LLM под капотом

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

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

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

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

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

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

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

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

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

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

Ваш, @llm_under_hood 🤗

Читать полностью…

LLM под капотом

Новую 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 🤗

Читать полностью…

LLM под капотом

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 со всеми вопросами, которые мне задают последние полтора года.

Читать полностью…

LLM под капотом

Финальные результаты 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 🤗

Читать полностью…

LLM под капотом

Первые инсайты из 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 🤗

Читать полностью…

LLM под капотом

Завтра в 10:00 по CET (UTC+1) я расскажу про победителей Enterprise RAG Challenge и новые инсайты. Встретимся в MS Teams. Ссылку на встречу выложим в discord, а видео - потом на timetoact-group-at">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 под капотом

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

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

https://youtu.be/_2gPwGSSxs0

Ваш, @llm_under_hood 🤗

Читать полностью…

LLM под капотом

Бенчмарк 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 🤗

Читать полностью…

LLM под капотом

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


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

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

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

Ваш, @llm_under_hood 🤗

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

Читать полностью…

LLM под капотом

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 под капотом

В чате канала обсуждают компиляцию 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: Если впервые заходите в чат, пожалуйста, не игнорируйте запрос от бота канала. Он бдит, банит ботов и не понимает шуток.

Читать полностью…

LLM под капотом

Зачем вообще нужен 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 🤗

Читать полностью…

LLM под капотом

Зачем вообще нужен 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 🤗

Читать полностью…

LLM под капотом

Исходники лучшего решения 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 🤗

Читать полностью…

LLM под капотом

Сегодня я запускаю новый эксперимент. Это курс 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 раз легко, если правильно ставить задачи.

Читать полностью…

LLM под капотом

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 со всеми вопросами, которые мне задают последние полтора года.

Читать полностью…

LLM под капотом

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

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

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

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


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

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

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

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

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

Ваш, @llm_under_hood 🤗

Читать полностью…

LLM под капотом

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

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

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

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

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

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

Тут дополнительно варианты разные варианты retrieval в Enterprise RAG Challenge уже изучали Valerii и Илья (см /channel/neuraldeep/1348 в NeuralDeep).

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

Ваш, @llm_under_hood 🤗

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

Читать полностью…

LLM под капотом

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 🤗

Читать полностью…

LLM под капотом

Победители 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

Еще раз поздравляю всех!

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

Ваш, @llm_under_hood 🤗

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

Читать полностью…

LLM под капотом

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

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

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

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

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

Ваш, @llm_under_hood 🤗

Читать полностью…

LLM под капотом

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

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

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 🤗

Читать полностью…

LLM под капотом

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

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

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

Ваш, @llm_under_hood 🤗

Читать полностью…

LLM под капотом

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

Ссылка на встречу - в дискорде https://discord.gg/dN2u38kC

Ваш, @llm_under_hood 🤗

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

Читать полностью…

LLM под капотом

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% кейсов.

Читать полностью…

LLM под капотом

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 🤗

Читать полностью…
Подписаться на канал