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

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

12420

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

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

LLM под капотом

NVIDIA Project Digits - персональный AI сервер на ладошке.

NVIDIA показала компактную AI платформу стоимостью в 3k USD, которая может запускать модели размером до 200B. А если соединить две машины - до 405B.

На борту - GB10 Grace Blackwell чип. У чипа может быть до 128 GB unified памяти (похоже на маки). На борту крутится DGX OS и запускается весь софт NVIDIA. Машинка может использоваться отдельно или подключаться к компьютеру.

Получается такой DGX сервер на минималках. В продаже — начиная с Мая. Это может быть выгодным вариантом для компаний, которые хотят протестировать локальных AI ассистентов без покупки большого сервера с GPU.

У вас есть проекты, где бы хорошо зашла такая машина?

Ваш, @llm_under_hood 🤗

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

LLM под капотом

ChatGPT o1 pro - и будущее остальных моделей

Пара заметок про то, как возможности o1 pro, скорее всего, повляют на развитие моделей в целом.

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

Какие задачки, например?

Задача: Вот тебе 200 KB субтитров с YouTube (очень корявых) с последних раундов AI for Good в Женеве. Просмотри эти часы и определи, какие стартапы прошли до финала, а какие в этот финал прошли. На основе этого дай нам ответ на вопрос - на что именно обращали внимание члены жюри при отборе команд. Какие у них реальные требования (а не заявленные).

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

Задача: вот тебе описание моих прошлых LLM бенчмарков, а вот краткое описание, почему эта архитектура плохо справляется с добавлением новых кейсов. А мне нужна и поддержка VLM, и опциональные Structured Outputs, и поддержка openAI/OpenRouter итп. Давай-ка набросай мне такую композицию классов, чтобы все стало просто и понятно.

o1 pro до сих пор толком не справилась - код я выкину. НО! В процессе она так переписывает весь фреймворк с самого начала с учетом всех ограничений, что я глазами вижу более или менее удачные варианты. Я потратил где-то часов 8 на все, сэкономил себе пару недель мучительного выписывания архитектуры с разными итерациями.

Самое интересное - это смотреть на ту скупую выжимку chain of thought, которой делится o1 pro в процессе рассуждений.

Такое ощущение, что там работает в тандеме несколько разных моделей.

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

Если, скажем, o1 pro передать большой список на обдумывание (например, список компаний для анализа), то она может проходить по нему последовательно, каждый раз анализируя 1-2 компании. А иногда может каждый раз сканировать весь список. Во втором случае результаты будут похуже. А в конце анализа модель возьмет паузу на минутку и соберет результаты в кучку для финального ответа.

Если o1 pro дать сложную задачу с кучей ограничений (например, нарисуй-ка мне такую архитектуру, которая удовлетворяет вот этим 10 требованиям), то прямо видно, как модель будет крутиться вокруг проблемы, пытаясь найти к ней подход. И если получится нащупать решение, то начнет распутывать этот клубок.

Да, подобное нам уже давно обещают “агентами” - дружная работа нескольких моделей над общей задачей. Но у openAI тут какая-то другая магия. И агентами они o1 pro почему-то не называют.

Будет интересно посмотреть, получится ли подсмотреть у OpenAI o1 pro работающие паттерны, как это у нас с вами получилось со связкой Structured Outputs/Checklists, которая в итоге дала Custom Chain of Thought. Глядишь, в 2025 и дорастем до Custom Agent Tandem.

Вот было бы интересно попробовать в Code+Eng тандем из 4o и Claude Sonnet 3.5 v2 (одна рулит, а вторая - пишет)

Ваш, @llm_under_hood 🤗

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

LLM под капотом

В заключение бенчмарков на 2024 год, хочу показать то, насколько прокачались LLM в качестве (за те же деньги).

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

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

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

Ваш, @llm_under_hood 🤗

PS: Если кто-то хочет построить свой график - в llm-benchmark-history есть данные в csv формате. Можно самостоятельно привязать их к timeline и построить свой график.

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

LLM под капотом

А в чем проблема с полной передачей LLM Core сервисов на поддержку команде интеграции?

(это в чате канала продолжается дискуссия на тему экономики кейсов с LLM под капотом)

Это как раз не совсем честно. Достаточно посмотреть на ситуацию глазами обычного разработчика без опыта создания системы с LLM под капотом.

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

В теории будет красиво. Но на практике в коде будет пара классов, где начинается мистическая фигня.

Открыли мы этот класс, поменяли пару полей местами - качество сразу системы упало (ибо это был custom chain of thought в Structured Output).

Переименовали классы или зарефакторили поля поудобнее, а то больно длинные название - качество системы снова упало (ибо названия оптимизированы были под data extraction контекст на немецком языке)

Поправили комментарии к полям (Field descriptions), качество системы снова упало (ибо descriptions попадают в json schema и идут в контекст модели)

Зареклись трогать классы от Structured Output и просто запустили refactoring из другого места, а он глобально задел одно из полей в Structured Output. Качество системы снова упало.

Чуть чуть поменяли промпт в одном из файлов, добавив туда инструкций и данных для решения конкретной проблемы от заказчика. Качество на этой проблеме выросло, а общее качество системы упало многократно (ибо перегрузили контекст и нарушили noise/signal ratio)

Зареклись что-то делать и трогать этот код, а качество системы снова упало (ибо модель запинили к общей версии, а ее недавно OpenAI переключил на более дешевую и чуть менее качественную версию, как это они любят делать)

И тому подобное)

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

Все равно, разработка ядра системы с LLM под капотом - это лишь 5-10% от общей работы по интеграции или разработке продукта.

Ваш, @llm_under_hood 🤗

PS: Подобный подход не совсем применим к системам, где LLM/AI является основной фичей, вроде чат-ботов или каких-нибудь нейроаватаров.

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

LLM под капотом

Как тестировать агентов? Да и вообще любые системы с LLM под капотом?

(по мотивам вопроса в community курса)

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

Скажем, есть вопрос "Which requirements to implement and test business continuity plans does the contract specify?", а ответ - "The contract specifies these requirements for implementing and testing business continuity plans..."

Можно, конечно, набрать пары вопрос-ответ, а потом использовать "LLM as a Judge" для сравнения каноничного ответа с тем, который выдает система. Но этот путь выложен граблями.

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

Пример ответа, который можно проверить автоматически:


{ "relevant_sections": [ "2.2.1", "3.15", "6.1" ] }


Бенчмарк для данного агента будет состоять в виде таблицы "вопрос" - "relevant_sections". Мы будем отправлять их в систему, получать relevant_sections и сравнивать их с каноничными используя, например, Jacard Index. Считаем среднее и получаем качество работы системы в данной версии.

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

Ваш, @llm_under_hood 🤗

PS: Для тех, кто любит distributed systems, есть одна из самых вдохновляющих презентаций на тему тестирования сложных систем - от создателей FoundationDB: Testing Distributed Systems w/ Deterministic Simulation.

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

LLM под капотом

"Как ищете клиентов?"

Это простой вопрос в комментарии на предыдущий пост про экономику кейсов с LLM под капотом. Ответ будет чуть посложнее.

Я лично (почти) не беру проекты на end-to-end разработку. Вместо этого я помогаю командам и клиентам, которые разрабатывают системы с LLM под капотом.

Основная компания - TimeToAct Austria, которая предоставляет услуги по консалтингу и разработке. У них с клиентами в области LLM/AI получилось очень забавно - их слишком много. Настолько много, что можно выбирать самые интересные проекты, и при этом еще иметь сильно больше запросов на разработку, чем есть команд.

Как так получилось? Это результат работы нескольких стратегий.

Во-первых, эффективный маркетинг в области AI. Видели официальные релизы моих LLM Benchmarks (например, ноябрьский)? Бенчмарки работают настолько хорошо для создания репутации и привлечения клиентов, что теперь публикуются не только на сайте TimeToAct Austria, а сразу на основной странице сайта всей группы компаний в целом.

Enterprise RAG Challenge (та часть второго раунда, которая пройдет в Европе)- тоже пример маркетинга в области AI с очень хорошей отдачей. Еще есть ряд местных нишевых конференций и активностей в DACH, которые работают аналогичным образом.

И на каждом мероприятии обязательно упоминаются материалы из LLM Benchmarks и AI Case Portfolio, что создает репутацию и хорошо влияет на конверсию. Эти же материалы обязательно присутствуют во всех презентациям клиентам. Даже ребята из sales (без опыта AI/LLM) обязательно используют их после экспресс-инструктажа по правильному использованию.

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

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

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

По мере набивания шишек и накопления опыта стала вырисовываться система. А общение с разными командами в США и Европе позволило набрать еще больше статистики про то, что работает, а что - не очень. И теперь, как только появляется компания, которая хочет решить какую-то проблему при помощи LLM, запускается следующий процесс:

(1) Директора и лиды компании зазываются на “AI Case Mapping” Workshop, где я разбираю их проблемы и хотелки и сопоставляю с известными граблями и кейсами

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

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

(4) Я помогаю реализовать прототип, который доказывает применимость LLM для решения выбранной проблемы (или наоборот). На этом этапе “вскрываются” основные оставшиеся риски.

(4) Причем делается не только прототип (его можно и на LangChain сделать), но и выстраивается процесс, который позволит контроллируемо повышать качество системы. Так прототип превращается в LLM Core.

(5) Дальше LLM Core передается на реализацию командам AI Business Integration, которые уже должны будут встроить новые возможности в бизнес-процессы [1].

Окончание тут.

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

LLM под капотом

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

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

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

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

Если у кого-то в команде горят бюджеты текущего года и важно купить курс сейчас: вы можете написать в личку @akitka или @abdullin, мы пришлем ссылку для оплаты и проведем покупку в ручном режиме.

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

Ваш, @llm_under_hood 🎅

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

LLM под капотом

Бенчмарк OpenAI o1 - бронза🥉

OpenAI открыла доступ по API и для o1, так что ее можно, наконец, автоматически протестировать в бенчмарке.

Сразу напомню, что есть 4 разные версии o1: просто, mini, preview и pro. Не путайте их! Разницу я описал в посте про бенчмарк o1 pro.

Правда тут еще нужно помнить про нюанс, что o1 в API может отличаться от o1 в чате. Разные лимиты на compute, плюс у нас появляется chain of command (правила робототехники в исполнении OpenAI): Platform > Developer > User > Tool

Базовую o1 я тестировал автоматически, как и все остальные модели (за исключением pro). В итоге по очкам модель оказалась на третьем месте - немного похуже o1-preview и немного лучше o1-mini.

Запускалась она с reasoning_effort="medium" (дефолтное значение) и max_tokens=25000 (рекоммендация OpenAI).

Что примечательно, третье место тут и по цене - зависимость между стоимостью и качеством нарисовалась красивая. o1-preview стоит подороже в API за счет генерации большего количества reasoning tokens, но и результат дает получше. Ну а o1 pro думает очень долго и тщательно.

Этот тренд поддерживает и исследование HF, которое Игорь упоминал недавно - про "вытягивание" модели уровня 3B до 70B за счет генерации большого количества вариантов ответов.

Поэтому можно ждать, что на волне популярности o1 pro все больше провайдеров начнут предоставлять особо умный режим за дополнительную плату (см неблагодарный прогноз на 2025). А потом, глядишь, и появятся хорошие варианты запуска reasoning локально из коробки.

Ваш, @llm_under_hood 🤗

PS: Для тех, кто видит бенчмарки впервые, подробнее про них написано тут.

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

LLM под капотом

Я решил попробовать побенчмаркать o1 pro вручную

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

Это займет какое-то время, но результат должен быть забавный.

Можно уже точно сказать, что o1 pro умеет неплохо признавать свои ошибки post-mortem 😁

Как вы думаете, какие scores будут у этой модели на продуктовом бенчмарке?

Ваш, @llm_under_hood 🤗

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

LLM под капотом

Enterprise RAG Challenge Round 2 состоится - 27 февраля!

В нем мы сравниваем точность того, как разные RAG-архитектуры отвечают на вопросы по документам компаний.

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

Второй раунд состоится в конце февраля и будет немного покрупнее.

За результатами будут следить не только читатели этого канала, но и компании. Например, IBM, Google и прочие небольшие корпорации в пределах Австрии, Германии и Швейцарии.

Официально регистрацию пока не открыли. Это просто sneak preview для читателей канала, чтобы иметь в виду 27 февраля.

Ваш, @llm_under_hood 🤗

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

LLM под капотом

📦 Бенчмарки нескольких моделей одной пачкой: LLama 3.3, Amazon Nova, Gemini 1206

Meta Llama 3.3 70B Instruct - 40 место. Неплохой Reason, чуть ниже 405B, но вот со следованием инструкциям достаточно плохо. Но это типично для базовых моделей Llama. Хорошие тюны это дело исправляют.

Серия Amazon Nova - тоже так себе. Выложили что-то сырое. Инструкциям оно следует, но в целом хуже Llama 70B. Модели заняли 31, 50 и 74 места

Google Gemini Experimental 1206 - 23 место. Сильно хуже Google Gemini 1.5 Pro v2, которая очень хороша (если продраться через особенности использования). На то 1206 и экспериментальная модель.

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

Что насчет тестов o1-pro и o1? Когда эти модели будут доступны по API, тогда я их протестирую. По субъективным ощущениям o1 будет слабее o1-preview, ближе к уровню o1-mini. А o1-pro должен быть немного сильнее o1-preview.

Ваш, @llm_under_hood 🤗

PS: Для тех, кто видит бенчмарки впервые, подробнее про них написано тут.

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

LLM под капотом

Полный LLM Benchmark за ноябрь 2024

Полный отчет по продуктовым бенчмаркам LLM за ноябрь только что опубликовали. Читаем его тут: English / Deutsch.

Содержание
- Update: Claude Sonnet 3.5 v2 - Small capability improvement and great PDF capability
- GPT-4o from November 20 - TOP 3!
- Qwen 2.5 Coder 32B Instruct - mediocre but pushes SotA!
- Qwen QwQ 32B Preview - too smart for its own good
- Gemini Experimental 1121 - decent, but hard to get.
- Plans for LLM Benchmarks v2 - focus on cases and capabilities
- Text-to-SQL Benchmark

Этот отчет для тех, кто предпочитает моим постам в канале вдумчивый long-read один раз в месяц. Ну или для тех, у кого нет аккаунта в Телеграме 😁

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

Ваш, @llm_under_hood 🤗

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

LLM под капотом

Неблагодарный прогноз на 2025

В чате спросили про мой прогноз на 2025 год. А потом про тему будущего для агентов и fine-tuning спрашивали на созвоне с первой когортой курса.

Поэтому вот мой субъективный прогноз на 2025 по паре вопросов.

fine-tuning уже все?

Да fine-tning и никогда не был особо удачной вещью на практике. Его применяют к месту только в одном случае из 20, а применяют успешно (так, чтобы не сбить HLRF калибрацию и не набрать галлюцинаций) - и того реже. Чаще это все из-за того, что недооценивают сложность подготовки правильного набора данных и корректного процесса тюнинга.

Из моих кейсов удачно и к месту fine-tuning был использован только в одном проекте. У них там было достаточно данных - самостоятельно написанный справочник на нужную тематику, а еще 200-300 своих статей на эту же тему.

А в следующем году fine-tuning будет использоваться и того реже, т.к. люди начнут лучше понимать сколько разных возможностей дает хорошая базовая модель. А уж если там есть structured outputs / custom chain of thought и нормальный prompt engineering - то и того больше.

Будет ли 2025 год - годом агентов?

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

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

При этом фреймворков для агентов будет вагон и маленькая тележка. Всем хочется славы LangChain. Вон даже Pydantic подключился - https://ai.pydantic.dev.

А что будет с моделями? AGI в 2025?

AGI точно не будет - это еще более сложная тема, чем агенты)

Но все больше компаний будут покушаться на первое место OpenAI (это видно по трендам бенчмарков).

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

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

(1) Structured Outputs (constrained decoding) - он пока толком есть только у OpenAI, а ведь больно удобная это штука для повышения качества ответов (а если уж речь идет про custom chain-of-thought, то тем более)
(2) Работу с PDF сразу на уровне Text + Vision, это аналогично тому, как Anthropic под капотом разбивает PDF по страницам на текст + картинки.
(3) RAG + Execution Sandbox, как это сделано у OpenAI Assistants API.

А вот смены трансформеров на более удобную в inference архитектуру я пока не жду. Уж больно хорошо люди их научились обучать.

А какие у вас прогнозы?

Ваш, @llm_under_hood 🤗

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

LLM под капотом

Qwen QwQ 32B Preview - пока плохо

Вчера я писал про интересные результаты оценки Qwen 2.5 Coder 32 Instruct. И как раз сразу после этого на OpenRouter появилась новая reasoning модель, которую все очень хвалят по результатам общения: QwQ-32B-Preview

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

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

You extract product properties from provided text. Respond in format: "number unit" or "N/A" if can't determine. Strip quotes, thousands separators and comments.


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

А что в ответе? Alright, I've got this text about an electric screwdriver,...

Да даже mistral-7b-instruct-f16 ответил по существу: 1300 rpm. Это тот ответ, который можно без проблем использовать дальше в pipeline продукта.

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

Constrained decoding смог бы тут помочь. Либо нормальное дообучение. Подождем, что будет дальше.

Ваш, @llm_under_hood 🤗

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

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

LLM под капотом

Вчера я провел AI Discovery Workshop для одного клиента. Они пришли с таким запросом:

Мы поставляем сложное медицинское оборудование [1]. Иногда что-то идет не так, и это оборудование надо отлаживать. Техники выгружают логи, смотрят ошибки, потом находят схожие кейсы в нашей документации и исправляют. Если все сложно - пробиваются до инженеров, отвлекают их, потом снова едут к клиенту и продолжают тратить время компании.

Что мы попробовали - LangGraph + LangChain, чтобы ужимать громадные файлы логов и извлекать релевантные статьи из проиндексированной базы знаний в Confluence(гибридный поиск).

Все хорошо, но система галлюцинирует. Она выдумывает типы ошибок и новые записи в логах. Ответы - бывают вообще недопустимые. Как нам исправить ситуацию?

Что думаем делать дальше:
(1) Self-RAG или еще какой вариант RAG
(2) fine-tuning
(3) лучше промпты
(4) предобработка логов


С этой отправной точки мы начали общение и провели workshop. Они поняли, как можно с иной перспективы посмотреть на решаемую ими проблему "мы экономим время экспертов и технарей" и упростить весь остальной продукт:

(1) поменять формулировку решения и декомпозицию задач.
(2) сформировать интерфейс/scope/ACL в рамках которого команда разработки будет общаться с бизнесом в процесс разработки продукта
(3) сформировать процесс общения команды разработки с экспертами по отладке этих станков (это те самые эксперты, время которых техники тратят запросами)
(4) свести решение к 1-2 простым промптам и паре техник (и выкинуть весь LangChain/LangGraph хлам подальше) [2]
(5) выстроить feedback loop так, чтобы осознанно улучшать качество системы и не допускать регрессий.

Разобрать UX решения для in-process сбора customer feedback мы уже не успели, т.к. истек час, который я отвел на workshop. Но этого часа уже было достаточно, чтобы они перестали смотреть в сторону тупичка имени гибридного RAG-а.

К слову, на workshop я их заманил фразой, что мы чат-ботов не делаем, но можем детально описать все те грабли, на которых они потеряют следующие 2-3 месяца своей жизни (т.к. я сам в прошлом году наступал, да и кейсов насмотрелся) 🙈

До предсказаний дело не дошло, клиента сразу заинтересовало то, как можно все упростить и сделать быстрее. В итоге R&D отдел международной компании ушел думать со словами “нам нужно переварить и согласовать бюджеты, но мы к вам обязательно вернемся, чтобы дальше продукт так двигать”.

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

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

Ваш, @llm_under_hood 🤗

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

[2]
- Ринат, а какую библиотеку использовать вместо LangChain?
- OpenAI, Pydantic и matplotlib.
- А зачем matplotlib?
- Что Pydantic вопросов не вызывает - это уже очень хорошо. Matplotlib - чтобы визуализировать распределение ошибок системы на вашем наборе данных для валидации

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

LLM под капотом

Как тестировать систему с LLM под капотом? Как бенчмаркать разные LLM? Давайте попробуем разобраться.

В посте про тестирование агентов мы с вами проговорили про тестируемость LLM систем в принципе.

А как именно можно выстроить тестирование отдельных блоков? Как можно проверить качество их работы? Как мы можем подобрать наилучшую модель?

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

Вот кусок кода 👇. Он тестирует блок, который реализует паттерн “Data Extraction”. Тут мы отправляем в Vision Language Model картинку с графиком и задаем вопросы по названиям линий (картинку я добавлю в комментарии).


@requires_vision
def bench_analyse_chart_line(m: Model) -> TestResult:
attachment = Attachment.image(FOLDER / "chart_colored.png")

class ChartAnalysis(BaseModel):
line_name: Optional[str]

truth_table = [
("blue", ["20V", "20 V"]),
("purple", ["12V", "12 V"]),
("red", ["5V", "5 V"]),
("green", ["80", None]),
("yellow", ["3.3V", "3.3 V"]),
("pink", [None])
]

scores = []

for color, names in truth_table:
response = m.generate(
context="Analyze the chart and answer the question.",
attachments=[attachment],
question=f"What is the name of the line colored {color}?",
response_format=ChartAnalysis,
)
score = 1.0 if response.line_name in names else 0.0
scores.append(score)

avg_score = sum(scores) / len(scores)
return TestResult.score(avg_score)



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

Исходные данные - это картинка и тестовый dataset, который в коде назван truth_table. Во время запуска этого бенчмарка, мы проходимся по всем строчками в этой таблице, формируем запрос в LLM, получаем ответ и сравниваем его с каноничными вариантами. Если есть совпадение, то присваиваем 1.0, если нет - 0.0. А в итоге считаем среднее.

В LLM бенчмарке v2 таких блоков будет под сотню, на основе разных кейсов и паттернов. Поэтому код каждого блока простой, а таблицы - маленькие и прямо в коде (получаются table-driven tests). Мы аггрегируем оценки модели на разных блоках и получаем ее оценку в бенчмарке в целом.

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

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

(2) если пользователи проекта найдут кейс, который система отрабатывает плохо, мы проанализируем и найдем “сбоящий блок”. Потом, аккуратно внесем данные в тестовые таблицы этого блока и перейдем на шаг (1).

Можно повторять эти шаги для планомерного повышения качества системы.

Если у вас есть проекты, которые непонятно, как тестировать с таким подходом - пишите ситуацию и проблему в комментарии! Можно устроить community brainstorming для подбора путей к решению.

Ваш, @llm_under_hood 🤗

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

LLM под капотом

Всех с наступающим новым годом!

Неблагодарный прогноз на 2025 год я уже писал. За один месяц практически ничего не изменилось. Разве что вся ситуация начала еще больше походить на браузерные войны (все помнят Netscape Navigator и Internet Explorer?). Вон, Google начал тестировать четвертый способ работать со своими LLM - через библиотеки OpenAI.

Последние интересные модели за этот год тоже уже побенчмаркал - o1 pro в ручном режиме, o1 базовый, DeepSeek v3 671B, Gemini 2.0 Flash Experimental.

Самым полезным инсайтом за последние месяцы - про тестирование систем с LLM под капотом - тоже поделился.

В следующем году должно быть еще интереснее. Откроем продажи курса и запустим вторую версию LLM бенчмарка в продуктовых и бизнес задачах. В январе я планирую поделиться разборами двух новых кейсов в работе, а 27 февраля состоится Enterprise RAG Challenge r2 (там тоже ожидается куча инсайтов).

2024 год вышел насыщенный. Всем добра, здоровья и всего самого хорошего в новом году!

Ваш, @llm_under_hood 🎅

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

LLM под капотом

Бенчмарк DeepSeek v3 671B - TOP 20

Мелочь, а приятно. Еще одна локальная модель смогла побить планку старых GPT-4 Turbo и занять 20 место в продуктовом бенчмарке LLM. Это DeepSeek v3 671B - Mixture of Experts модель, которая активирует только 37B параметров на token.

Модель улучшила результат предыдущей версии DeepSeek v2.5 (TOP 30). Работа с бизнес-задачами в области CRM поднялась с 80 до 97, а решение инженерных задач в области разработки - с 57 до 62 (но до старушки Claude 3.5 Sonnet v2 с 82 этой модели еще далеко).

Хоть модель и использует только 37B параметров на токен, это не облегчит запуск ее локально. MoE означает более быстрый inference, а не "меньше требований к VRAM". Для запуска потребуется что-то вроде 8xH200 GPU, что делает модель не такой удобной для локально запуска.

Что интересно в этой модели - для обучения такой большой модели впервые использовали FP8 mixed precision training framework. Этот подход позволяет обучать модели быстрее, дешевле и с меньшими требованиями к памяти. Ну и квантизация тут должна работать лучше из коробки. Будем ждать, не появятся ли с этим подходом новые локальная модели - небольшие, но мощные.

Ваш, @llm_under_hood 🤗

PS: Для тех, кто видит бенчмарки впервые, подробнее про них написано тут.

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

LLM под капотом

Честно ли одной команде делать LLM Core, а потом передавать его на интеграцию команде AI Biz Integration?

Это в чате канала продолжается дискуссия на тему экономики кейсов с LLM под капотом:

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


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

Для полноты картины лучше рассмотреть и другие точки зрения.

Первая точка зрения - это видение ситуации людьми, которые работают в области Biz Integration не один год (PM, Frontend/Backend, Full-stack итп). У них есть немаленький опыт разработки и интеграции, но в последние годы и добавляется печалька, что такая большая сфера деятельности как LLM/AI просто проплывает мимо. Причем времени на “вкатывание” в ML/AI нужно потратить столько, сколько у них свободного нет, а иначе никак не попасть на проекты с LLM. Традиционная проблема курицы и яица.

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

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

Уже есть какое-то ядро, но оно спрятано за интерфейсом API. По сути это просто еще один сервис, который надо интегрировать. За поддержание LLM Core в рабочем режиме несет ответственность та же команда, которая его и делала.

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

В общем, для классических команд разработки, разделение проекта на LLM Core + AI Biz Integration - это возможность начать нарабатывать практический опыт с LLM/AI в комфортном для себя темпе, выполняя ту же работу, которую делали и всегда.

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

А пока - кому близка первая точка зрения про "опыта с AI/LLM нет, а в проекты с LLM под капотом не берут без соответствующего опыта"?

Ваш, @llm_under_hood 🤗

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

LLM под капотом

А теперь будет самый забавный момент.

(это завершение поста про "Как ищете клиентов?")

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

аааа, клиент хочет поскорее подписать бюджет на интеграцию работающего LLM Core, а у нас команды разработчиков все заняты. Где можно поскорее найти опытных PM, full-stack, FE/BE ребят в районе DACH для remote-first работы? Опыт с LLM не нужен совсем!


После подобной оптимизации компания получает себе очень приятную головную боль - потенциально прибыльных проектов сильно больше, чем команд для их реализации. Вторая приятность - для реализации этих проектов не требуются какие-то особые скиллы. Даже если нанимать новых людей, не нужно спешно учить их работать с LLM/AI. При желании, конечно, такое привествуется, но можно обойтись и “LLM логика спрятана за вон той API-шкой, вам нужно интегрировать ее в процессы клиента”.

TLDR; Как находить клиентов на проекты с LLM под капотом?

(1) Выстраиваем эффективный и хорошо масштабируемый маркетинг.
(2) Набираем портфель кейсов в своих областях для привлечения потенциальных клиентов
(3) Оптимизируем процесс работы с лидами так, чтобы быстро идентифицировать проблемы, которые можно быстро и выгодно (для всех) решить с использованием LLM/AI
(4) Страдаем от того, что рост компании упирается в скорость поиска, найма и обучения команд интеграции AI Biz Integration.

Там сбоку будет еще два процесса: (1) обучение разработчиков и менеджеров, (2) добавочная приоритизация проектов, активностей и мероприятий, чтобы системно набирать новый опыт и расширять портфель AI Cases. Но это уже скорее стратегический уровень, нежели просто привлечение клиентов.

Ваш, @llm_under_hood 🤗

[1] При приоритизации проектов на самом первом этапе выбираются такие, которые потом можно будет удобно разделить между командами на две части - LLM Core и AI Biz Integration. Между ними для эффективной работы команд мы четко пропишем интерфейс взаимодействия (смотрим с перспективы ACL в мире DDD или воплощения Inverse Conway Maneuver)

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

LLM под капотом

Давайте поговорим про экономику кейсов с LLM под капотом

Я специализируюсь на кейсах с LLM под капотом, которые встраиваются в продукты или оптимизируют какие-то бизнес-процессы в компаниях США и Европы.

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

Все эти пункты в итоге сводятся к одному экономическому - выгоде. Про какую выгоду я говорю?

Посмотрим на кейс с использованием ChatGPT в качестве бизнес-переводчика в нишевой области (кейс). Там выгода от использования вполне себе конкретная - компания экономит на услугах freelance перводчиков на 5-6 языков до 10000 евро в месяц.

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

Другой кейс - генерация лидов в международной компании (описание). Внедряемый процесс экономит, как минимум, пару недель ручного труда на каждую новую пачку лидов. За год, с учетом всех телодвижений, это экономит 30k-50k EUR в год на один офис. А офисов у этой международной компании больше пятидесяти. Можно перемножить и оценить потенциальную выгоду.

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

А еще забавно, что 90%+ стоимости внедрения в этом проекте не будет связано с LLM совсем. LLM Core (основное ядро с парой промптов и интеграций) - это один небольшой сервис. Ядро уже сделано и работает. Но потребуются усилия команд по интеграции (AI Biz Integration Team), чтобы эти новые возможности аккуратно воткнуть в бизнес-процессы компании. И они стоят того.

Аналогичная история повторяется постоянно. Скажем, в кейсе с захватами рынков, прямая выгода от внедрения data extraction на базе LLM - это пара недель экономии времени раз в пару месяцев. Можно консервативно посчитать как 2000 EUR в месяц. Казалось бы, что немного, но есть еще один нюанс под названием “Opportunity Cost”.

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

И, как это обычно водится с подобными кейсами, LLM ядро в данном кейсе - это компактный и достаточно простой модуль с парой промптов и выверенной системой контроля качества (фактически, тестовый dataset). Трудозатраты - полтора-два человеко-месяца.

LLM ядро там уже сделано и работает достаточно хорошо, а основная оставшаяся работа - это аккуратная интеграция всего этого добра в бизнес-процессы компании. Она, скорее всего, займет не один месяц работы AI Biz Integration команд.

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

Но неуспешные проекты не попадают в мою статистику Proven AI Cases, и поэтому не портят картину с работающими паттернами и успешно закрытыми кейсами.

Ваш, @llm_under_hood 🤗

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

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

LLM под капотом

OpenAI объявила модель o3, которая очень круто решает задачки из ARC-AGI.

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

o3 смогла решить 91% задачек из этого бенчмарка.

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

Если o1 pro - это золотой стандарт по цене и качеству, то o3 - это прямо заоблачная модель и по качеству и по цене.

o3 более заоблачно дорогая, нежели качественная (см картинку). Люди пока дешевле и эффективнее на задачах c тем уровнем сложности, который представлен в ARC-AGI.

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

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

Ваш, @llm_under_hood 🤗

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

LLM под капотом

Бенчмарк o1 pro - золотой стандарт

Итак, настало время протестировать o1 pro.

Но сначала disclaimer. Есть 4 разные версии o1. Не путайте их!

- o1-mini - самая маленькая и недорогая из Reasoning моделей. Она есть в ChatGPT и по API
- o1-preview - мощная версия, которая раньше была доступна в ChatGPT интерфейсе. Теперь ее оттуда убрали и заменили на pro. По API она еще доступна
- o1 - это то, что теперь заменяет o1-preview в чат интерфейсе. У этой модели ограничено время на размышления, так что субъективно она заметно глупее preview. По API эта модель не доступна.
- o1 pro - самая мощная модель, которой разрешили думать много и долго. Она есть в чат интерфейсе по Pro подписке за $200. По API ее пока нет.

Этот пост - исключительно про o1 pro. Модель я в порядке исключения тестировал вручную.

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

Еще я отключил custom instructions по своевременному совету Игоря. Память у меня и так была отключена. Сконвертировал запросы к API в текстовый запрос и запустил вречную.

Тут я столкнулся с двумя граблями.

Во-первых, o1 pro сейчас встроена в Chat. Поэтому задачки, которые по API возвращали нормальный plain-text YAML, теперь стали возвращать красиво отформатированный markdown. Тут я исправлял формат вручную.

Во-вторых, я при задачах в API я few-shots всегда форматировал так:


System: Task explanation

User: sample request 1
Assistant: sample response 1

User: sample request 2
Assistant: sample response 2

User: real request


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

В итоге, o1 pro понижала приоритет инструкций, которые были помечены как System и начинала искать паттерны в запросах пользователя. Она их находила и приходила к неверным выводам, спотыкаясь на integrate. Поэтому задачу в текстовый UI я стал форматировать так:


# Task
Task explanation

## Example
User:
Assistant:

## Example
User:
Assistant:

# Request


Ну а что в итоге?

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

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

Ваш, @llm_under_hood 🤗

PS: Для тех, кто видит бенчмарки впервые, подробнее про них написано тут.

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

LLM под капотом

Бенчмарк Gemini 2.0 Flash Experimental - Снова TOP-10

Тестировать новую Gemini 2.0 Flash Exp от Google я начинал с дурными предчувствиями и ожиданиями ниже плинтуса. Почему - это отдельная история про выхлопную трубу и Data Extraction на Google Vertex AI .

В итоге эта модель приятно удивила. По сравнению с предыдущей Flash 1.5, у Flash 2.0 на моих продуктовых бенчмарках нарисовался заметный скачок качества. Reason поднялась с 44 до 62, а итоговый результат - 75 до 84.

При этом модель оказалась внимательна к инструкциям (что важно для Structured Output / Custom Chain of Thought), и достигла идеальных 100 в Docs & Integrate. Последнего нет больше ни у одной другой модели.

Google Deepmind пишут, что модель создавалась для автоматизации и agentic experiences, а input context у нее - 1M.

В итоге по очкам Gemini Flash модель поднялась на 7 место. При этом, возможно, у модели самая низкая цена в TOP-15 (цену я не нашел, пока считаем, что она как у Flash 1.5).

Google продолжает удивлять, довольно кучно выпуская модели, которые попадают в TOP-10 бенчмарка. Из-за этого старые фавориты вроде Mistral / Anthropic постепенно съезжают куда-то вниз. При этом они не становятся хуже, просто у нас появляется больше выбора. И это здорово!

Ваш, @llm_under_hood 🤗

PS: Для тех, кто видит бенчмарки впервые, подробнее про них написано тут.

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

LLM под капотом

На курсе в рамках изучения Sandbox + Structured Output + CoT я включил такую практическую задачку.

Нужно написать скрипт, который позволит задавать text-to-sql вопросы по базам данных (вот тестовая SQLite из этого задания - DB1). Это тестовое задание, поэтому весь пайплайн можно собрать на коленке в Jupyter Notebook или PyCharm. Строчек 100 Python тут хватит.

Весь скрипт - это просто последовательность шагов, которая буквально реализует простой паттерн:

(1) передаем вопрос пользователя c контекстом в LLM, просим написать SQL
(2) выполняем SQL по базе
(3) возвращаем ответ DB на экран

Есть набор тестовых вопросов с каноническими ответами (я их докину в комментарии), по которым можно посчитать accuracy score. И все задание состоит в вопросах:

(1) Посчитать accuracy score для каждого варианта БД.
(2) Почему оно такое низкое/высокое?
(3) Как можно улучшить качество?
(4) А что будет, если спросить у вашей системы "How many firemen work at the company?"? Что именно нагаллюцинирует система, и как этого избежать?

Если кто-то захочет попробовать решить эту задачку - в комментариях к этому посту я выложу список из вопросов для БД c правильными ответами.

Можно попробовать собрать свой pipeline и поделиться полученным числом правильных ответов. Да, и что именно отвечает ваша система на вопрос "How many women work at the company?"

Ваш, @llm_under_hood 🤗

PS: А еще в этом практическом задании специально зарыто несколько грабель. В одни из них можно наступить просто выполняя это задание. А в другие только сегодня утром в учебных условиях наступил победитель Enteprise RAG Challenge (просто они его еще не стукнули 😈).

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

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

LLM под капотом

А как же дела у AIFG Innovation Factory Malta?

Помните, в середине ноября я писал об акселераторе, который запускает компания Mellifera при поддержке ООН?

Это программа для стартапов, чья идея продукта отвечает одной из Sustainable Development Goals ООН и реализуется при помощи AI. Проводится онлайн, принимающая страна - Мальта, в конце программы будет финал, победитель которого едет представлять свой продукт на саммите AIFG в Женеве.

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

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

География заявок тоже оказалась шире, чем предполагали - это страны СНГ, РФ, США, Азия, страны ЕС. При этом одно из условий участия (поскольку конкурс с Мальты) - наличие компании на Мальте, которую нужно открыть до конца марта 2025. Здесь Mellifera готова оказать помощь компании-победителю, независимо от географии.

Про timeline дальше. Как написано в письме от Mellifera для фаундеров из нашего канала - ваши расширенные анкеты ждут до 18 декабря. По анкетам проведут отбор и часть команд позовут на питчинг в январе, чтобы отобрать 5 команд в bootcamp. Он начнется в феврале.

Если кто-то хочет успеть податься с нуля - да, это еще можно сделать. Заполняйте сразу расширенную анкету.

Про самые значимые события Innovation Factory я буду упоминать в канале. Но основной канал коммуникации с фаундерами, подавшими заявки, будет с почтового адреса от Mellifera.

Ваш, @llm_under_hood 🤗

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

LLM под капотом

Мы запустили вторую когорту курса!

Мы провели первую когорту курса по AI ассистентам, собрали feedback и прошлым вечером запустили новую когорту.

Когорта небольшая. Это поможет провести качественный Q&A, собрать feedback, улучшить подачу материала и быстрее открыть продажи для всех.

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

Вот список апдейтов и улучшений курса, которые уже сделали на основе обратной связи первой когорты:

Update 1
- Предварительно загружаем только метаданные для видео (чтобы снизить нагрузку, когда курс проходят с телефона)

Update 2
- Unit 2.2 Prompt - Добавили в методические материалы пример query expansion - промпта из проекта про поиск в документах компании.
- Unit 2.16 Structured Outputs & Custom CoT - Добавили в методические материалы пример Pydantic класса для анализа compliance документов, с разбором почему некоторые поля сделаны именно так, а не иначе. Заодно там демонстрация tagged unions в Pydantic.

Update 3
- Unit 2.4 Knowledge Base - добавили ссылку на разбор кейса про Multilingual Biz Translator (Кейс с ChatGPT про 10.000 € в месяц)
- Unit 2.7 Sandbox - добавили ссылку на использование Self-serve BI Dashboards (из детективной истории)
- Unit 2.12 Human in the Loop - добавили ссылку на Creative Content Generator.
- Unit 2.13 Structured Data Extraction - добавили ссылки на кейсы про извлечение данных компонентов (тут и тут)
- Unit 2.14 REPL - добавили ссылки на кейсы про SEO Keyword generation и автоматическое исправление ошибок

Update 4
- Unit 2.7 Sandbox - Добавили практическое задание по text-to-sql с двумя заполненными БД и доп вопросами (воспроизведение кейса Self-serve BI Reports)

Update 5
- Unit 2.7 Sandbox - обновили org_structure_db2.sqlite в задаче. Теперь Employee таблицы заполнены

Update 6
- Unit 2.7 Sandbox: Добавили второе практическое задание по написанию text-to-code прототипа (на базе первого)
- Unit 2.7 Sandbox: Добавили пример промпта для text-to-code, анонимизированный из одного из кейсов.

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

Большое спасибо всем, кто делится обратной связью, участвует в воркшопах по улучшению курса и оставляет отзывы!

Ваш, @llm_under_hood 🤗

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

LLM под капотом

Бенчмарк Gemini Experimental 1121 - седьмое место, unobtanium

Google освоились с LLM, они продолжают выпускать модели, которые кучно попадают в TOP 10. Новая экспериментальная версия повторяет этот тренд. Она немного хуже топовой Gemini 1.5 Pro, особенно в автоматизации задач из Code+Eng. Но хороший reason дает основание ожидать, что модель только станет лучше.

Почему модель - unobtanium? Да потому, что ее пока нигде не достать. Она доступна либо на OpenRouter либо на Google AI Studio с такими дикими rate limits, что на бенчмарк ушло несколько дней и API ключей.

Ваш, @llm_under_hood 🤗

PS: Для тех, кто видит бенчмарки впервые, подробнее про них написано тут.

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

LLM под капотом

Бенчмарк Qwen 2.5 Coder 32B Instruct - сначала расстроит, а потом порадует

Причина для расстройства на экране - Code+Eng в моем бенчмарке у него очень низкий. Я перепроверил ответы - действительно, очень много ошибок. Возможно, это связано с достаточно низким Reason - 46. Code Review ни один не был сделан правильно, анализ кода получился только простой.

Ну а что мы могли ожидать от модели, которая называется Coder? Кстати, чисто генерация кода у модели при этом получается хорошо. Даже в довольно хитрых сценариях. Я дополнительно прогнал text-to-sql бенчмарк (тот, про который рассказывали на докладе Neo4j), и модель догнала по возможностям Sonnet 3.5.

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

А то, что эта кодинг-модель пододвинула рамки качества в продуктового LLM бенчмарка в категории "оно запустится локально на H100/A100"! В этой категории не было заметных скачков с релиза Qwen 1.5 32B в начале этого года.

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

Таблица с результатами text-to-sql и график трендов локальных моделей будут в первом комментарии к этому посту.

Ваш, @llm_under_hood 🤗

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

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

LLM под капотом

Канал достиг очередной вехи в своем развитии. Кто-то завел клон моего аккаунта и начал попрошайничать денег. У одного подписчика попросили 3700$ на BTC.

Профиль выглядит похоже на мой, но вместо двух ll (маленькая буква L) там стоят две II (большая буква i). Сходу даже не отличить.

Сергею отдельное спасибо за бдительность!

Ваш, @llm_under_hood 🤗

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