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

Подготовили сейчас площадку и визуализацию базовыми MMLU/ruMMLU  кстати как вам сравнение Llama3.1 8b vs Qwen 2.5 7b ?


Еще и клод сразу помогает сделать красивую визуализацию =)

Бенчмарки будут про бизнесовые задачи в РФ от HR RAG до text2sql задачек! Пишите что интересно вам!

Как построить собственную AI-поисковую систему: опыт российского рынка 2024

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

От простого к сложному

Представьте классическую задачу ML - кредитный скоринг в банке. Для его работы достаточно сервера с парой GPU NVIDIA L4 общей стоимостью около 2-3 млн рублей. Такой сервер может обрабатывать нескольких 10 тысяч заявок в день.

Теперь посмотрим на современные RAG-поисковики с LLM. Для запуска требуется минимум 4-8 карт A100 или H100, а это уже 20-40 млн рублей только за железо. И это без учета остальной инфраструктуры.

Три пути внедрения поисковых систем на базе ИИ в 2024 году:

1. Облачные решения (OpenAI/Anthropic):
- Простота внедрения
- НО: Отсутствие контроля над данными
- НО: Невозможность отследить, что сотрудники отправляют в поисковые запросы
- НО: Риски утечки конфиденциальной информации через промпты

2. API-интеграция:
- Больше контроля над процессами
- Возможность логирования запросов
- НО: Все еще есть риски утечки через промпты
- НО: Зависимость от внешних провайдеров

3. Собственное RAG-решение:
- Полный контроль над данными и поисковыми запросами
- Возможность тонкой настройки под специфику компании
- НО: Стандартные серверы для обработки даже 5 параллельных запросов стоят выше тендерного лимита
- НО: Сложность начальной настройки

Почему это критично для российского рынка?

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

Наш путь оптимизации RAG-системы

1. Техническая оптимизация:
- Разработали специализированные методы запуска LLM на китайских MTT картах
- Создали ETL-пайплайны для бесшовной интеграции корпоративных баз знаний с векторными БД:
* Автоматическая синхронизация с популярными CRM/ERP системами
* Умная обработка структурированных и неструктурированных данных
* Поддержка инкрементальных обновлений
- Оптимизировали векторный поиск для работы с гибридными данными
- Внедрили эффективную систему кэширования

2. Обучение моделей:
- Провели fine-tuning open-source моделей под специфику поисковых задач
- Оптимизировали параметры для быстрого поиска
- Сфокусировались на моделях до 10B параметров, идеальных для RAG

3. Инфраструктурные решения:
- Внедрили серверные карты MTT на базе MUSA технологий
- Обеспечили стабильные поставки через китайских партнеров
- Достигли производительности уровня NVIDIA L4 по цене в 2-3 раза ниже

Реальные результаты

При классическом подходе:

Общая стоимость = Софт (N) + Сервер (S) + Внедрение (W)
Окупаемость = Экономия (C) / Время внедрения (T)

С нашими оптимизациями:
- Стоимость серверной части снижается в 2-3 раза по сравнению с аналогичными решениями на L4
- ETL-процессы позволяют начать работу с существующими базами знаний за считанные дни вместо месяцев
- Гибридный подход к хранению и поиску обеспечивает точность на уровне 80%+

Подтверждение рынком

На начало 2025 года:
- Портфель из 4 крупных компаний в очереди на поставку программно-аппаратного комплекса
- Успешные пилоты в разных отраслях
- Подтвержденная экономия на внедрении от 60%


Главный инсайт:
- Китайские GPU карты это что-то новое и до конца не изученное,
- Классические базы знаний компаний уже содержат 80% необходимой информации. Наша задача - сделать её доступной через современные векторные поисковые системы. Благодаря оптимизированным ETL-процессам мы превращаем статичные базы знаний в динамические поисковые системы.

Про что рассказать дальше?
- Как работает наш ETL-пайплайн для разных типов данных?
- Методы оптимизации векторного поиска?
- Особенности интеграции с популярными корпоративными системами?
- Практические кейсы внедрения?
- Расчеты экономической эффективности на железе?

Сбер добрался до гигабайта

В целом я был бы не против но только на небольшое время!

Наверное еще рано чтобы подводить громкие итоги.

Но я точно могу сказать чем могу гордиться к 30 годам

У меня родился сын в 2024!!!
У меня прекрасная жена без которой я бы не достигал таких высот ❤️
Супер крутая и отзывчивая семья!

Осуществил мечту собрать команду мечты, они самые крутые ребята!

Поборол страх выступлений, в этом году более 8 публичных выступлений, участий в подкастах и съёмках.

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

Оставайтесь на связи, вы самая крутая аудитория =)

В 2025 я продолжу свой путь!

Всем привет!
Начнем этот год с бенчмарков on-premise VL и Cloud моделей и их производительности в анализе неструктурированных документов и извлечении данных из них через подход Structured output.

У нас сегодня открытые данные (таможенные декларации и неструктурированные документы): паспорта качества, СЭС-сертификаты, сертификаты пожарной безопасности. Все эти документы объединяет то, что они общедоступные и неструктурированные.

Соревнуются четыре модели: Qwen/Qwen2-VL-7B-Instruct и Qwen/Qwen2-VL-72B-Instruct (вторая запущена в динамической квантизации на 8FP.

А так же claude-3.5-sonnet и gpt-4o

Куда смотрим для понимания точности на метрику DocVQAtest

Qwen2-VL-7B: 94.5% (в сравнении с gpt-4o-mini)

Qwen2-VL-72B: 96.5% (в сравнении с моделями ниже)
GPT-4o: 92.8%
Claude-3.5 Sonnet: 95.2%

Итак, на вход у нас задача извлекать 5 типов данных:
1) Производитель
2) Номер документа
3) Даты
4) Организация, которая выдала
5) Описание

Примерный промпт, который мне понравился:

Analyze the document image and extract the following fields with special attention to mixed character sets:
1. MANUFACTURER (ПРОИЗВОДИТЕЛЬ):
   - Extract complete legal name
   - Include organization type (ООО, АО etc.)
   - Preserve original formatting
2. DOCUMENT NUMBER (НОМЕР ДОКУМЕНТА):
   - Extract complete number maintaining original format
   - Pay special attention to:
     * Cyrillic characters (А-Я, а-я)
     * Latin characters (A-Z, a-z)
     * Numbers (0-9)
     * Special characters (-, .)
   - Preserve exact case of letters
3. DATES (ДАТЫ):
   - Issue date (дата регистрации)
   - Expiry date (действительна по)
   - Format: DD.MM.YYYY
   - Validate date format
4. ISSUING ORGANIZATION (ОРГАНИЗАЦИЯ):
   - Extract complete legal name
   - Include location if specified
   - Maintain original spelling
5. DESCRIPTION (ОПИСАНИЕ):
   - Extract document type and purpose
   - Include scope of application
   - Preserve key regulatory references

Structured Output схема (специально максимально скрыл данные в некоторых полях, считаю это уже интеллектуальной собственностью):

{
  "type": "object",
  "properties": {
    "manufacturer": {
      "type": "string",
      "description": "..."
    },
    "document_number": {
      "type": "string",
      "description": "..."
    },
    "issue_date": {
      "type": "string",
      "description": "..."
    },
    "expiry_date": {
      "type": "string",
      "description": "..."
    },
    "issuing_organization": {
      "type": "string",
      "description": "..."
    },
    "description": {
      "type": "string",
      "description": "..."
    }
  },
  "required": [
    "manufacturer",
    "document_number",
    "issue_date",
    "expiry_date",
    "issuing_organization",
    "description"
  ]
}

Так как мы запускаемся на VLLM, то у нас на сегодня есть три бэкенда для Structured Output. Но я использую xgrammar.

Конфиг железа:
1) 7b модель запущена на 4090

gpu_executor.py:80] Maximum concurrency for 20000 tokens per request: 3.82x

2) 72b модель в динамической FP8 влезает в одну H100, так что тут не густо по потокам, но хватает для анализа

gpu_executor.py:80] Maximum concurrency for 6000 tokens per request: 2.38x

А что по времени с on-premise

4 сек у 7b и 10 сек у 72b на одну страничку!

В картинку вынес сравнительную таблицу по стоимости(учитывая аренду сервера на месяц), скорости своим комментариям, и емкости взял за пример, что в сутки надо анализировать 20к документов.

Какие выводы можем сделать?
Если у вас огромные потоки данных для анализа в сутки от 10-20к в день, и вам очень важна секьюрность, то on-premise решения уже догоняют Cloud решения по многим характеристикам. Да начинаем с cloud (так как надо SO то пока что только openai)

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

Ну что разбиваем копилку?

Вышла долгожданная 5090 в два раза мощнее прошлой GeForce RTX 4090, и в два раза компактнее.

Nvidia представила GeForce RTX 5090, а также GeForce RTX 5080, GeForce RTX 5070 Ti и GeForce RTX 5070

GeForce RTX 5090 оказалась сильно дешевле, чем ожидалось $1.999 я рассчитывал на 2.500+

GeForce RTX 5090. 32 ГБ памяти GDDR7.
Частота памяти составила 30 ГГц. Видеокарта построена на GPU GB202-300-A1 c 21 760 ядрами CUDA.
TDP — 575 Вт.
Ускоритель поддерживает PCIe Gen 5.0 и DisplayPort 2.1b UHBR20 (8K 165 ГЦ)