12420
Канал про разработку продуктов на базе LLM/ChatGPT. Выжимка важных новостей и разборы кейсов.
Enterprise RAG Challenge - тестовый прогон 20 февраля
Завтра, 20 февраля в 12:00 UTC+1 / 14:00 MOW пройдет тестовый прогон Enterprise RAG Challenge. Это будет просто тестовая проверка всех систем. Я сгенерирую вопросы, выложу PDF, покажу запущенный Submission API/UI.
Если интересно задать свои вопросы и пообщаться, то приходите в discord (ссылка на него приходит после регистрации). Но это не обязательно. API и файлы останутся доступны и после, а ссылки я на них продублирую.
Ваш, @llm_under_hood 🤗
PS: Кстати, у участия в RAG Challenge или курсе по ассистентам есть побочный эффект - вас могут схантить к себе в команду. Были уже прецеденты. Так вот, не удивляйтесь, если произойдет такое:
Блин. Мне тут из-за тебя походу новую работу предложили
Ну вот найти бы продажника кто пошел и купил этот курс) Есть тут такие?)Читать полностью…
AI in Coding или эксперимент с агентами
Если кратко, у нас на одном проекте стоит повторяющаяся задача. Нужно извлекать структурированную информацию из сайтов. Структура известна достаточно жестко, но сайты постоянно меняются. И каждый раз ходить по страницам, выбирать html, писать селекторы итп - надоедает.
Коллега, который сталкивается с этой задачей не в первый раз, решил попробовать написать пару кодинг агентов с инструментами. Идея такая - натравливаем их на какой-то сайт и уходим пить чай. По возвращении получаем готовый код, который уже может автоматически извлечь данные из сайта.
Поэтому решили поставить эксперимент - выделить пару дней на попытку прототипирования таких агентов. Естественно, агенты для написания кода писались при помощи Claude/ChatGPT (ибо код давно уже почти никто не пишет - все разленились).
Задача не стояла “сделать”, а “пощупать и посмотреть, как далеко можно пройти за пару дней”. Это типичный timeboxing из стартапов.
Вот финальный протокол эксперимента:
Короче с агентами, в упрощенном виде все работает. Делаю так. Есть несколько агентов, которые заточены делать определенную функцию:
(1) поиск селектора для каталога - в итоге очень замудрено и проще его самому достать и передать, поэтому потом откажусь.
(2) генератор кода, который из html кода строки генерирует конвертер в json
(3) генератор кода, который делает next page, то есть переключает pagination
Агенты пишут самостоятельно эти генераторы (for loop) и при этом приводят к определенному интерфейсу.
Далее айдеру у себя в коде говорю, что надо уже написать полный парсер каталога, передаю ему интерфейсы инструментов, которые написали агенты, говорю про селекторы. Он уже потом генерирует код. Эту часть можно так же автоматизировать через агента, но хватит с меня экспериментов 😂
По сути, все это в разы быстрее можно было делать напрямую через aider. Но, если условно стояла бы задача “вот 100 клиентов, делайте”, то можно было запустить генератор по массиву и пойти пить чай.
Айгиз есть в чате канала, можно задавать ему там вопросы в обсуждении этого поста.
Ваш, @llm_under_hood 🤗
PS: Если впервые заходите в чат, пожалуйста, не игнорируйте запрос от бота канала. Он бдит, банит ботов и не понимает шуток.
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)")
Enterprise RAG Challenge - новости
(1) Мы уже получили более 200 заявок на участие во втором раунде! Было бы больше, но вчера в Кёльне была авария у провайдера, и сайт всей группы прилег. А так в день 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 🤗
Пример из теста на работу с кодом в новом reasoning бенчмарке
Как я уже говорил раньше, вторая версия моего бенчмарка не только сильнее нагружает современные модели, но и позволяет раскрыть исходники некоторых тестов.
Вот пример простого теста на понимание кода:
Which specs would fail, if I add a new feature: after authorizing any transaction larger than 3000, the system automatically blocks the card due to “Large Transaction Risk.” We do not add new event type, just extend the existing command handler.
Source code:
{
"short_thought_steps": [
"1. New feature: block card if transaction > 3000",
"2. This affects authorize_transaction command",
"3. Current specs that test large transactions:",
"4. 'authorize_transaction_success' tests 2000 amount - would pass",
"5. But any spec testing transactions > 3000 would fail",
"6. Looking for specs with large transactions..."
],
"failing_spec_names": [
"authorize_transaction_success"
]
}
{
"short_thought_steps": [
"Check specs that authorizeTransaction with amounts > 3000",
"No spec has an authorization > 3000",
"Hence no test scenario triggers the new block logic",
"No spec fails"
],
"failing_spec_names": []
}
Курс “LLM под капотом: выбираем эффективные технические решения для AI-ассистентов”
С когортами поработали, апдейты добавили, приглашения к покупке по листу ожидания разослали, и вот теперь курс можно купить на моей странице https://abdullin.com/ai-assistants-course.
Спасибо всем, кто был с самого начала, тестировал, задавал сложные вопросы и помогал делать курс лучше! Спасибо и тем, кто недавно присоединился из списка ожидания. Пусть этот курс даст вам свежие идеи и рабочие решения.
А тем, кто только планирует, — курс открыт для покупки, он в записи. Можно изучать материалы в своём темпе и применять на практике.
Помимо самого курса у нас есть чат курса, который постепенно превращается в мини-комьюнити. Там можно разбирать вопросы, обсуждать идеи и делиться решениями.
Присоединяйтесь, будет интересно!
Ваш, @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 на бизнес задачах.
Что мы хотели знать про DeepSeek r1, но стеснялись спросить?
(1) Правда ли, что DeepSeek r1 лучше o1?
Вот никаким боком. Болтает, может, и приятно, но на конкретных бизнес-задачах он на уровне между 4o и 4o-mini. Да, это предварительные результаты бенчмарка v2 (см. рисунок 1). Да, там есть возможность поразмышлять вволю. Да, DeepSeek пользуется этой возможностью и размышляет только так.
(2) Правда ли, что DeepSeek r1 настолько дешевле o1? Как у них экономика сходится?
А тут начинаются интересные нюансы, про которые журналисты не всегда упоминают. Идем в Wiki статью про DeepSeek.
DeepSeek - это китайская лаборатория искусственного интеллекта, которая разрабатывает большие языковые модели с открытым исходным кодом. DeepSeek в значительной степени финансируется китайским хедж-фондом High-Flyer, основанным и управляемым Лян Вэньфэном из Ханчжоу, Чжэцзян.
Визуализация 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 комманд.
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
Что бы вы хотели знать о проблемах и задачах крупных компаний в Европе?
На 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 🤗
Как за $1.5 получить 24M входящих и 2.4M исходящих токенов Llama 3.3 70B на FP8?
Про это прямо сейчас в чатике канала рассказывает Seva Leonov с картинками бенчмарков.
Важно! Eсли заходите в чат впервые, не пропустите запрос на верификацию от нашего бота защиты от спама (иначе через 60 секунд забанит)
Ссылка на обсуждение в чате.
Ваш, @llm_under_hood 🤗
Одна история разработки своего 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 🤗
Enterprise RAG Challenge round 2 - открыт прием заявок!
> Это дружеское соревнование по построению RAG-систем, которое открыто для всех. Для участия нужно будет сгенерировать ответы на вопросы по набору годовых отчетов компаний (PDF) и прислать их.
Возможность анонимного участия, открытые исходники генератора вопросов итп - все это осталось точно таким же, как и в первом раунде. Разве что ответы надо будет присылать не мне в личку, а отправлять в API.
Народу ожидается побольше, т.к. запускаются рекламные компании в Европе. Да и вообще освещением процесса занимается несколько компаний. Тех, кто займет высокие места, хантить к себе будут не только из этого канала, как было в первом раунде.
Будет небольшой призовой фонд (500, 350 и 200 евро ваучером на ваш выбор). А еще на мероприятие хочет заглянуть и рассказать про всякое интересное Intel’s Director of AI Go-to-Market and EMEA Lead for the AI Center of Excellence.
👉 Записываться тут 👈
Кому понравился первый раунд, и кто идет на второй?
Ваш, @llm_under_hood 🤗
Sam Altman недавно написал, что ChatGPT pro при цене в 200$ в месяц внезапно оказался убыточен для OpenAI.
Похоже, что те, кто согласен платить за эту подписку - это power users, которые гоняют ChatGPT на всю катушку.
Причем, Sam Altman говорит ниже, что он сам лично выбирал цену и был уверен в прибыльности.
Не так просто заработать на LLM-ках, даже в OpenAI.
Ваш, @llm_under_hood 🤗
Coding for AI - Как я быстро запускаю сервера с AI сервисами
Меня очень радует, когда в небольшой слайс времени и внимания получается упихнуть заметный объем работ за счет эффективного использования современных технологий. Сейчас как раз случился аналогичный пример - не могу не поделититься.
Итак, нужно быстро завести и запустить с нуля сервер с парой AI сервисов на разных языках, разными зависимостями, нормальным HTTPS, настройками network и SystemD? Чтобы все конфигурации были версионированы, применялись автоматически, а в случае проблем AI сервер можно было перезагрузить на любую предыдущую конфигурацию.
Плюс, естественно, надо дать доступ разработчикам к deployment pipelines, чтобы они могли сами выкатывать новые версии. И чтобы новые сервисы, DEV/PROD слоты втыкались в сервер без проблем, а сам AI сервер с потрохами можно было при желании перенести на другое железо или переупаковать в виртуальную машину.
На все это суммарно ушло несколько часов, включая отладку, организационные нюансы, постановку пары небольших процессов, документацию итп.
Как все это делается?
- Разработчики заранее сами разрабатывают сервисы так, как им это удобно. Используют ChatGPT/Claude и их друзей. Один сервис на Python, другой в данном случае - Golang. Не суть столь важно
- Заводим виртуальную машину, где быстрее и проще, переключаем на NixOS.
- Кидаем ChatGPT в проект “DevOps Wizard” краткое описание сервисов, путей, необходимых ресурсов и просим одним файлом описать виртуальную машину.
- копируем выхлоп на 100 строчек, проглядываем глазами и запускаем команду nixos-rebuild switch. Через десяток секунд все будет развернуто, в OS установятся нужные зависимости, добавятся нужные ключи инженеров и переменные окружения, появятся SystemD слоты для запуска самих сервисов, Reverse Proxy получит HTTPS сертификаты и настроит раутинг, а порты - откроются.
В чем фишка? Проект “DevOps Wizard” - это просто типовая инструкция, которая велит LLM-ке подумать и написать аккуратную конфигурацию для NixOS. Там есть пара примеров разворачивания аналогичных систем просто для того, чтобы LLM-ка видела привычные правила форматирования и названия переменных.
Плюс поскольку все проекты уже спокойно укладываются в портфель из известных кейсов и паттернов, то и конфигурация достаточно типизированная (если только не нужно возиться с хитростями CUDA).
А если есть host.nix, то полностью перенастроить сервер на новую конфигурацию - это дело секунд.
Технология на базе NixOS настолько безотказная, простая и работающая (на моих кейсах), что все просто работает. Главный недостаток системы - по-своему упоротый синтаксис и относительная нишевость (админы обычно знают про Ansible, Chef или puppet). Но если бОльшую часть работы по возне с Nix DSL берет на себя LLM, а результаты налицо, то это мало кого волнует.
В итоге - одно удовольствие быстро разворачивать AI сервисы, если вдруг это надо срочно сделать самому.
А у вас есть свои примеры технологий, которые доставляют сплошную радость от использования?
Ваш, @llm_under_hood 🤗
Как работать с информацией при построении своих RAG систем?
Я сейчас собираю материал для дополнительного видео к курсу, чтобы ответить на вопрос "Ну собрали мы онтологию для поиска информации по ответу пользователя, а дальше что?" И нашел фотографию, которая наглядно описывает весь процесс.
Раньше так люди исследования вели и книги писали! И умудрялись умещать кванты знаний в странички блокнотов и библиотечные карточки. Zettelkasten растет оттуда (и немного - Obsidian). И вот эта концепция манипулирования большими объемами информации через небольшие структурированные ссылки, цитаты и заметки как раз идеально ложится на работу с текстовыми LLM.
Разве что мы теперь можем не по десятку карточек в минуту перетасовывать теперь, а по десятку тысяч.
Ну а Domain-Driven Design как раз описывает процессы копирования человеческих процессов подобных данному в цифру. DDD уделяет очень много внимания языку и смысловым концепциям (Ubiquitous Language, Bounded Context, Context Mapping итп) и LLM-ки обучены хорошо работать с человеческим миром через языки.
Использование DDD + LLM для отражения подходящих человеческих процессов в цифре - это весьма мощный и удобный инструмент.
Ваш, @llm_under_hood 🤗
Старожилы канала поймут и этот мем и вот этот комментарий в чате:
Нам схема с русскими подписями в кейсе + 8% к точности дала
Что лучше - ставить вопрос в промпте до текста или после текста?
В прошлом посте про новые бенчмарки я написал:
Кстати, обратим внимание, что я вопрос ставлю до исходников файла. Это мне портит кэш, зато позволяет в среднем облегчить жизнь моделям и повысить качество на несколько процентов.
На что в чате возник резонный вопрос:
я бы сказал, это разворачивает бенчмарк в сторону 4о и других моделей опенаи. Из-за такого становится понятно, почему они так высоко в рейтинге по сравнению с действительно сильными моделями, тем же клодом.
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 на бизнес задачах.
Краткая история использования 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 🤗
Ловите второе 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 модели, чтобы улучшать архитектуры своих проектов с LLM под капотом.
Reasoning модели пока не способны удерживать нюансы на длительных логических цепочках, но вот прокрутить большой объем данных и самостоятельно рассмотреть их с разных сторон - это они могут хорошо.
Этим можно пользоваться, заменяя небольшой R&D отдел - вычитывать новые статьи и примерять идеи из них на свои решения.
(1) в контекст модели загружаем архитектуру текущего решения с LLM под капотом - свои мысли вперемешку с кусками кода. И просим сделать сухую выжимку. Повторять, пока не будут подсвечены нужные нюансы.
(2) потом в контекст грузим интересную статью, например, whitepaper про DeepSeek R1. Просим внимательно прочитать в контексте архитектуры текущего решения и предложить простые способы улучшения архитектуры, которые можно быстро проверить.
В ответ можно получить что-то вроде:
Your existing approach already follows many best practices in structured reasoning: ...
Borrowing from DeepSeek-R1’s lessons—especially the self-check “reflection” and using a simple reward or rating for partial coverage—can help you tighten feedback loops. And adding short extraction or “evidence snippet” steps can make your system’s findings easier to read and trust. Each idea above is relatively small-scale to implement but can unlock smoother or more transparent user experiences, aligned with the paper’s spirit of reinforcing better chain-of-thought.
А у какой локальной модели из топовых на моем бенчмарке есть удобный платный хостинг, который поддерживает нормальный constrained decoding (для CoT+SO)? В идеале сразу с openai-compatible API.
Чтобы можно было быстро удаленно потестировать гипотезу до разворачивания vLLM с guidance на каком-нибудь GPU.
Ваш, @llm_under_hood 🤗
Какой из промптов будет давать более точный ответ?
Промпты почти одинаковые, меняется только порядок.
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)
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)
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 🤗
Одна история разработки своего Reasoning - Эпизод III
- Эпизод I
- Эпизод II
Шаг 20. Поспал и посмотрел на неработающий запрос свежим взглядом. И тут я понял, что больше сходу не вижу в формулировке вопроса того очевидного плана для ответа на него, который я видел только вчера (я же не эксперт, вот и выгрузился контекст во время сна). Значит и система его не увидит.
Я давал системе вопрос от эксперта и просил построить план ответа на вопрос. Это как если бы я позвал человека с улицы и попросил сделать то же самое: “посмотри на вопрос и выпиши различные условия или топики, которые надо изучить отдельно для ответа на этот вопрос”.
Система просто не видит всего этого богатства нюансов, которые бы позволили спланировать более тщательно. Ну упомянуты три синонима через запятую, что такого? Почему я от нее требую запускать параллельные поиски именно по этим сущностям в вопросе, а не по остальным? Там есть и не только синонимы.
Но, тем не менее, нюансы есть! В вопросе эксперт явно называл резолюцию, в разрезе которой надо было анализировать документы. И если смотреть с ее перспективы, то это не три синонима, а три разных события, которые влекут за собой разные последствия. Соответственно, и прописаны они должны быть в договоре отдельно. А, значит, и искать надо их независимо друг от друга.
Шаг 21. Я смог получить работающий блок планирования ответа!
Надо обязательно перед запуском планировщика определять перспективу, с которой мы смотрим на вопрос (она описана в регуляторном документе). Грузим релевантную онтологию в схему, докидываем пару ключевых слов для общего настроя и, вуаля, внезапно планировщик начинает видеть нужные нам нюансы в терминах. Во всяком случае теперь ответ всегда один и тот же, сколько раз не вызывай. С этим можно работать. Это поддается тестированию и аудиту.
Шаг 22. Правда теперь возникают другие грабли. Спланировали анализ мы в одной перспективе, а документы у нас проиндексированы с другой перспективе, и они не стыкуются. Получается, что нельзя вычитать документ LLM-кой один раз, а потом использовать получившуюся карту знаний для ответа на любые вопросы.
Эх, заново индексировать. Ладно хоть LLM не просят доплату за нудность работы.
Но зато это объясняет, почему система глупила при ответах на некоторые вопросы. Вопросы требовали понимания таких нюансов, про которые система не знала на момент индексации, вот она их и пропускала.
Конец.
Не в смысле, что конец истории, которая началась три месяца назад. На этом месте шаги не заканчиваются, как и грабли.
Просто теперь мы дошли до сегодняшнего дня. Большинство грабель уже понятны и знакомы. Не “ничего не работает”, а что-то вроде “ага, не хватает вот в этой онтологии точности при извлечении релевантных сегментов”. Работы там выше крыши и она только начинается.
Смотря на все эти телодвижения ретроспективно понятны две вещи.
(1) Любые агенты "из коробки" никогда не будут работать так хорошо, как обещают. В их мышлении нет того скелета, который обращает внимание на нюансы предметной области. Прошивать нюансы в reasoning pipelines - требует усилий и времени. Но если это сделать хорошо один раз, то потом система будет работать если не идеально, то с претензией на стабильность и возможностью улучшаться. А там, глядишь, и сойдется юнит-экономика на всю автоматизацию.
(2) Неземной респект командам OpenAI, которые смогли сделать reasoning движок, который само-адаптируется под неизвестные заранее вопросы. Причем не просто адаптируется, но и очень часто умудряется находить хорошие ответы на очень сложные вопросы. Это вам не классифицировать запросы пользователя по предвычисленным “в лоб” онтологиям предметной области.
Возможно когда-нибудь, можно будет брать последнюю версию LLM, и она сама сможет правильно индексировать все документы в какой-то отрасли, планировать исследования и без проблем приходить к ответу. Ну и еще сможет качественно учиться на ошибках.
Но я сомневаюсь, что это будет в ближайшие годы - слишком много важных нюансов. А что вы скажете?
Ваш, @llm_under_hood 🤗
Одна история разработки своего Reasoning
Чем больше я пытаюсь повторить 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 🤗
Кейс - поиск ошибок в строительных заказах на покупку
Давно не было разборов кейсов. Давайте расскажу про один из текущих. Он тоже реализуется по концепции 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 🤗
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: Для тех, кто видит бенчмарки впервые, подробнее про них написано тут.