Кто-нибудь успел затестить GigaChat 2 MAX, которую сегодня зарелизил Сбер?

Глядя на бенчмарки, обгоняет GPT4o и Qwen 72B (вот с этими модельками у меня достаточно взаимодействия было, и я знаю, на что они способны)

Выглядит так, что на русском языке это сейчас лучшая модель (но надо потестить конечно же)

Все жду, когда будет релиз Structured Output, вот тогда можно будет создавать нормальные агентские сценарии 😎

@alexs_journal

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

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

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

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

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

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

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

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

Ваш, @llm_under_hood 🤗

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

Продолжаю эксперименты по документам из RAG Challenge
Задела эта тема так как это финансовые документы и наконец есть результаты (правильные ответы)

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


На скрине оценка качества retrieval, сравнение моих двух подходов на базе векторов openai (small/large) моделей + query expansion CoT)

+ Я почти правильно собрал метрики подсчёта оценки так как почти такие же метрики у Ильи (первое место)

В комментариях приложу md файл + html для вашей оценки

P.S Забыл самое важное
small openai для векторов подойдет когда вы хотите с экономить но если вам важны очень хороший ретривал и высокая разница в score то в финансовом секторе пока ничего лучше large от openai нет)

Пересесть с классической IDE на Cursor - как пересесть с лошади на автомобиль. Риск ДТП выше, если ты невнимателен и медленно обучаемый, но это не значит что до того как садиться на машину нужно для тренировки дальше для тренировки кататься на лошади. В конечном итоге бенефиты ускорения работы х10 переплёвывают все минусы

В продолжение вайб кодинга на уровне квестов и курсора

Взялся протестировать один наш сервис для gptdaisy.com начинаем тонуть в запросах на генерацию изображений там связка async image generation сервис состоит из Comfy(кастомное апи написанное нами + flux + rabbit)

И так получил файлы от лида и взял наш новенький сервер с двумя 4090 и раскатил все что надо, скачал модели докер куда фигуда в общем сказка все на моих любимых скриптах

Цель была стабилизировать сервис и проверить на масштабирование как будет вести себя при n воркерах там еще и удаленные есть и сколько у нас будет IPM(image per minute) сейчас кстати почти честные 15 штук

В общем сервис не взлетел апи принимало запросы картинки не отдавлись

В общем я же вайб кодер взял подключил курсор к core + worker он проиндексировал папки ну и выдал пачки кода которые я принял

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

На утро пустил на сервер бекенд лида и получил порцию консервированных оценок кода от ллм в общем и целом результат на лицо(на скрине)

Курсор (клод 3.7) переписал все обратно на синхронные функции и зачем-то решил каждый раз открывать закрывать содениение по ws чтож тут должен быть мем но придумайте сами =)

Результаты Enterprise RAG challenge (https://abdullin.com/erc/)
На сайте клацаем кнопку Show Local Models Only

На сегодня я завершаю свои исследования по локальным RAG подходам по документам и расскажу как мы заняли 4 место с разницей в 8 баллов от 70+b моделек (Локальных) и 1 первое место среди 32b моделей и Full Dense retrieval and cross-encoder reranker подходом (никаких кстати langchain и другого готового рагоделья только вайб кодинг в курсор и requests + vLLM)

Предыдущие посты на эту тему:
1) Анализ разных векторных моделек
2) Сравнение локальных моделей векторизации с 1 местом
3) Первые эксперименты

В итоге навайбкодил около 11к строк кода которые позволили показать такие результаты
Важное отступление что более 7 дней у меня в итоге заняло эксперименты по экстракту данных из PDF (карл)

И так для начала какое решение я принял сразу что-то ошибочно:

1) Никакой подготовки стендов заранее, все материалы команда и я в частности приступили изучать в день старта соревнований (взял из команды 2 человек ребята помогли вчитаться в условия и понять данные) (Вот тут рефлексия что нужно выделять как минимум неделю заранее свою что бы войти в курс дела)

2) Заранее пополнили все нужные нам сервисы для аренды локальных мощностей

3) Выкинул наш пайплайн RAG и я его стал строить с 0

4) Были заранее развернуты и заготовлены cross encoder bge-rerank + bge-m3 embedding model Арендована машина с А100 для (qwen 2.5 32b (16FP) instruct)


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

Перебрав около 3-5 библиотек финальный результат был сделан на библиотеке Marker

Далее чанкование и векторизация
Ничего нового каждая страница была разбита на чанки по 400 токенов с перекрытием в 80 токенов и дальше векторизирована батчами в сервис vLLM где развернута модель bge-m3

Далее под каждый док была созданная коллекция и настроены модели данных (что бы при запросе на KNN возвращать чанки номер страницы с которой он был взят и путь до файла где есть фулл контент страницы как потом я выяснил данный подход называется Parent Document Extraction)

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

Ну и пошли прогоны (прогонял я систему наверное раз 40 не менее)
Каждый раз вчитываясь что же она отвечает

Ищем чанки внутри дока через KNN
Ранжируем через bge-reranker (cross-encoder)
Передаем в ллм с CoT+SO для ответа

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

Как итог часть этих наработок уже ушла в наш прод продукт Smart Platform которая нацелена решать проблему создания RAG агентов для крупных компаний на локальных мощностях

Stay Tuned!
Скоро будет большой анонс нашей платформы будем с нашим CPO рассказывать что же мы там ваяли за год

P.S мы уже провели внутренние демо нашего продукта получили очень позитивный фидбек! Значит движемся куда нужно!

Кстати схема работы моего решения) Если смотреть между строк почти ничем не отличается от других топ решений

1/2 Когда выгодно переходить с облачных API на собственные LLM-модели: сравнение OpenAI API, облачных и локальных open-source решений


Пришел тут ко мне интересный вопрос, допустим у нас планируется 100 000 только текстовых диалогов в сутки размером не более 3 сообщений от пользователя
Текущий стек gpt-4o-mini CoT + SO

И так, допустим, у нас есть 100 000 диалогов примерно по 100-300 токенов от пользователя и еще по 3 сообщения от ллм в сумме на инпут у нас 900 аутпут примем что чуть больше 1200

получаем вот такую картину пока исключил кеширование:
gpt-4o-mini

Входящие токены (900 × 100K): $11.48 (некеш) + $1.01 (кеш) = $12.49/день
Исходящие токены (1,200 × 100K): $72/день
Всего: ~$84.49/день или ~$2,535/месяц


Расчет RPS (запросов в секунду) возьмем очень идеальное условия:

100,000 диалогов в день = 100,000 ÷ 86,400 секунд ≈ 1.16 RPS
В пиковые часы (если 70% трафика приходится на 6 часов): ~5.63 RPS

Теперь представим, что мы хотим не повторить, но хотя бы быть на уровне результатов gpt-4o-mini
В моем честном бенчмарке это что-то около модели qwen2.5-32b-instruct
А теперь цифры, что вышли у меня
Одна А100 стоит на runpod $1.89 и такая штука будет иметь пропускную способность 2-3 запроса в секунду со стримингом

Необходимое количество серверов: 6 (для обеспечения пиковой нагрузки с запасом)

Расчет стоимости на RunPod:

Стоимость одной A100: $1.89/час
Стоимость 6 серверов A100: 6 × $1.89 = $11.34/час
Месячная стоимость (24/7): $11.34 × 24 × 30 = $8,164.80/месяц

Итого при текущих параметрах

gpt-4o-mini: ~$2,535/месяц
Локальное решение (qwen2.5-32b-instruct на 6 A100): ~$8,165/месяц

Локальное решение может становится выгодным?
Да когда мы четко выявляем для себя вот такие пункты:

1.Когда важна защита данных - нет отправки конфиденциальной информации в облако
2. Когда необходимо соответствие регуляторным требованиям - GDPR, 152-Ф3, запрет на трансграничную передачу (и то Amazon вроде GDPR соответствует если мы говорим про не РФ)
3. Стабильная работа без лимитов - нет ограничений API, кредитной системы или очередей
4. Независимость от вендора - нет риска, что АРІ поднимет цены или изменит условия

Когда еще выгодно? Update расчет для покупки железа https://www.tgoop.com/neuraldeepchat/4288

Когда у нас не растет RPS но растет кол-во обрабатываемых токенов за одну сессию допустим мы начинаем сторить не 3 сообщения от пользователя а 10-20 и тогда нам начинает быть более интересно переходить на покупку/аренду железа

Забирайте как шпаргалку когда вам в голову приходит идея аренды железа под ллм

в комментариях еще кинул (написаный курсором калькулятор) есть вопросы к качеству но представление он показывает

2/2 Когда выгодно переходить с облачных API на собственные LLM-модели: сравнение OpenAI API, облачных и локальных open-source решений

Решил для себя закрепить пройденный материал

Давайте за термины проговорим:
API облачных LLM сервисы, предоставляющие доступ к языковым моделям через API (OpenAI, Anthropic, Google и др.) где оплата происходит за каждый обработанный токен

Open-source модели открытые модели (Qwen, Llama, Mistral и др.), которые можно скачать c huggingface и использовать на собственной инфраструктуре

On-premise размещение моделей на собственном локальном оборудовании компании

Cloud аренда вычислительных ресурсов в облаке (RunPod, AWS, GCP(google platform)) для запуска моделей (возможны разные вариации защиты данных от confidential compute до Федеративного шифрования с DP)

Confidential Computing для компаний с критическими требованиями к безопасности, где затраты вторичны по отношению к защите данных

Сценарий_simple_text_chat_system: 100к текстовых диалогов в сутки
Исходные данные
100 000 диалогов ежедневно
3 сообщения от пользователя в каждом диалоге
900 токенов на вход, 1200 токенов на выход
Средняя нагрузка: 1.16 RPS
Пиковая нагрузка: 5.63 RPS (70% трафика в течение 6 часов)

Стоимость Cloud API (GPT-4o-mini)

----------------------------------
Парам | Расчет         | Сумма   |
------|----------------|----------
Вход  | 900×100K×$0.15 | $12.5/д |
Выход | 1.2M×100K×$0.6 | $72/д   |
------|----------------|----------
Итого |                | $2535/м |
----------------------------------
Итого |                | $2535/м |

Аренда RunPod

--------------------------------
Парам | Расчет       | Сумма   |
------|--------------|----------
A100  | $1.9×6×24×30 | $8165/м |
--------------------------------

Стоимость своего оборудования

------------------
Парам  | Сумма   |
-------|----------
Железо | $106K   |
Колок  | $240/м  |
Энерг  | $400/м  |
Аморт  | $2945/м |
DevOps | $3000/м |
-------|----------
Итого  | $6585/м |
------------------

Сравнение решений

|Решение | $/мес.| Преимущ.|Недос.|
|--------|-------|---------|------|
|CloudAPI| $2,5к | Low ent |APIdpn|
|RunPod  | $8,1к | flexi   |High $|
|Lcl     | $6,5к | fullctrl|High $|

Когда переходить на собственные модели?

1. Экономические факторы
- Высокий объем запросов- локальное решение становится выгоднее GPT-4o-mini при более 140,000 диалогов/день
- Длинные контексты- при обработке больших объемов данных (>100K токенов) на запрос
- Долгосрочные проекты - окупаемость собственного оборудования относительно RunPod: ~24 месяцев

2. Неэкономические факторы
- Конфиденциальность данных - отсутствие передачи информации внешним сервисам
- Соответствие регуляторным требованиям - GDPR, 152-ФЗ, ограничения трансграничной передачи
- Стабильность работы - отсутствие очередей, ограничений скорости, кредитных лимитов, прекращение поддерживание старых версий моделей

Альтернативные сценарии_agentic_system(реальный кейс)
Пример: SAST агент патчер на базе qwen32b-coder

Экономическое обоснование:
- 50 репозиториев с ежедневными сканированиями (это минимум что апдейтит средний tir1-2 корп в сутки)
- 20 уязвимостей/день требуют исправления (анализа и быстрой реакции на них)
- 160K токенов на вход, 25K на выход 1000 запусков в день

Просто сравним сколько бы в месяц даже на старте мы тратили бы на gpt-4o-mini
И так как это MAS мы насчитали около 40+ промптов для каждого агента (представьте после PoC переезжать на qwen и все переписывать
Но для чистоты сравню стоимость

|   Решение   | Стоимость/месяц |
|-------------|-----------------|
| GPT-4o-mini |      $990       |
| Local(A100) |      $868       |

Для стартапов и проектов с небольшим объемом запросов(и низкими требованиям к безопасности после PoC) оптимальным выбором остаются облачные API из-за низкого порога входа и отсутствия капитальных затрат

Гибридный подход может быть оптимальным: использование облачных API(на старте) для обычных задач и локальных моделей для конфиденциальных данных или при высоких объемах запросов.

⚡️ OpenAI сегодня ВЕЧЕРОМ представит GPT-5 — новая модель уже прошла внутреннее тестирование и готова к релизу.

Главные изменения:

• Мультимодальность — GPT-5 сможет обрабатывать видео, аудио и изображения в реальном времени.
• Автономные действия — ИИ сможет выполнять задачи в интернете без запросов пользователя (платежи, бронирования и т. д.).
• Ограничения — некоторые функции будут доступны только по подписке Pro Max.

Что еще известно:
• Первыми доступ получат корпоративные клиенты и разработчики.
• Бесплатная версия останется, но с урезанными возможностями.

⚡️ Подробности — сегодня в 20:00 по МСК.