12419
Канал про разработку продуктов на базе LLM/ChatGPT. Выжимка важных новостей и разборы кейсов.
Используйте 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: Для тех, кто видит бенчмарки впервые, подробнее про них написано тут.
Как тестировать систему с 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)
Всех с наступающим новым годом!
Неблагодарный прогноз на 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 🎅
Бенчмарк 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, а потом передавать его на интеграцию команде AI Biz Integration?
Это в чате канала продолжается дискуссия на тему экономики кейсов с LLM под капотом:
При этом это не камень в огород, признание того что ты, Ринат поступаешь очень по-умному, избегая самую неблагодарную часть, которую конечно же тоже умеешь реализовывать.
А теперь будет самый забавный момент.
(это завершение поста про "Как ищете клиентов?")
Можно с самого начала смотреть на весь этот процесс (от маркетинга до передачи проекта на интеграцию) как на одну систему. И если оптимизировать все шаги для максимальной пропускной способности, то получится, что bottleneck в компаниях будет не на первых шагах, а на стадии:
аааа, клиент хочет поскорее подписать бюджет на интеграцию работающего LLM Core, а у нас команды разработчиков все заняты. Где можно поскорее найти опытных PM, full-stack, FE/BE ребят в районе DACH для remote-first работы? Опыт с LLM не нужен совсем!
Давайте поговорим про экономику кейсов с LLM под капотом
Я специализируюсь на кейсах с LLM под капотом, которые встраиваются в продукты или оптимизируют какие-то бизнес-процессы в компаниях США и Европы.
Мне подобные кейсы нравятся тем, что бизнес очень хорошо умеет считать выгоду (а кто не умеет - освобождает место конкурентам на рынке). В такой ситуации у меня быстро отсеиваются подходы и кейсы, которые: (a) невыгодны (б) рискованны или (в) их нельзя быстро и контроллируемо встроить в бизнес.
Все эти пункты в итоге сводятся к одному экономическому - выгоде. Про какую выгоду я говорю?
Посмотрим на кейс с использованием ChatGPT в качестве бизнес-переводчика в нишевой области (кейс). Там выгода от использования вполне себе конкретная - компания экономит на услугах freelance перводчиков на 5-6 языков до 10000 евро в месяц.
Причем там еще есть скрытая экономия - переводчиков, которые разбираются в оптимизации логистики - очень сложно найти и выбрать. Текучка при этом большая. Но директорам компании теперь не нужно тратить личное время на работу с кадрами.
Другой кейс - генерация лидов в международной компании (описание). Внедряемый процесс экономит, как минимум, пару недель ручного труда на каждую новую пачку лидов. За год, с учетом всех телодвижений, это экономит 30k-50k EUR в год на один офис. А офисов у этой международной компании больше пятидесяти. Можно перемножить и оценить потенциальную выгоду.
Понятно, что цифры довольно абстрактные. До автоматизации люди не занимались такой работой совсем (человек не вынесет такого), и просто не могли находить настолько качественных лидов. Поэтому точно нельзя измерить выгоду просто потому, что раньше эта возможность отсутствовала.
А еще забавно, что 90%+ стоимости внедрения в этом проекте не будет связано с LLM совсем. LLM Core (основное ядро с парой промптов и интеграций) - это один небольшой сервис. Ядро уже сделано и работает. Но потребуются усилия команд по интеграции (AI Biz Integration Team), чтобы эти новые возможности аккуратно воткнуть в бизнес-процессы компании. И они стоят того.
Аналогичная история повторяется постоянно. Скажем, в кейсе с захватами рынков, прямая выгода от внедрения data extraction на базе LLM - это пара недель экономии времени раз в пару месяцев. Можно консервативно посчитать как 2000 EUR в месяц. Казалось бы, что немного, но есть еще один нюанс под названием “Opportunity Cost”.
Новая технология не только позволяет быстрее реагировать на новые рыночные возможности и действия конкурентов. Она позволяет перераспределить ресурсы компании с автоматизированного процесса на обработку новых возможностей. А это - рост прибыльности компании без сопутствующих трат на найм и обучение людей. Умножаем это на обычный срок окупаемости инвестиций и корректируем на риск, чтобы получить шестизначную сумму приемлемой стоимости проекта.
И, как это обычно водится с подобными кейсами, LLM ядро в данном кейсе - это компактный и достаточно простой модуль с парой промптов и выверенной системой контроля качества (фактически, тестовый dataset). Трудозатраты - полтора-два человеко-месяца.
LLM ядро там уже сделано и работает достаточно хорошо, а основная оставшаяся работа - это аккуратная интеграция всего этого добра в бизнес-процессы компании. Она, скорее всего, займет не один месяц работы AI Biz Integration команд.
Эти цифры и кейсы вовсе не значат, что все случаи внедрения LLM выгодны. Наоборот, можно легко закопаться в какой-нибудь чат-бот, где экономика далеко не такая выгодная, а вероятность успешного закрытия проекта еще печальнее (см, например, про Ринат не делает чат-ботов).
Но неуспешные проекты не попадают в мою статистику Proven AI Cases, и поэтому не портят картину с работающими паттернами и успешно закрытыми кейсами.
Ваш, @llm_under_hood 🤗
PS: При всем при том мы не говорим к каких-то сверхприбылях для компаний. С учетом всех суммарных затрат и расходов получаются просто инвестиции, которые окупаются несколько быстрее других вариантов.
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 🤗
Визуализация 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 🤗
NVIDIA Project Digits - персональный AI сервер на ладошке.
NVIDIA показала компактную AI платформу стоимостью в 3k USD, которая может запускать модели размером до 200B. А если соединить две машины - до 405B.
На борту - GB10 Grace Blackwell чип. У чипа может быть до 128 GB unified памяти (похоже на маки). На борту крутится DGX OS и запускается весь софт NVIDIA. Машинка может использоваться отдельно или подключаться к компьютеру.
Получается такой DGX сервер на минималках. В продаже — начиная с Мая. Это может быть выгодным вариантом для компаний, которые хотят протестировать локальных AI ассистентов без покупки большого сервера с GPU.
У вас есть проекты, где бы хорошо зашла такая машина?
Ваш, @llm_under_hood 🤗
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 🤗
В заключение бенчмарков на 2024 год, хочу показать то, насколько прокачались LLM в качестве (за те же деньги).
Напомню, что на этом графике модели группируются не по семействам, а по ценам на запуск бенчмарка.
Ну и понятно, что группировка цен топовых reasoning моделей сильно условна - они уже завели свою категорию.
Рост качества был у всех основных поставщиков. Особенно удивили и порадовали в Google, которые сильно активизировались в конце этого года. Остается только пожелать, чтобы в новом году прогресс не останавливался, было больше хороших и доступных всем моделей.
Ваш, @llm_under_hood 🤗
PS: Если кто-то хочет построить свой график - в llm-benchmark-history есть данные в csv формате. Можно самостоятельно привязать их к timeline и построить свой график.
А в чем проблема с полной передачей 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 и сравнивать их с каноничными используя, например, Jacard Index. Считаем среднее и получаем качество работы системы в данной версии.
"Как ищете клиентов?"
Это простой вопрос в комментарии на предыдущий пост про экономику кейсов с 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 под капотом: выбираем эффективные технические решения для AI-ассистентов”.
Мы закончили работать с когортами курса по AI-ассистентам. На основе фидбэка я добавил в курс обновления, начиная с практических заданий и до появления кнопок для ускорения просмотра видео.
Огромное спасибо всем за участие и обратную связь! Я бы с удовольствием сделал еще пару когорт ради такого качественного общения, вдумчивого фидбека, вопросов и вдохновляющих отзывов, но материал курса уже готов к широкому доступу.
Что дальше? Сейчас мы подготавливаем платформу к началу продаж, которые откроются в начале следующего года. Про это я напишу в канале отдельно. Тем, кто оставлял заявки в листе ожидания, продублирую email-ом.
Если у кого-то в команде горят бюджеты текущего года и важно купить курс сейчас: вы можете написать в личку @akitka или @abdullin, мы пришлем ссылку для оплаты и проведем покупку в ручном режиме.
Напоминаю, что оплатить курс можно только зарубежной картой. Закрывающие документы генерируются при покупке.
Ваш, @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: Для тех, кто видит бенчмарки впервые, подробнее про них написано тут.