LLM под капотом

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

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

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

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

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

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

Ваш, @llm_under_hood 🤗

Enterprise RAG Challenge: Updated question generator

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

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

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


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


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

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

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

Ваш, @llm_under_hood 🤗

Enterprise RAG Challenge - новости

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

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

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

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

Ваш, @llm_under_hood 🤗

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

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

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

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

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

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

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

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

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

Ваш, @llm_under_hood 🤗

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

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

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

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

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

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

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

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

Ваш, @llm_under_hood 🤗

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

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

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

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

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

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

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

Ваш, @llm_under_hood 🤗

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

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

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

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

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

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

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

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

Ваш, @llm_under_hood 🤗

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

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

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

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

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

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

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

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

Ваш, @llm_under_hood 🤗

Визуализация Reasoning цепочек - Эпизод IV

Пора заканчивать reasoning историю. В этот раз будет про локальные модели и с картинками в комментариях.

- Эпизод I
- Эпизод II
- Эпизод III
- Reasoning кирпичик для Stargate
- Эпизод IV (этот)


Шаги 23 - 46: Долго и старательно доводил напильником онтологию. Получается в итоге что-то вроде графа, по которому “ползают” ассистенты. Причем в определенный момент, в зависимости от сложности задачи, мы запускаем несколько выделенных ассистентов в разные стороны.

Шаг 47: Задал тестовый compliance вопрос ChatGPT o1 pro. Он думал 2m47s и провалился в грабли, через которые мы перешагнули на шаге 11. А мой reasoning на базе 4o за 25s пришел к правильному выводу.

Шаг 48: Если отобразить семантические связи в виде графа, а потом подсветить на нем пройденные взаимосвязи, то получается интересная визуализация размышлений.

Шаг 49: 4o - это хорошо, но с ним связана куча рисков. А насколько много работы нужно для запуска всей системы целиком локально? Есть только один способ проверить - перенести и посмотреть, насколько сильно она глупеет.

Шаги 50-53: Про портирование работающих Structured Output / CoT цепочек с 4o на более болтливую Qwen2.5-72B-Instruct с “костыльным” constrained decoding.

Шаг 54: Запустил на паре тестовых запросов. Внезапно, но система доходит до конца там, где o1 pro ломается. Похоже, что тщательно вылизанные логические цепочки обладают бОльшим запасом прочности, чем я ожидал.

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

Шаг 56: А что, если вместо Qwen2.5-72B взять модель попроще, проанализировать ошибки, укрепить цепочки, а потом запускать на модели помощнее?..

Вот на этом и все. Графы с цепочками размышлений ассистентов на базе ChatGPT 4o vs Qwen2.5-72B-Instruct закину в комментарии.

Ваш, @llm_under_hood 🤗

PS: Где можно прочитать про технологии выстраивания reasoning цепочек на сложных доменах? Я не знаю, сам этому учусь на ходу. Больше всего помогает Domain-Driven Design, работы Кристофера Александра, основы продуктовой разработки, и технологии из организации lean R&D комманд.

А у какой локальной модели из топовых на моем бенчмарке есть удобный платный хостинг, который поддерживает нормальный constrained decoding (для CoT+SO)? В идеале сразу с openai-compatible API.

Чтобы можно было быстро удаленно потестировать гипотезу до разворачивания vLLM с guidance на каком-нибудь GPU.

Update: спасибо, нашел. Fireworks AI напрямую (или через OpenRouter) поддерживает Structured Outputs!

Ваш, @llm_under_hood 🤗

Reasoning кирпичик для Stargate

В предыдущих постах я оставил закладки, которые, приводят нас к сегодняшнему посту. Итак, следите за руками. Начнем мы с конца.

В прошлом посте я дал небольшую задачку на подумать - “Какой из промптов будет давать более точный ответ?”. Фишка там была в двух моментах.

Во-первых, на этот вопрос нельзя ответить теоретически. Да, можно упоминать головы внимания, positional encoding и кэши. Но на практике могут выстрелить совершенно другие нюансы. Правильного ответа тут нет, но есть правильный ход рассуждений:

(1) я считаю, что система будет работать так
(2) я прогнал код раз 10 и посчитал accuracy, получилось так
(3) я могу объяснить результаты так

Если прогнать этот тест хотя бы раз 5, то получится такая картина:

gpt-4o-2024-11-20
  Prompt q_first accuracy: 5/5 = 100
  Prompt q_last accuracy: 0/5 = 0

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

gpt-4o-mini-2024-07-18
  Prompt q_first accuracy: 0/5 = 0
  Prompt q_last accuracy: 5/5 = 100
gpt-4o-2024-08-06
  Prompt q_first accuracy: 4/5 = 80
  Prompt q_last accuracy: 5/5 = 100

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

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

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

Но если вложить время и усилия, то можно прописать reasoning. Чуть выше я писал историю про шаги в построении своей reasoning системы. Прошлой ночью случился шаг, к которому я шел три месяца:

Шаг N: Задал тестовый compliance вопрос ChatGPT o1 pro. Он думал 2m47s и провалился в грабли, через которые мы перешагнули на 11. А мой reasoning на базе 4o за 25s пришел к правильному выводу.

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

И вот тут у нас есть классное совпадение - в США новый президент как раз объявил про проект Stargate.

Это чисто коммерческий проект по построению AI инфраструктуры на 500B USD, который организовали вместе крупные компании (причем не только из США). Государство там сбоку - ленточку перерезать и помочь с получением всяких разрешений. А бизнес - не дурак - вкладывать деньги будет только есть возможность получить отдачу. Значит, у них уже есть конкретные наработки про окупаемость.

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

Текущих технологий уровня 4o уже хватает, чтобы масштабировать интеллектуальный труд специалистов достаточно высокого уровня (не заменять их, а дополнять и усиливать). Я это прочувствовал, перенося мыслительные цепочки в compliance на логические блоки в reasoning системе. А что если использовать в качестве движка не 4o а сразу o1 pro? А что если активнее использовать o1 pro или o3 pro для процесса переноса?

У нас же появляется возможность масштабировать процессы и отрасли, которые раньше упирались в банальную нехватку специалистов! И вот тут начнется самое интересное. Скорее всего, это будущее и увидели те компании, которые рискнули вложить немаленькие суммы в проект Stargate.

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

Ваш, @llm_under_hood 🤗

PS: История заканчивается эпизодом IV про визуализацию цепочек.

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

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

from openai import OpenAI
client = OpenAI()

prompt1 = f"How many times is word 'RAG' mentioned in the text? Answer with a number.\n<text>{text}</text>"
prompt2 = f"<text>{text}</text>\nHow many times is word 'RAG' mentioned in the text? Answer with a number."

for p in [prompt1, prompt2]:
    completion = client.chat.completions.create(
      temperature=0,
      model="gpt-4o-2024-11-20",
      messages=[
        {"role": "user", "content":p}
      ]
    )
    print(completion.choices[0].message.content)

Сможете ответить сходу и объяснить почему?

Если сложно сказать, попробуйте запустить код несколько раз и убедиться сами. Абзац текста я добавлю в комментарии.

Второй вопрос - а какой из промптов будет давать более точный ответ в случае использования Structured Output и почему? 😜

class Response(BaseModel):
    how_many_times_is_word_RAG_mentioned_in_text: int

for p in [prompt1, prompt2]:
    completion = client.beta.chat.completions.parse(
      model="gpt-4o-2024-11-20",
      temperature=0,
      response_format=Response,
      messages=[
        {"role": "user", "content": p}
      ]
    )

    print(completion.choices[0].message.parsed)

Ваш, @llm_under_hood 🤗


PS: Это новая задачка, которую я решил добавить в практическую часть курса для выработки интуиции. Уж больно она наглядная и неожиданная.

Что бы вы хотели знать о проблемах и задачах крупных компаний в Европе?

На Enterprise RAG Challenge в конце февраля придет с keynote Stephan Gillich. По его роду деятельности, у него есть куча инсайтов о крупном бизнесе в Европе. Он расскажет про задачи, которые компании пытаются с решать с помощью AI, что у них из этого выходит, и на что есть спрос.

Например, одна из таких вещей - OPEA - это комбайн вроде LangChain для enterprise, но из Linux Foundation и на более высоком уровне. В него вкладываются компании вроде AMD, Intel, ByteDance, SAP и China Unicom. И при этом про него в русскоязычном сегменте мало кто слышал.

Кстати, Stephan говорит, что спрос на локальные решения сейчас на самом деле очень большой, и Project Digits от NVidia вышел в очень удачное время.

Эти топики уже интересны, и будет про них очень здорово услышать подробнее. Но, может быть, еще есть какие-то вопросы вокруг этих тем? Задавайте свои вопросы в комментарии, я потом их соберу, обработаю и вынесу на Q&A сессию после Keynote.

Ваш, @llm_under_hood 🤗

Titan - альтернатива трансформерам от Google #разбор

Google тут втихую выложил интересную работу про LLM с улучшенной памятью и потенциальным контекстом более 2M. Если учитывать то, что Google в последнее время кучно выпускает модели, которые попадают в TOP-10 моего бизнес-бенчмарка, то потенциал у этой затеи очень интересный.

Если в обычном Transformer память о прошлых токенах хранится только в рамках короткого окна self-attention (и приходится хитрить со Structured Checklists, чтобы оптимизировать внимание), то в Titans вводится многокомпонентная система памяти:

(1) Краткосрочная память (ограниченное скользящее окно внимания).
(2) Долгосрочная память (онлайн-обучаемая нейронная память).
(3) Постоянная память (фиксированный набор параметров для общих знаний).

Такое построение позволяет модели "учиться" на неожиданных событиях прямо во время inference. По сравнению с трансформерами, Titans обеспечивают:

(1) Более эффективную работу с очень длинными контекстами, перекладывая «глобальное» запоминание с дорогого self-attention на лёгкий по вычислительным затратам механизм памяти (ближе к O(n) или O (n log n), нежели тупиковый O(n*n))
(2) Увеличенную способность «доставать» нужную информацию из глубокого прошлого за счёт специального, динамически обновляемого модуля.

Это теоретически дает превосходство на ряде бенчмарков, где требуется действительно долгосрочное моделирование (например, cверхдлинные «needle-in-haystack» задачи, задачи из time-series и геномики).

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

Прочитать статью можно тут.

Ваш, @llm_under_hood 🤗

PS: Google могли бы оптимизировать модели под использование GPU и CPU тесном тандеме, и тогда они могли бы работать только на системах вроде Google TPU или новых супер-чипов NVidia. Но именно в этой архитектуре обновления памяти специально распараллеливаются так, чтобы работать хорошо на традиционных акселераторах. Молодцы!

Как за $1.5 получить 24M входящих и 2.4M исходящих токенов Llama 3.3 70B на FP8?

Про это прямо сейчас в чатике канала рассказывает Seva Leonov с картинками бенчмарков.

Важно! Eсли заходите в чат впервые, не пропустите запрос на верификацию от нашего бота защиты от спама (иначе через 60 секунд забанит)

Ссылка на обсуждение в чате.

Ваш, @llm_under_hood 🤗

Одна история разработки своего Reasoning - Эпизод III

- Эпизод I
- Эпизод II

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

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

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

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

Шаг 21. Я смог получить работающий блок планирования ответа!

Надо обязательно перед запуском планировщика определять перспективу, с которой мы смотрим на вопрос (она описана в регуляторном документе). Грузим релевантную онтологию в схему, докидываем пару ключевых слов для общего настроя и, вуаля, внезапно планировщик начинает видеть нужные нам нюансы в терминах. Во всяком случае теперь ответ всегда один и тот же, сколько раз не вызывай. С этим можно работать. Это поддается тестированию и аудиту.

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

Эх, заново индексировать. Ладно хоть LLM не просят доплату за нудность работы.

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

Конец.

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

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

Смотря на все эти телодвижения ретроспективно понятны две вещи.

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

(2) Неземной респект командам OpenAI, которые смогли сделать reasoning движок, который само-адаптируется под неизвестные заранее вопросы. Причем не просто адаптируется, но и очень часто умудряется находить хорошие ответы на очень сложные вопросы. Это вам не классифицировать запросы пользователя по предвычисленным “в лоб” онтологиям предметной области.

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

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

Ваш, @llm_under_hood 🤗

PS: Схема архитектуры на этот момент - в комментариях.

Одна история разработки своего Reasoning - Эпизод II

Продолжение Эпизода I

Шаг 12. Приделал свой tracing, чтобы удобно было смотреть все, что происходит под капотом каждого логического блока. Даже сделал так, чтобы было удобно копипастить полный дамп в ChatGPT на предмет анализа. Ну как я? Мои лучшие друзья - ChatGPT и Claude. Заодно и визуализацию для JupyterLab сделали.

Шаг 13. Прошка умно анализирует и видит ошибки. Она пишет красивые и хорошие промпты, которые... совершенно не помогают в этом пресловутом вопросе. А текста там всего 1000 токенов! Но зато хоть отладил "обвязку" для быстрой проверки гипотез.

Шаг 14. В процессе понял, что при работе с разными типами вопросов и регулирующими документами нужны свои онтологии. Своя карта знаний - для каждой пачки документов. Это можно делать заранее, опираясь на опыт экспертов, а потом при поиске информации грузить эту онтологию прямо в структуры пайплайнов поиска. Такой модульный RAG.

Но проблему со стабильным ответом на тот вопрос это не решает...

Шаг 15. Ничего не работает. Дурацкая GPT-4o, ничего не может, хотя все факты перед глазами. Не эксперт, а новичок, какой-то.

Шаг 16. Думаем. Как я бы мы поставили процесс студенту-новичку? “Не спеши с выводами. Посмотри на вопрос и выпиши все условия, которым он должен удовлетворять, чтобы ответ был верным. А потом исследуй каждое условие в отдельности, поищи в документации, выпиши цитаты. А потом сделай обзор и выводы”. А что если так и сделать? Сначала разбить на под-задачи, исследовать каждую отдельно, подгружая из документов, а потом слить ответ вместе?

Шаг 17. Это сработало! Система не только сама выявила 3 риска в вопросе пользователя, но и решила еще добавить в план анализа “заглянуть в документацию регулятора на эту тему”. Она умничка!

Теперь можно генерировать такие планы, параллельно запускать их на поиск информации и выполнение, а потом делать общий вывод. Прямо o1 pro для конкретной области!

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

Шаг 19. Теряю надежду. Какие только Structured Checklists варианты не пробовал.

По крайней мере у меня есть воспроизводимая проблема - “как из короткого запроса пользователя одним промптом стабильно строить план (или дерево) для дальнейшей работы с документами?”

Третий эпизод задокументирую уже завтра. Он - совсем свежий.

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

OpenAI для этого притащили reinforcement learning.

Ваш, @llm_under_hood 🤗

PS: Эпизод III тут

Одна история разработки своего Reasoning - Эпизод I

Чем больше я пытаюсь повторить reasoning flow o1 pro, тем больше поражаюсь тому, насколько это мощная и сложная вещь. И как только в OpenAI смогли не только додуматься до подхода с reinforcement learning, но и масштабировать его во что-то работающее?

Последние три месяца я исследую задачу в области compliance и рисков. Ретроспективно весь процесс выглядит как будто ребенок на минималках проходит путь OpenAI до reasoning.

Шаг 1. Так, значит, надо отвечать на вопросы по тексту? OpenAI 4o знает все, дадим текст контракта и вопросы к нему и попросим ответить. Что тут сложного?

Шаг 2. Отвечает так себе? Ну добавим поле “подумай перед ответом”, и все станет лучше.

Шаг 3. Ответы действительно есть, и даже хорошие. Но как теперь улучшить ответы на вопросы по комментариям эксперта? Придется смотреть в каждом случае то, что идет на вход промпта и может ли LLM ответить правильно в таких условиях?

Шаг 4. Да я свихнусь вычитывать промпт на 3 страницы A4 шрифтом размера 8! Не удивительно, что и LLM путается. Надо находить релевантные части, чтобы хотя бы я мог разобраться. Давай-ка будем отдельным шагом просить систему фильтровать части контракта по оглавлению и подавать только выбранные на вход.

Шаг 5. Так, теперь картина стала более понятной - мусора меньше и тексты более компактные. Даже могу вычитать промпты глазами. Почему-то LLM тоже стала лучше отвечать. И чего она раньше так не делала?

Шаг 6. Теперь есть еще вопросы, на которые система дает ошибочные ответы. Но там все понятно - релевантные части документов на вход не подгружаются. А не подгружаются потому, что в оглавлении контрактов не всегда видно про что этот фрагмент. Видимо придется подключать дополнительные индексы.

Шаг 7. FTS использовать не хочу, как и вектора, ибо там потом от мусора результаты надо много чистить. О, а сделаю-ка я онтологию всех важных терминов, как это делается в сопроводительных материалах к книгам. Пусть будет Literal c кучей вариантов. Пройдусь по всем фрагментам в контракте и попрошу 4o проиндексировать и привязать.

Шаг 8. Что? OpenAI API вызовы зависают и ломаются, если отправлять слишком большую схему? Интересно, придется вычитать вручную.

Шаг 9. Получается неплохо. Входящий вопрос разбираем на релевантные ключевые слова по онтологии, это можно проверить глазами и протестировать. Потом из документации достаем все фрагменты с этими ключевыми словами и потом отдельным запросом к 4o фильтруем заново на релевантность к вопросу. Это тоже тестируется. А потом отфильтрованные фрагменты подаем на синтез ответа.

Шаг 10. Все стало сильно лучше, находит фрагменты неплохо, ответы тоже выглядят правильно. Но вот есть один простой вопрос. В нем нужно проверить, что контракт явно учитывает три различных риска. Система смотрит, находит упоминание одного риска и закрывает размышления с ответом “да, есть”. А нужно, чтобы были все три!

Шаг 11. Prompt engineering не помогает. Ничего не помогает. Эксперт так не ошибся бы. Особенно если ему сказать “не путай триггеры и риски”.

...

Второй эпизод истории будет попозже. Размером она не лезет в один пост.

А пока - у кого есть какие идеи про подход к построению рабочих reasoning планов для автоматического исследования на основе запроса пользователя?

Ваш, @llm_under_hood 🤗

PS: Эпизод II тут

Enterprise RAG Challenge round 2 - открыт прием заявок!

> Это дружеское соревнование по построению RAG-систем, которое открыто для всех. Для участия нужно будет сгенерировать ответы на вопросы по набору годовых отчетов компаний (PDF) и прислать их.

Исходники генератора вопросов будут открыты до соревнования. Уже можно посмотреть версию первого раунда: main.py. А еще вопросы и ответы. И PDF и ответы других команд. И результаты первого раунда и исходники 4х решений, включая победившее.

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

И да, во втором раунде я генератор вопросов чуть перебалансирую, чтобы усложнить жизнь для таких ленивых CoT/SO/checklist решений. Ибо мы можем двинуть state of the art еще дальше!

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

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

Будет небольшой призовой фонд (500, 350 и 200 евро ваучером на ваш выбор). А еще на мероприятие хочет заглянуть и рассказать про всякое интересное Intel’s Director of AI Go-to-Market and EMEA Lead for the AI Center of Excellence.

👉 Записываться тут 👈

Кому понравился первый раунд, и кто идет на второй?

Ваш, @llm_under_hood 🤗

PS: Кто хочет источников вдохновения - вот исходники 4х решений из первого раунда.

Кейс - поиск ошибок в строительных заказах на покупку

Давно не было разборов кейсов. Давайте расскажу про один из текущих. Он тоже реализуется по концепции LLM Core.

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

Этот проект - обычный data extraction на базе VLM, но есть три нюанса:

(1) Реализовать надо в Google, а у Gemini на Vertex AI пока очень упоротый structured output format (не JSON schema, а Vertex AI API)
(2) Клиент очень медленный. Пачки PDF-ок он прислал, а вот ground truth дата - нет. Ибо организационные пробуксовки помноженные на рождественнские праздники.
(3) Конкуренты хотят использовать Google Document AI и обучать какие-то дополнительные модели. Если сделать надежное решение просто на 1-2 промптах, то команда может хорошо выделиться.

Про детали реализации не буду углубляться, это обычный structured data extraction, как в победителе Enterprise RAG Challenge или кейсе про захват рынка. Из особенностей реализации в этом проекте:

(1) да, нужно возиться с SO форматом на Gemini Pro под Vertex AI, но это решаемая проблема.
(2) отсутствие ground truth data - тоже решаемая проблема. Можно взять другую модель от другого поставщика (например, Claude 3.5 Sonnet v2) и сравнивать ответы разных моделей. Если они сошлись, то обе модели извлекают правильно. Если расходятся, то одна из черепашек – ошибается. Строим heatmap, чтобы понять масштаб проблем и пойти улучшать.
(3) то, что в данном проекте извлечение данных из PDF - это implementation detail. И Gemini и Sonnet по API принимают на вход PDF.
(4) обе модели начинают путаться, когда за раз хочется извлечь заказ на покупку на 20-30 позиций со всеми данными. Разбивка процесса извлечения на два промпта повышает качество. Но есть теория, что нормальный CoT поможет стабильно извлекать одним единственным промптом.

И еще тут возникает интересный момент с тестированием. Команда проекта бралась за него зная, что может быть проблема с получением ground truth data для тестов. А без тестов обычно браться за LLM проекты - я считаю слишком рискованным.

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

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

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

А как вы тестируете свои проекты с LLM под капотом? И что делаете, если удобных данных для тестирования нет?

Ваш, @llm_under_hood 🤗

Sam Altman недавно написал, что ChatGPT pro при цене в 200$ в месяц внезапно оказался убыточен для OpenAI.

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

Причем, Sam Altman говорит ниже, что он сам лично выбирал цену и был уверен в прибыльности.

Не так просто заработать на LLM-ках, даже в OpenAI.

Ваш, @llm_under_hood 🤗

LLM Benchmark - December 2024

Вышел полный отчет по бенчмаркам моделей в business automation за декабрь 2024. Там написано про DeepSeek v3, o1 pro, Gemini 2.0 Flash и еще много других моделей. English / Deutsch

Содержание:

- Benchmarking Llama 3.3, Amazon Nova - nothing outstanding
- Google Gemini 1206, Gemini 2.0 Flash Experimental - TOP 10
- DeepSeek v3
- Manual benchmark of OpenAI o1 pro - Gold Standard.
- Base o1 (medium reasoning effort) - 3rd place
- Our thoughts about recently announced o3
- Our predictions for the 2025 landscape of LLM in business integration
- Enterprise RAG Challenge will take place on February 27th

Ваш, @llm_under_hood 🤗

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

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

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

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

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

Скажем, для небольших AI стартапов в EU, которым нужно работать с личными данными или секретами компаний - это очень выгодное решение. На заточку под работу с RAG-ами еще намекает место для данных - до 4TB flash storage на борту.

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

Ваш, @llm_under_hood 🤗

Как тестировать систему с 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 🤗

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 🤗

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

Неблагодарный прогноз на 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 🎅

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

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

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

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

Ваш, @llm_under_hood 🤗

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

Бенчмарк 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 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 под капотом?

(по мотивам вопроса в 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 под капотом. Ответ будет чуть посложнее.

Я лично (почти) не беру проекты на 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 под капотом, которые встраиваются в продукты или оптимизируют какие-то бизнес-процессы в компаниях США и Европы.

Мне подобные кейсы нравятся тем, что бизнес очень хорошо умеет считать выгоду (а кто не умеет - освобождает место конкурентам на рынке). В такой ситуации у меня быстро отсеиваются подходы и кейсы, которые: (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 под капотом: выбираем эффективные технические решения для AI-ассистентов”.

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

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

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

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

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

Ваш, @llm_under_hood 🎅

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 🤗

Бенчмарк 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: Для тех, кто видит бенчмарки впервые, подробнее про них написано тут.

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

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

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

- o1-mini - самая маленькая и недорогая из Reasoning моделей. Она есть в ChatGPT и по API
- o1-preview - мощная версия, которая раньше была доступна в ChatGPT интерфейсе. Теперь ее оттуда убрали и заменили на просто o1. По 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: Для тех, кто видит бенчмарки впервые, подробнее про них написано тут.

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

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

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

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

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

Ваш, @llm_under_hood 🤗

Бенчмарк 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: Для тех, кто видит бенчмарки впервые, подробнее про них написано тут.

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

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

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

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

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

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

Ваш, @llm_under_hood 🤗

На курсе в рамках изучения 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 дня жизни проекта перед его сдачей.

📦 Бенчмарки нескольких моделей одной пачкой: 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: Для тех, кто видит бенчмарки впервые, подробнее про них написано тут.

А как же дела у 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 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 🤗

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

Мы провели первую когорту курса по 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 - теперь в первом практическом задании три варианта БД

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

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

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

Ваш, @llm_under_hood 🤗

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

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

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

fine-tuning уже все?

Да fine-tuning и никогда не был особо удачной вещью на практике. Его применяют к месту только в одном случае из 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 🤗

Бенчмарк 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: Для тех, кто видит бенчмарки впервые, подробнее про них написано тут.

Бенчмарк 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 под капотом. Про структуру и примеры бенчмарков можно прочитать в лабах или на официальном сайте бенчмарков.

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

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

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

Ваш, @llm_under_hood 🤗

Neo4j, наконец, выложили видео про LLM и text-to-SQL

В этом получасовом докладе мы с коллегой из sister company сравниваем способности разных LLM-ок к генерации запросов для реляционных и графовых баз данных.

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

Слайды есть тут.

Видео: https://youtu.be/YbJVq8ZOsaM?si=r8AjLduNtXcdfq7L

Ваш, @llm_under_hood 🤗

Новости про курс по AI-ассистентам

Пригласительные письма первой когорте отправлены. Проверьте свою почту!

Группу старались сделать небольшой, но разнообразной по бэкграунду, задачам и рабочим ролям.

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

Записаться в waitlist и узнать больше о курсе можно здесь.

Если вы уже записывались, повторно этого делать не нужно: все сохранилось и лист ожидания в силе.

Ваш, @llm_under_hood 🤗

Anthropic Sonnet 3.5 1022 - это очень классная модель

(1) Она поддерживает хорошо работу с PDF
(2) У этой модели есть кэширование промптов
(3) делать structured data extraction с checklist и custom chain of thought на ней одно удовольствие.

Хотя Anthropic пока и не завел structured outputs на базе constrained decoding (как это сделали в OpenAI), но их модели понимают JSON схему без каких-то нареканий. А выход у них пока без ошибок (если не перегружать контекст и соблюдать signal-noise ratio).

Что я делаю для извлечения данных из сложных PDF недорого:

(1) загружаю системный промпт со схемой в первое сообщение. Помечаю для кэширования через "cache_control": {"type": "ephemeral"},. Схему конвертирую в строку (см ниже) и добавляю к общему описанию задачи:

json.dumps(Model.model_json_schema(), indent=2, ensure_ascii=False)

(2) загружаю PDF напрямую во второе сообщение модели. Также помечаю для кэширования.

У меня PDF достается из CAS, но можно грузить хоть откуда. Главное - сконвертировать бинарную начинку в base64 для добавления в API запрос (так сделана работа с документами в бете):

def read_pdf_as_base64(env: Env, hash: str):
    with env.storage.read_cas(hash) as file:
        return base64.standard_b64encode(file.read()).decode('utf-8')

Кстати, под капотом Anthropic не просто распарсит PDF в текст, но и приложит картинки страниц к этому тексту. Это заметно повышает качество ответов.

(3) помещаю задачу из чеклиста в третье сообщение, уже не кэширую.
(4) в последнее сообщение добавляю

{
    "role": "assistant",
    "content": "Here is the JSON requested:\n{"
}

(5) к ответу модели добавляю { и валидирую загрузкой в исходную pydantic model

И потом все будет работать так:

results = []
for pdf in pdfs:
  for question in checklist:
    result = extract_data(schema, pdf, question)
    results.append(result)

Причем schema кэшируется на все запросы, а содержимое pdf (самое большое) переиспользуется на все вопросы из чеклиста.

Такой процесс в итоге работает точнее и проще, чем комбайн из openAI GPT-4o со structured outputs и предобработкой PDF в отдельных специализированных моделях.

Ваш, @llm_under_hood 🤗

PS: Бенчмарк модели будет попозже

А давайте запустим в канале акселератор AI-проектов?

AI Bootcamp: AI For Good

Идея такая. Мы ищем проекты и стартапы c LLM под капотом, у которых есть социально значимые цели. Проект может быть на стадии от “есть оформившаяся идея, которую мы уже начали пилить” до “есть MVP, который хотим уже показывать клиентам и инвесторам”.

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

Участие полностью удаленное. Но есть три ключевых требования:
(1) Идея проекта должна быть социально значима: она должна решать хотя бы одну из задач в списке Sustainable Development Goals от ООН. Это проще, чем кажется: SDG достаточно широкие и универсальные, и многие проекты способны внести свой вклад - важно лишь увидеть, как именно ваша идея может быть здесь полезной.
(2) Команда должна быть потенциально заинтересована в запуске проекта и открытии компании на Мальте.
(3) Должно быть реальное желание развиваться и двигать свой проект вперед. Это bootcamp, и мы будем плотно работать с командами в нем.

Да, участвовать из РФ тоже можно.
Язык коммуникации - английский.

Почему такие требования?

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

Если вы присоединитесь к bootcamp (первый шаг - заполнить предварительную анкету по ссылке), то с декабря мы начнем предварительно общаться, а в январе - плотно работать: воркшопы, курсы, лекции. 🔥 Здесь постараемся подключить представителей интересных компаний вроде Mistral AI и Anthropic. Как я уже говорил, участие в проектах ООН открывает много дверей.

До весны мы будем помогать вам развивать ваши идеи и продукты. Самое интересное начнется в марте - команды презентуют свои идеи и наработки жюри в финале на Мальте. А компания-финалист получит возможность поехать летом в Женеву на мировой финал инициативы AI for Good - презентовать свою идею жюри ООН, знакомиться с инвесторами и компаниями глобального уровня. К слову, на саммите AIFG выступал и Sam Altman.

Как поехать, как оформить визы, как зарегистрировать, как разобраться с финансированием - с этим всем, естественно, поможем. Поездку в Женеву оплатим. Если не запускали стартапы, не работали с инвестициями или не выходили на рынок Европы - не страшно. Задача bootcamp - научить и помочь вывести на рынок социально значимый продукт с LLM под капотом.

Кстати, переезжать на Мальту не требуется. Это уже только при желании.

Интересно?

👉 Заполняйте форму на сайте. Срок до конца ноября.
👉 Если есть вопросы - задавайте в комментариях или пишите @akitka, @abdullin.
👉 Смело делитесь этим сообщением - буткамп запустится только если будет достаточное количество стартапов-участников на входе.

NB: Понимаю, что Sustainable Development Goals от ООН можно интерпретировать по-разному. Можно удариться в greenwashing и политику. Наш AI bootcamp не про это, а про то, чтобы помочь запустить идею, которая реально может помочь сделать мир лучше. Поэтому, пожалуйста, давайте в комментариях фокусироваться на позитивной стороне. Она точно есть.

Ваш, @llm_under_hood 🤗

Итак, тот самый курс от LLM под капотом

готов, и мы набираем первую когорту участников. Ссылка ниже.

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

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

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

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

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

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

Ответы на вопросы про курс собраны тут 👈. Там же можно заполнить форму на участие в первой когорте или просто оставить email для получения уведомления о начале общих продаж.

На скриншоте - общая карта всех материалов курса. Если приглядеться, то можно разглядеть слайды с разбором кейса про Sales Lead Generation. Анализ Checklists и Custom Chain of Thought там рядом.

Ваш, @llm_under_hood 🤗

“Ринат не делает чат-ботов!”

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

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

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

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

(1) чтобы учитывал предыдущие сообщения в чате
(2) чтобы знал дату рождения директора
(3) чтобы разговаривал вежливо и корректно
(4) чтобы не лил воду и говорил кратко
(5) чтобы мог подстраиваться под хотелки каждого пользователя
(6) чтобы никогда не галлюцинировал про финансы
(7) чтобы учитывал права доступа пользователя при доступе к документам
(8) чтобы знал имя собаки директора
(9) чтобы учился на ошибках
(10) чтобы читал Excel файлы.

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

Да, такой проект может принести вендору более 1M EUR, но он растянется на месяцы и легко загрузит команду в 4-6 человек на это время (это цифры из конкретного кейса, который до сих пор пилят).

Я предпочитаю вместо длительной возни с одним нудным проектом точечно закрыть 5 мелких проектов. Поэтому я стараюсь выбирать такие проекты, чтобы можно было сказать “мы с вероятностью в +80% можем его быстро сделать так, чтобы клиент был доволен”.

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

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

Наглядный пример. Вчера мы сдали клиенту основную часть проекта по генерации лидов на рынках двух стран. На eval прогоне система прошлась по 330 компаниям из реестра и самостоятельно дополнительную информацию по 58 компаниям. Клиент проверил и сказал, что 10% из этого были известные компании, 42% - мало информации, а вот 48% - это новые компании. Для них мы нашли сайты, почтовые адреса и/или телефоны. Причем это все недавно открытые компании, к которым самое время заходить с предложениями. Выборка была случайная.

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

Естественно, что к этому повороту мы были готовы заранее: “А давайте попробуем в одной из стран пилот разворачивания вот этой удобной CRM, в которую мы будем каждую неделю подгружать новые лиды из AI платформы, продажники будут последовательно по ним проходить, а бизнес будет видеть метрики по процессу. Мы вам все настроим и подключим” - “Ну-ка, расскажите про это подробнее!”

Когда закрывается один AI Case, обычно открывается 2-3 новые возможности проектов. А это означает больше пространства для роста. При этом рост уже не требует AI/LLM/GPT специалистов, там обычные интеграторы и разработчики.

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

Что же я делаю, когда клиенты просят очередного чат-бота?

Это окончание поста. Начало тут.

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

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

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

(1) Проблема - люди тратят 70-80% времени на чтение purchase orders от разных вендоров и ручное вбивание их в систему. Простое решение - сделать копилота, который извлекает данные из purchase orders в таблицы. Data Extraction.

(2) Проблема - компания тратит кучу времени на чтение тендеров на поставку оборудования в новостройки и оценку прибыльности. Простое решение - сделать копилота, который извлекает список позиций из строительных тендеров, а потом сопоставляет с фактическими затратами на аналогичные позиции из истории. Задача здесь не делать точную систему, а систему, которая достаточно хорошо и быстро сможет дать оценку любому тендеру данного клиента. Data Extraction + Search (Query Expansion)

(3) Проблема - крупная юридическая компания тратит кучу времени своих адвокатов (а это 300 евро в час) на составление инвойсов на услуги. Простое решение - сделат копилота, который берет неструктурированные time-sheets и преобразует их в черновики детализированных инвойсов для клиента. Data Exraction + Transformation.

Что общее в этих примерах - scope проекта очень четко очерчен. Можно забрать себе размеченные документы с ground-truth и потом спокойно с ними поработать. И сильно меньше вероятности, что возникнут неожиданные хотелки внутри проекта - мы либо преобразовываем информацию точно по спецификациям либо нет.

Если получается, то проект считаем сданным. А потом по схеме: "Да, кстати, а вам нужно его удобно интегрировать в рабочий процесс сотрудников или еще решить вот такую проблему? Мы можем тут предложить…"

Ваш, @llm_under_hood 🤗

История развития State of the Art локальных моделей.

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

Gemini 1.5 Flash 8B добавлен со звездочкой - его нельзя выкачать и запустить локально. Надо будет ждать, пока не появится открытая модель.

NB: Модели разделены условно на те категории железа, которые я чаще всего вижу у клиентов. Считаем VRAM на запуск с запасом места под контекст и без квантизаций.

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

Маленькие модели, которые влазят в 4090, достаточно долго стагнировали. Gemini 1.5 Flash 8B стал недавно внезапным рывком.

Ваш, @llm_under_hood 🤗

Бенчмарк Claude 3.5 Haiku - дороже и умнее

Новая младшая модель от Anthropic отражает тренд последовательного роста качества небольших моделей. Haiku в среднем подтянула очки по общим показателям, за исключением Code+Eng (*)

А еще у модели почти в два раза выросла способность мыслить! В категории Reason произошел скачок с 35 до 68. Это самое большое значение среди всех моделей Anthropic. Возможно мы видим новую архитектуру следующего поколения моделей?

На смену архитектуры намекает и четырехкратное увеличение стоимости Anthropic Haiku. Теперь она уже не "смышленая и очень дешевая". Можно найти подешевле и умнее. Например, GPT-4o Mini или Google Gemini Flash 1.5 8B.

Но общий тренд роста качества моделей радует. Посмотрим, не проявится ли рост Reason в следующих релизах моделей постарше.

Ваш, @llm_under_hood 🤗

(*) Я переименовал категорию Code в Code+Eng, чтобы точнее отражать наполнение бенчмарков - не только написание кода, но и анализ, review и интерпретация.

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

Лучшие проекты с LLM - это те, которые делают отчеты, а не болтают

Я уже не раз говорил, что я стараюсь не браться за проекты, где клиент хочет себе conversational search или чатбота или что-то еще с текстовым полем "А что вы хотите сделать?"

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

А как тогда быть? Да просто копать в настоящие хотелки клиента и пытаться свернуть продукт туда, где нужно работать с процессами или системами.

Только вчера шло обсуждение нового клиента, который хотел глобальный data warehouse с conversational search и умными ассистентами. Когда я сказал, что это делать совсем не выгодно - поискали альтернативные варианты и нашли пару кейсов с data extraction (пример кейса) или lead generation (пример кейса).

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

Отчеты бывают читаемые людьми или для выгрузки в системы. Особый UX там не требуется, а если нужно причесать UI, то хватит и GPT-o1 (дизайн на фотке - его). А еще обычно не нужно ничего патчить, внимательно следить за нагрузками и аптаймом. Customer Support сводится к минимуму, а первые итерации можно просто прогонять у себя в юпитере и присылать файлом клиенту.

В общем, проекты с LLM под капотом, которые сводятся к отчетам - это сплошная красота (по скорости закрытия). И, по моей статистике, большинство клиентских ситуаций как раз можно свести к этому. Достаточно просто вспомнить заветы product-driven development и копнуть поглубже.

Ваш, @llm_under_hood 🤗

Бенчмарк новой Claude 3.5 Sonnet v2 - лучше прошлой версии, но не TOP 10.

Только что в Anthropic зарелизили Claude 3.5 Sonnet v2. На продуктовом бенчмарке она в TOP 10 не попала, заняв 11ое место в общем зачете.

У новой версии подтянули следование инструкциям и работу с кодом (Code - это не только написание кода, но и анализ, преобразования и рефакторинг).

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

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

Ваш, @llm_under_hood 🤗

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

Кейс - графовая система организации знаний для завода / корпорации.

На TedAI Vienna я встретился с ребятами, которые пилят Data Context Hub - систему для организации корпоративной системы знаний для заводов и огранизаций. Эта система подгребает под себя разносторонние источники данных и потом выстявляет наружу API для работы с ними.

Например, API для ответа на вопрос, “а сколько гаек X12123 версии 123 было использовано в машинах на последней неделе?” или “а кто может заменить рабочего X, которому надо нарезать 345 гаек X12123 версии 124, но заболел?”

Самое интересное у них:

(1) Они рано поняли, что векторные базы, семантический чанкинг (или любой чанкинг) - это бесполезная и вредная фигня в тех областях, где галлюцинации нам не нужны.
(2) Достаточно быстро поняли, что секретный рецепт для получения точных ответов на разнообразные ответы - “просто надо нормально предобрабатывать и структурировать данные”.
(3) Плюс быстро сообразили, что generic chatbot interface - это тупиковый путь. Лучше выставлять наружу специализированные интерфейсы под конкретные задачи, которые будут работать заведомо лучше (Dedicated Agents с заранее собранным инструментарием и контекстом под задачи)

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

Поэтому они они после data intake ставят context mapping layer (все читали про Context Map из Domain Driven Design, так ведь?) В нем поток сырых данных размечается, сопоставляется, привязывается к сущностям и контекстам. И эти ребята просто выставили наружу интерфейс, в котором эксперты у клиента сами могут набросать правила преобразования их собственных сырых данных в их собственные размеченные данные. А если что-то не работает - поменять.

Подход похож на knowledge mapping, например из ассистента маркетолога, только в последнем эксперты у нас еще и сами данные раскладывали 😎

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

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

Авторы Data Context Hub партнерятся с BMW и Siemens. Судя по всему, точности и гибкости системы хватает для небольших заводиков.

Кстати, забавно, что на сайте в use cases они еще упоминают embeddings, но в самой документации к продукту ни слова про вектора/chunks/embeddings. Возможно, хотят направить не слишком внимательных конкурентов по ложному следу.

Ваш, @llm_under_hood 🤗

На TedAI Vienna. Создатель xLSTM рассказывает про свой новый проект, который не использует трансформеры.

Кто-нибудь ещё пришел сюда?

Бенчмарк Grok-2 от X.AI - 12 место

Это было внезапно. Я от X.AI не ожидал ничего работающего. Но у них Grok-2 неожиданно оказалась настолько хороша по показателям на продуктовом бенчмарке, что заняла место в первой дюжине. Даже Reason не самый стыдный - 58.

У модели в соседях - старые версии GPT-4, но она все же будет пониже, чем локальная Qwen 2.5.

При этом пользоваться ей пока совершенно невозможно - на OpenRouter дикие RateLimits.

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

Ваш, @llm_under_hood 🤗

🔗 Бенчмарк GPT o1 - топовая модель
🔗 Бенчмарк Qwen 2.5 - лучшая локальная модель
🔗 Бенчмарк Google Flash 1.5 8B - Прекрасное далеко

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

PS: Слайд про подобных агентов из курса. Эту часть я уже записал и переделывать даже не надо)

OpenAI Swarm - пример мультиагентной системы

OpenAI написали целую статью про организацию агентов и открыли небольшой фреймворк с примерами - Swarm.

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

refund_agent = Agent(
    name="Refund Agent",
    instructions="You are a refund agent. Help the user with refunds.",
    tools=[execute_refund],
)

def transfer_to_refunds():
    return refund_agent

sales_assistant = Agent(
    name="Sales Assistant",
    instructions="You are a sales assistant. Sell the user a product.",
    tools=[place_order],
)

Для красоты они еще добавляют TriageAgent, который может переключать между нужными агентами:

triage_agent = Agent(
    name="Triage Agent",
    instructions=(
        "You are a customer service bot for ACME Inc. "
        "Introduce yourself. Always be very brief. "
        "Gather information to direct the customer to the right department. "
        "But make your questions subtle and natural."
    ),
    tools=[transfer_to_sales_agent, transfer_to_issues_and_repairs, escalate_to_human],
)

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

Концепция агентов - простых функций, со своим контекстом и набором инструментов работает очень хорошо. Помните, я в Марте писал про AI Ассистента для международной компании?

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

У каких-то агентов были инструменты в виде FTS поиска, какие-то знали, в каких папках искать, у третьих в контекст был встроен FAQ. А на входе стоял Triage Agent. Но тогда я еще не умел пользоваться tools/structured output, и в коде было много ненужных промптов и костылей. Сейчас это делается еще проще.

А как в ассистенте заранее знать, какие будут вопросы, чтобы подготовить армию агентов? Да просто смотреть на предметную область и задавать вопросы! В своем примере (который основывается на куче опыта) ребята из OpenAI же откуда-то узнали, что нужен TriageAgent/RepairsAgent/SaleAssistantAgent и RefundAgent?

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

Кто еще смотрел этот код? Что думаете?

Ваш, @llm_under_hood 🤗

Аренда H100 за $2 в час - про резкое падение цен на GPU

Очень детальный разбор ситуации есть в новой статье на latent space.

Если кратко, то в прошлом году было сложно арендовать H100 за 8 долларов в час в заметных количествах. В последние месяцы из-за кучи факторов среднаяя стоимость стала падать до двух долларов. См, например, цены на площадке SFCompute.

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

Но есть один нюанс. Рынок - не дурак. Относительно дешевые конфигурации H100 - это пока именно, что излишки. Там, скорее всего, не будет InfiniBand, будут медленные хосты, проблемы с сетками или молодой неопытный оператор. Чем ниже цена - тем больше грабель.

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

Ваш, @llm_under_hood 🤗

Настал тот момент, когда мы замучались удалять ботов

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

Бот только что вышел на стражу. В нем целых 166 строчек кода на golang. Его от Shieldy отличает то, что логику верификации теперь мы можем переписать очень быстро.

Если кто хочет - может попробовать его сломать. У вас есть одна попытка 😎

Ваш, @llm_under_hood 🤗

PS: Бот заменяет старого Shieldy и срабатывает только на момент добавления и верификации. Существующие сообщения модерируются, как и раньше, вручную. В добром чатике банят только за спам, яростный оффтопик и токсичность.

Как может выглядеть checklist?

Например, так, как на картинках. Это скриншоты из бенчмарка, который мы делаем для доклада на NODES '24 (Neo4j dev conference).

Этот бенчмарк оценивает то, как качественно LLM преобразовывает запрос пользователя в запрос по базе данных (SQLite/neo4j).

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

Добавление такой chain of thought (захардкоженной в виде structured output) улучшает качество ответов с 76 до 81 на этом бенчмарке.

Вы пробовали такой подход? Напишите про результаты!

Ваш, @llm_under_hood 🤗

Бенчмарк Google Flash 1.5 8B - Прекрасное далеко

Помните недавно мы разбирали маленькие локальные модели от Llama 3.2, и там они прямо подвинули State-of-the-art? На этом прогресс не останавливается.

У Google стала доступна новая версия Gemini Flash 1.5 8B, и она показывает очень хорошие результаты на моих продуктовых бенчмарках . Эта модель размера 8B держится на уровне старых GPT 3.5 или Llama 3 70B. Она почти догоняет обычную 1.5 Flash по бенчмаркам.

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

Зато Gemini Flash 1.5 8B можно использовать очень недорого. Плюс, как это продемонстрировал сам Google - все, что сделала одна компания, другая сможет повторить. Поэтому ждем открытых моделей такого же уровня.

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

Ваш, @llm_under_hood 🤗

🔗 Бенчмарк GPT o1 - топовая модель
🔗 Бенчмарк Qwen 2.5 - лучшая локальная модель
🔗 Gemini 1.5 Pro 002 - внезапно третье место!


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

OpenAI Canvas - аналог Claude Artifacts

OpenAI подсуетились и встроили в свой интерфейс режим Canvas. Он сильно похож на вариант от Anthropic и работает на GPT-4o.

В обоих случаях мы можем работать с текстом и кодом. ChatGPT может редактировать код, делать ревью, работать с комментариями и логами. На скриншоте пример, когда я отправил прототип golang http сервера в canvas и попросил сделать review кода.

OpenAI не поленились и вынесли отдельные операции (Code Review, Port to a language итп) прямо в кнопки в интерфейсе. Это хорошо - они наверняка отладили эти промпты на куче тестовых кейсов.

Еще можно выделить кусок текста на экране и попросить ChatGPT изменить его или объяснить. Переключение между версиями есть тоже.

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

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

В общем, если у вас есть стартап или свой продукт - избегайте очевидных тропинок, по которым уже идет куча других компаний и могут пойти крупные игроки. Рискованное это дело. Скорость, с которой OpenAI повторили ключевой функционал Anthropic Artifacts это показывает.

Я лично использую Aider (см мой текущий AI Coding setup) для работы проектами на много файлов, и ему ChatGPT конкуренции пока не составляет, только Claude.

Ваш, @llm_under_hood 🤗

PS: А еще Canvas удобен для работы не только с кодом, но и текстом.

Исходники 4-х решений из Enterprise RAG Challenge

Месяц назад у нас прошел первый раунд Enterprise RAG Challenge - дружеского соревнования по построению AI ассистентов на годовых отчетах компаний.

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

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

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

Если кратко:
- daniel - решение-победитель на базе checklist + structured outputs. Первое место.
- felix - multi-agent решение на базе ChatGPT-4o. Двенадцатое место.
- maria - assistants API. Тринадцатое место.
- pedro - локальное решение на базе openchat-3.5-0106. Девятое место.

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

Во втором раунде генератор вопросов будет перебалансирован, чтобы:
(1) было меньше вопросов без ответов (c N/A)
(2) было больше вариативности в вопросах, чтобы подход “в лоб” с checklist + structured outputs больше не мог так легко занять топовые места.

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

Ваш, @llm_under_hood 🤗

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

Бенчмарки Llama 3.2 - Так себе, но есть маленький нюанс 🤩

Meta недавно выпустила новые версии своей локальной модели Llama - 3.2.

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

Смотрим на первую таблицу:
Llama 3.2 90B Vision работает на уровне Llama 3/3.1 70B
Llama 3.2 11B Vision работает на уровне прошлых 8B

Чисто по поведению на бенчмарках выглядит так, словно рост в ~20% размере моделей как раз обусловлен добавлением мультимодальных способностей к старым версиям. А небольшая просадка качества - тем, что дообучали на новых модальностях в ущерб текстовому качеству.

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

И еще есть маленький нюанс, который круче всего остального в этом релизе. Размер маленького нюанса - 1B и 3B. Эти крошки заточены на работу "on-the-edge" даже с относительно слабыми процессорами (процессоры ARM, железо Qualcomm и MediaTek). При этом у них контекст в 128K tokens, а качество и следование инструкциям на продуктовых задачах неожиданно офигенные.

Помните я говорил, что DBRX 132B Instruct - это никому не нужная ерунда? Так вот, Meta Llama 1B ее догоняет, а 3B - уделывает. В общем, смотрите сами на соседей этих моделей на второй таблице.

А ведь это еще базовые модели без тюнов. Тюны обычно повышают качество моделей Meta на этом бенчмарке еще больше.

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

Ваш, @llm_under_hood 🤗

🔗 Бенчмарк GPT o1 - топовая модель
🔗 Бенчмарк Qwen 2.5 - лучшая локальная модель
🔗 Gemini 1.5 Pro 002 - внезапно третье место!

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

Тут выдохнуть спокойно нельзя

Только я сел делать предобработку видео для курса по AI Ассистентам - новость, мол, вышла Llama 3.2. Дайте я хоть расскажу план курса, а потом бенчмарк, ок?

План такой - курс состоит из двух модулей. Они будут доступны на моей площадке ML Labs, формат - текст и видео. По времени и стоимости напишу отдельно попозже.

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

Второй модуль полностью новый. Я прошелся по всем кейсам успешного внедрения LLM/AI на текущий момент, систематизировал их и вывел повторяющиеся архитектурные паттерны. Эти паттерны с особенностями применения я и показываю, разберем кейсы с их использованием. Второй модуль дает “насмотренность” на текущее использование LLM в отраслях из моих кейсов в современных компаниях: это структурированные знания, которые клиенты уже применяют.

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

Помимо теоретической части и видео будет доступен отдельный практикум, чтобы разобрать вопросы и поговорить более предметно. Как и весенние вебинары, практикум на продажу записываться не будет. Можно будет приносить свои кейсы для обсуждения - они за пределы группы не выйдут. А все выпускники получают доступ в коммьюнити. Кстати, нынче там обсуждают расценки на создание юридических RAG с нуля, механизмы внимания в LLM и делятся бенчмарками Qwen2.5/Llama70B на H100/H200 для максимальной окупаемости.

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

Ваш, @llm_under_hood 🤗

PS: А дальше будет бенчмарк LLama 3.2

Gemini 1.5 Pro 002 - третье место в бенчмарке! 🚀

Ребята из Google - молодцы. Релиз за релизом они последовательно повышали качество своих моделей, как Gemini Flash, так и Gemini Pro. Последняя версия Gemini Pro заняла третье место в моем продуктовом бенчмарке. При этом она потеснила относительно бесполезный (за такие деньги) GPT o1-mini.

В Gemini 1.5 Pro v002 Google подтянули все параметры - работу с кодом, документами, маркетинговыми текстами и даже сложный Reason. Стоимость немного меньше, чем GPT-4o со второго места бенчмарка.

В нашем чатике хвалят Gemini Pro за работу с разными языками. А клиенты из Google Cloud вообще радуются тому, что у них появилась своя нормальная LLM.

Долгое время казалось, что OpenAI и Anthropic - это единственные компании, которые могут делать передовые модели. И что крупные компании слишком медленны и отсталы для этого. Google смогли доказать, что это не так. Теперь можно начинать ждать классных моделей подобного уровня от Amazon и Microsoft. А там, глядишь, начнется и конкуренция с повышением качества и снижением цен :)

В комментариях к посту еще есть график динамики прогресса моделей Google со временем (как и всех hosted моделей) и сравнительная табличка с бенчмарками для всех моделей Google.

Ваш, @llm_under_hood 🤗

🔗 Бенчмарк GPT o1 - топовая модель
🔗 Бенчмарк Qwen 2.5 - лучшая локальная модель

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