Forwarded from Роман с данными
LLM моделей становится все больше и больше, разобраться в таком зоопарке становится все сложнее и сложнее.
Openrouter придумал интересный способ навести порядок - они проклассифицировали запросы своих клиентов по типам задач (programming, legal, finance и т.д) - и посмотрели в каких случаях какие модели используются.
Как говорится - все гениальное просто 🙃
Ознакомиться с инфографикой можно по ссылке https://openrouter.ai/rankings
P.S: За новость спасибо Валерию Ковальскому, автору канала Neural Deep
Openrouter придумал интересный способ навести порядок - они проклассифицировали запросы своих клиентов по типам задач (programming, legal, finance и т.д) - и посмотрели в каких случаях какие модели используются.
Как говорится - все гениальное просто 🙃
Ознакомиться с инфографикой можно по ссылке https://openrouter.ai/rankings
P.S: За новость спасибо Валерию Ковальскому, автору канала Neural Deep
🔥23❤7 3
1С Можно ли автоматизировать через VL модели семейства Qwen распознавание сканов товарных накладных?
Взял в проверку картинку и гипотезу с канала 1С PRO: Интеграция + ИИ
В тест взял 7b и 32b и 72b модельку
Так же завез детекцию bbox
По моим наблюдениям и запускам
7b уходила в бесконечный цикл генерации как бы я не старался исправить промпт на таблице её корежило
32b находила все что нужно но почему-то съезжают bbox
72b такая же болезнь что и у 32b
Гипотеза моя была в том что можно распознавать и дететктить bbox на новых типах накладных и допом OCRить поля для повышения уверенности
Но чуда не случилось буду тестировать еще другие файлики текст отличный (расположение bbox кривое)
Возможно скан низкого разрешения для bbox поищу сканы лучшего качества
Крутой подход от Ильи в коментах
Взял в проверку картинку и гипотезу с канала 1С PRO: Интеграция + ИИ
В тест взял 7b и 32b и 72b модельку
Так же завез детекцию bbox
По моим наблюдениям и запускам
7b уходила в бесконечный цикл генерации как бы я не старался исправить промпт на таблице её корежило
32b находила все что нужно но почему-то съезжают bbox
72b такая же болезнь что и у 32b
Гипотеза моя была в том что можно распознавать и дететктить bbox на новых типах накладных и допом OCRить поля для повышения уверенности
Но чуда не случилось буду тестировать еще другие файлики текст отличный (расположение bbox кривое)
АНАЛИЗ ДОКУМЕНТА
==================================================
Информация о документе:
--------------------
Тип: ТОВАРНАЯ НАКЛАДНАЯ
Номер: 923
Дата: 02.06.2017
Информация о получателе:
--------------------
Имя: Коршунова Мария
Адрес: 109044, Россия, Москва, 8-я улица Сокольной горы, д.22, кв./оф.203
Телефон: +79629978695
Продукты:
--------------------
# Название Артикул
-----------------------------------------------------------
1 Трансмиссионное масло HONDA ATF-DW1 для АКПП 0.9л, USA 082009008
2 Моторное масло HONDA Motor Oil ULTRA LTD SN 5W30 4L Япония (полусинтетика) 082189974
3 Фильтр масляный 15400RTA003
4 Фильтр воздушный 17220RNAY00
5 Фильтр салонный 80292TV1E01
6 Шайба уплотнительная (18 ММ) 90471PX4000
7 Шайба уплотнительная сливного отверстия масла двигателя/МКПП (14мм) 9410914000
Возможно скан низкого разрешения для bbox поищу сканы лучшего качества
Крутой подход от Ильи в коментах
👍11🤔5🔥3
Сегодня владельцы телеграм ботов, более 300к MAU, стали получать уведомления о просьбе отключить все сторонние платёжные системы, кроме Telegram Stars, иначе блокировка
По информации такие уведомления получили топ 10 ботов с доступом к различным сервисам, таким как LLM, по подписке
Запасайтесь звёздам для продления подписок
По информации такие уведомления получили топ 10 ботов с доступом к различным сервисам, таким как LLM, по подписке
Запасайтесь звёздам для продления подписок
❤10🤯4
Свой AI Call Center! Как построить? Опыт разработки длиною в год
Многие спрашивали в комментах про AI call center и я решил собрать материал! Позвал Артёма, технического архитектора (TA) стартапа, разрабатывающего подобную платформу
Вот главные инсайты за год реальной работы
Сразу к делу 👇
Что такое AI call center?
- Система для автоматизированных разговоров с клиентами
- Локальное onpremise решение (безопасность!)
- Интеграция STT, LLM и TTS компонентов
- Нетривиальный пайплайн обработки в реальном времени
- Поддержка 20+ языков (крутое преимущество для международного бизнеса)
Архитектура
- STT распознаёт речь (важно работать с односложными ответами!)
- LLM генерирует ответы (нужен правильный контекст)
- TTS озвучивает текст в голос
- GuardRails для безопасности на базе отдельной LLM
- Балансировщик нагрузки для масштабирования
Типичные проблемы
Безопасность
- Всё onpremise в базе (хотя пробовали разные варианты)
- Отдельный GuardRails, сходный с NVIDIA
- GR работает как "рубильник" и разрывает соединение при отклонениях
- Работает параллельно основной обработке, не замедляя пайплайн
❌ OpenAI-realtime плохо работает не на английском - путает языки входа/выхода
Масштабируемость
- Изначально система проектировалась на ~100 одновременных сессий
- Основной bottleneck — это LLM
- H100 тянет ~10 сессий для моделей типа Llama 70B+
- На первом этапе хватит 10-30 одновременных сессий для тестирования гипотез
❌ Не завязывайтесь на внешние нейронки в production! OpenAI не всегда стабильна, тайминги ответов непредсказуемы
⚠️ Критично: первый чанк озвученного текста должен быть готов за 1-1.5 секунды!
Затраты на разработку
- 1-2 NLP специалиста, бэкенд разработчик, 25% времени DevOps
- Прототип на внешних сервисах: ~1 месяц (качество диалога далеко от человеческого)
- Решение под конкретный язык на opensource +2 месяца
- Эксперименты с собственными нейронками, сбор датасетов и телефония: +6 месяцев
Проблемы с STT
⚠️ Модели ASR/STT заточены под более качественный звук, чем ulaw8000 в телефонии!
- Необходима логика нарезки входного звукового потока
- Модели плохо справляются с распознаванием речи в условиях мобильной связи
- Фоновые шумы и акценты – дополнительная сложность
LLM/TTS решается проще: 11labs даёт хорошее качество генерации голоса, обычной версии достаточно
Проблемы с LLM в диалоге
- Плохо заточены под формат живого диалога
- При подаче сырого транскрипта отвечают в стиле вежливого помощника
- Часто путаются в промпте и сценарии
- Достигнуть sub 1.5 sec на ответ при тюнинге вполне реально
Для низкоресурсных языков задача усложняется в разы — LLM с неточным контекстом и малой выборкой накапливает ошибку x2.
Особенно это заметно при переходе от частых фраз к нетипичным высказываниям, где модели начинают "плыть" и терять основную нить разговора
Организация логики разговора
- Юзер закончил говорить или сделал паузу?
- Юзер ждёт ответа или будет следующая фраза?
- Как обрабатывать дополнения к фразе?
- Как реагировать на перебивания?
- Как вернуть разговор в сценарий при отклонении?
- Если юзер молчит — это пауза или провайдер не передал звук?
Считаю для начала проекта надо сразу заложить эти челленджи и иметь 2-3 решения в рукаве. В нашем случае помогли промежуточные прототипы и вспомогательные LLM
Отдельно отмечу важность правильной инфраструктуры - подготовка к скачкам нагрузки, отказоустойчивость и мониторинг качества диалогов критичны!
На практике основные проблемы возникают не в алгоритмах, а в инфраструктурных решениях.
Один сценарий, где LLM начинает генерировать бесконечныя текст, может положить всю систему, если не предусмотреть лимиты и контроли
P.S. Подробнее про компоненты можем рассказать Чат канала тут
Кто строил подобные системы? Делитесь опытом!💪
Многие спрашивали в комментах про AI call center и я решил собрать материал! Позвал Артёма, технического архитектора (TA) стартапа, разрабатывающего подобную платформу
Вот главные инсайты за год реальной работы
Сразу к делу 👇
Что такое AI call center?
- Система для автоматизированных разговоров с клиентами
- Локальное onpremise решение (безопасность!)
- Интеграция STT, LLM и TTS компонентов
- Нетривиальный пайплайн обработки в реальном времени
- Поддержка 20+ языков (крутое преимущество для международного бизнеса)
Архитектура
- STT распознаёт речь (важно работать с односложными ответами!)
- LLM генерирует ответы (нужен правильный контекст)
- TTS озвучивает текст в голос
- GuardRails для безопасности на базе отдельной LLM
- Балансировщик нагрузки для масштабирования
Типичные проблемы
Безопасность
- Всё onpremise в базе (хотя пробовали разные варианты)
- Отдельный GuardRails, сходный с NVIDIA
- GR работает как "рубильник" и разрывает соединение при отклонениях
- Работает параллельно основной обработке, не замедляя пайплайн
❌ OpenAI-realtime плохо работает не на английском - путает языки входа/выхода
Масштабируемость
- Изначально система проектировалась на ~100 одновременных сессий
- Основной bottleneck — это LLM
- H100 тянет ~10 сессий для моделей типа Llama 70B+
- На первом этапе хватит 10-30 одновременных сессий для тестирования гипотез
❌ Не завязывайтесь на внешние нейронки в production! OpenAI не всегда стабильна, тайминги ответов непредсказуемы
⚠️ Критично: первый чанк озвученного текста должен быть готов за 1-1.5 секунды!
Затраты на разработку
- 1-2 NLP специалиста, бэкенд разработчик, 25% времени DevOps
- Прототип на внешних сервисах: ~1 месяц (качество диалога далеко от человеческого)
- Решение под конкретный язык на opensource +2 месяца
- Эксперименты с собственными нейронками, сбор датасетов и телефония: +6 месяцев
Проблемы с STT
⚠️ Модели ASR/STT заточены под более качественный звук, чем ulaw8000 в телефонии!
- Необходима логика нарезки входного звукового потока
- Модели плохо справляются с распознаванием речи в условиях мобильной связи
- Фоновые шумы и акценты – дополнительная сложность
LLM/TTS решается проще: 11labs даёт хорошее качество генерации голоса, обычной версии достаточно
Проблемы с LLM в диалоге
- Плохо заточены под формат живого диалога
- При подаче сырого транскрипта отвечают в стиле вежливого помощника
- Часто путаются в промпте и сценарии
- Достигнуть sub 1.5 sec на ответ при тюнинге вполне реально
Для низкоресурсных языков задача усложняется в разы — LLM с неточным контекстом и малой выборкой накапливает ошибку x2.
Особенно это заметно при переходе от частых фраз к нетипичным высказываниям, где модели начинают "плыть" и терять основную нить разговора
Организация логики разговора
- Юзер закончил говорить или сделал паузу?
- Юзер ждёт ответа или будет следующая фраза?
- Как обрабатывать дополнения к фразе?
- Как реагировать на перебивания?
- Как вернуть разговор в сценарий при отклонении?
- Если юзер молчит — это пауза или провайдер не передал звук?
Считаю для начала проекта надо сразу заложить эти челленджи и иметь 2-3 решения в рукаве. В нашем случае помогли промежуточные прототипы и вспомогательные LLM
Отдельно отмечу важность правильной инфраструктуры - подготовка к скачкам нагрузки, отказоустойчивость и мониторинг качества диалогов критичны!
На практике основные проблемы возникают не в алгоритмах, а в инфраструктурных решениях.
Один сценарий, где LLM начинает генерировать бесконечныя текст, может положить всю систему, если не предусмотреть лимиты и контроли
P.S. Подробнее про компоненты можем рассказать Чат канала тут
Кто строил подобные системы? Делитесь опытом!
Please open Telegram to view this post
VIEW IN TELEGRAM
2🔥21👍10🤯7❤1
Forwarded from Korenev AI - GPT в тапочках🩴
This media is not supported in your browser
VIEW IN TELEGRAM
В Курсоре появилась генерация правил проекта
Запускается так: /Generate Cursor Rules
В моем проекте курсор создал список всех файлов и краткое описание функциональности каждого файла. Думаю, это лучше поможет курсору ориентироваться в структуре проекта и сохранять чаще информацию там где надо, а не там, где почему-то неожиданно захотелось
Так же для каждого из правил можно указать его способ его использования, если я правильно понял
Запускается так: /Generate Cursor Rules
В моем проекте курсор создал список всех файлов и краткое описание функциональности каждого файла. Думаю, это лучше поможет курсору ориентироваться в структуре проекта и сохранять чаще информацию там где надо, а не там, где почему-то неожиданно захотелось
Так же для каждого из правил можно указать его способ его использования, если я правильно понял
🔥15👍7🤯2
AI Call Center: отвечаем на вопросы! Часть 2 🎙
В прошлый раз мы рассказали об опыте разработки AI Call Center, и в комментариях появились классные вопросы!
Собрал ответы от Артёма на самые интересные из них👇
A: Существует три важных ограничения:
1️⃣ Техническое: цена/пропускная способность провайдера IP телефонии.
2️⃣ Юридическое: в некоторых юрисдикциях боты не могут звонить сами и навязывать/рекламировать услуги. Но могут отвечать на звонки!
3️⃣ Человеческое: Далеко не всегда люди готовы к продуктивному диалогу с ботами. Эти моменты должны быть заложены в логике и сценарии
A: Мы раскурили свою инфраструктуру телефонии и работаем напрямую с провайдером через Asterisk. Пришлось буквально переписать всё на уровне низкоуровневых протоколов и ивентов, т.к. на Python нет адекватных библиотек для этого.
Интересно, что для осуществления одного звонка задействовано множество промежуточных акторов:
- Провайдеры разного уровня
- Системы анализа/записи на уровне государства
- Анализаторы/спам-фильтры
- Автоответчики
- И только потом сам пользователь
Отдельная головная боль - достаточное количество локальных номеров. Есть более "белые" номера (дорогие), есть "одноразовые", которые быстро отлетают в бан и их надо вовремя ротировать
A: Набор из STT, TTS, VAD и Denoise нейронок прекрасно умещается на 20-30 ГБ любого GPU. Для разработки мы взяли RTX6000, чтобы не париться. Смелые могут часть даже на CPU запустить, но это навредит таймингам ответа.
CPU/RAM особых требований нет - зависит от бэкенда, БД и нагрузки. Сборка с 24 CPU и 80-120 ГБ RAM способна потянуть 30 одновременных сессий на несколько тысяч абонентов.
Первое узкое место - LLM. Llama3.3-70B тянет ~13 потоков на пределе на H100. Для высокоресурсных языков можно брать радикально меньшие модели.
A: У нас сотни тысяч неинтерактивных обзвонов (проговаривание предзаписи) + голосовые OTP звонки. Для интерактивных сценариев объемы меньше (тысячи) - сбор обратной связи, уточнение причин проблем в работе с системой
Основные запросы бизнеса:
- Ответы по цели взаимодействия (опрос/обратная связь)
- Качество итогового транскрипта для последующей разметки/классификации
A: Сильно зависит от языка и сложности сценария. По субъективной оценке и разбору транскриптов, разница может составлять от 3-5% для английского до 30% на хинди.
Неинтерактивные обзвоны производятся в любом случае ботами. Для интерактивных сценариев работа колл-центра возможна, но гораздо более затратна по внедрению новых сценариев и меньше масштабируется, особенно когда мы звоним на разных языках.
P.S. Больше вопросов? Пишите в комментах, соберём еще один выпуск!
А все технические вопросы можно задать в чате https://t.iss.one/neuraldeepchat
В прошлый раз мы рассказали об опыте разработки AI Call Center, и в комментариях появились классные вопросы!
Собрал ответы от Артёма на самые интересные из них👇
Q: Какие еще ограничения есть?
A: Существует три важных ограничения:
1️⃣ Техническое: цена/пропускная способность провайдера IP телефонии.
2️⃣ Юридическое: в некоторых юрисдикциях боты не могут звонить сами и навязывать/рекламировать услуги. Но могут отвечать на звонки!
3️⃣ Человеческое: Далеко не всегда люди готовы к продуктивному диалогу с ботами. Эти моменты должны быть заложены в логике и сценарии
Q: Как вы решаете проблемы с телефонией?
A: Мы раскурили свою инфраструктуру телефонии и работаем напрямую с провайдером через Asterisk. Пришлось буквально переписать всё на уровне низкоуровневых протоколов и ивентов, т.к. на Python нет адекватных библиотек для этого.
Интересно, что для осуществления одного звонка задействовано множество промежуточных акторов:
- Провайдеры разного уровня
- Системы анализа/записи на уровне государства
- Анализаторы/спам-фильтры
- Автоответчики
- И только потом сам пользователь
Отдельная головная боль - достаточное количество локальных номеров. Есть более "белые" номера (дорогие), есть "одноразовые", которые быстро отлетают в бан и их надо вовремя ротировать
Q: Сколько и какого железа нужно для обслуживания разного количества потоков?
A: Набор из STT, TTS, VAD и Denoise нейронок прекрасно умещается на 20-30 ГБ любого GPU. Для разработки мы взяли RTX6000, чтобы не париться. Смелые могут часть даже на CPU запустить, но это навредит таймингам ответа.
CPU/RAM особых требований нет - зависит от бэкенда, БД и нагрузки. Сборка с 24 CPU и 80-120 ГБ RAM способна потянуть 30 одновременных сессий на несколько тысяч абонентов.
Первое узкое место - LLM. Llama3.3-70B тянет ~13 потоков на пределе на H100. Для высокоресурсных языков можно брать радикально меньшие модели.
Q: Какие у вас объемы звонков и сценарии использования?
A: У нас сотни тысяч неинтерактивных обзвонов (проговаривание предзаписи) + голосовые OTP звонки. Для интерактивных сценариев объемы меньше (тысячи) - сбор обратной связи, уточнение причин проблем в работе с системой
Основные запросы бизнеса:
- Ответы по цели взаимодействия (опрос/обратная связь)
- Качество итогового транскрипта для последующей разметки/классификации
Q: Насколько качество отличается от человека-оператора?
A: Сильно зависит от языка и сложности сценария. По субъективной оценке и разбору транскриптов, разница может составлять от 3-5% для английского до 30% на хинди.
Неинтерактивные обзвоны производятся в любом случае ботами. Для интерактивных сценариев работа колл-центра возможна, но гораздо более затратна по внедрению новых сценариев и меньше масштабируется, особенно когда мы звоним на разных языках.
P.S. Больше вопросов? Пишите в комментах, соберём еще один выпуск!
А все технические вопросы можно задать в чате https://t.iss.one/neuraldeepchat
👍11🔥6❤1
1M контекст - фейк? Тесты NoLiMa показали что RAG на длинных контекстах почти мертв? 💀
Спойлер нет
Наткнулся на интересное исследование Adobe Research про новый бенчмарк NoLiMa (Long-Context Evaluation Beyond Literal Matching)
В отличие от классического подхода "иголка в стоге сена", здесь тестируется способность модели работать с контекстом когда нет прямых лексических совпадений
Что такое NoLiMa и чем отличается?
Классические тесты (needle-in-haystack) позволяют моделям искать прямые совпадения слов
NoLiMa заставляет модель делать семантические связи без прямых текстовых совпадений
Требует от модели более глубокого понимания контекста и ассоциативного мышления
- Протестировано 12+ моделей с поддержкой контекста от 128K до 10M токенов
- Даже топовые модели значительно деградируют на длинных контекстах
- GPT-4o падает с 99.3% на коротких контекстах до 69.7% на 32K
У большинства моделей провал производительности ниже 50% от базового результата
Почему это важно для наших RAG систем?
В реальном мире информация редко лежит в тексте буквально
Чаще нам нужна модель, способная делать выводы из контекста, находить скрытые связи и работать с разными формулировками одной и той же мысли
Эффективный контекст большинства моделей составляет ~4K токенов, что существенно ниже заявленных значений
Реальные кейсы обычно требуют работы с гораздо большими объемами текста
Что особенно интересно
Отдельно авторы тестировали модели с CoT/reasoning, и результаты обнадеживают:
- GPT-o1 (рассуждающая версия) показывает 31.1% на 32K против базового 18.9% у GPT-o3 Mini
- Llama 3.3 70B с CoT улучшила результат с 8.9% до 10.1% на сложном варианте теста
Stay tuned!
Буду следить за развитием темы, похоже что NoLiMa может стать новым стандартом для оценки RAG и других систем работы с длинным контекстом 💪
Наткнулся на интересное исследование Adobe Research про новый бенчмарк NoLiMa (Long-Context Evaluation Beyond Literal Matching)
В отличие от классического подхода "иголка в стоге сена", здесь тестируется способность модели работать с контекстом когда нет прямых лексических совпадений
Что такое NoLiMa и чем отличается?
Классические тесты (needle-in-haystack) позволяют моделям искать прямые совпадения слов
NoLiMa заставляет модель делать семантические связи без прямых текстовых совпадений
Требует от модели более глубокого понимания контекста и ассоциативного мышления
- Протестировано 12+ моделей с поддержкой контекста от 128K до 10M токенов
- Даже топовые модели значительно деградируют на длинных контекстах
- GPT-4o падает с 99.3% на коротких контекстах до 69.7% на 32K
У большинства моделей провал производительности ниже 50% от базового результата
| Модель | Заяв.| Эфф| Score | 4K |
|-------------|-----------|-------|-------|
| GPT-4o | 128K | 8K | 99.3% | 95.7% |
| Llama 3.3 ..| 128K | 2K | 97.3% | 81.5% |
| Llama 4 Ma..| 1M | 2K | 90.1% | 68.8% |
| Gemini 1.5 .| 2M | 2K | 92.6% | 75.4% |
| Claude 3.5..| 200K | 4K | 87.6% | 77.6% |
Почему это важно для наших RAG систем?
В реальном мире информация редко лежит в тексте буквально
Чаще нам нужна модель, способная делать выводы из контекста, находить скрытые связи и работать с разными формулировками одной и той же мысли
Эффективный контекст большинства моделей составляет ~4K токенов, что существенно ниже заявленных значений
Реальные кейсы обычно требуют работы с гораздо большими объемами текста
Что особенно интересно
Отдельно авторы тестировали модели с CoT/reasoning, и результаты обнадеживают:
- GPT-o1 (рассуждающая версия) показывает 31.1% на 32K против базового 18.9% у GPT-o3 Mini
- Llama 3.3 70B с CoT улучшила результат с 8.9% до 10.1% на сложном варианте теста
Stay tuned!
Буду следить за развитием темы, похоже что NoLiMa может стать новым стандартом для оценки RAG и других систем работы с длинным контекстом 💪
🔥40👍9❤4
gpt-image-1 по API Openai
Но не всем!
Сначала пройди верификацию и как пишут в чатах даже на РФ права работает
Гоу тестить бота и ломать, его написал курсор за 2 часа
всем 1 фри генерация в сутки в low режиме
Я так же сначала получил доступ и верифицировал свою организацию (заняло это не более 5 минут) полет стабильный!
Сгенерировано по запросу: "Cобака бежит по дороге она смотрит на меня глазами красными и в костюме лебовского
На заднем плане стоят люди у обрыва и рассыпают прах как из фильма"
Антропоморфный накачанный кот породы экзот идёт по улице и на него влюбленным взглядом смотрят антропоморфные кошки в разных платьях
Это ок что она кадры из фильма подсовывает?
Гоу тестить пока не вырубил бота всем фри 1 генерацию
1024х1024 high (скорость около 30-50 секунд
За 15 картинок вышло 3,7 бакса или 20 рублей за картинку)
@gptimage1bot
Но не всем!
Сначала пройди верификацию и как пишут в чатах даже на РФ права работает
Гоу тестить бота и ломать, его написал курсор за 2 часа
всем 1 фри генерация в сутки в low режиме
Я так же сначала получил доступ и верифицировал свою организацию (заняло это не более 5 минут) полет стабильный!
Сгенерировано по запросу: "Cобака бежит по дороге она смотрит на меня глазами красными и в костюме лебовского
На заднем плане стоят люди у обрыва и рассыпают прах как из фильма"
Антропоморфный накачанный кот породы экзот идёт по улице и на него влюбленным взглядом смотрят антропоморфные кошки в разных платьях
Это ок что она кадры из фильма подсовывает?
Гоу тестить пока не вырубил бота всем фри 1 генерацию
1024х1024 high (скорость около 30-50 секунд
За 15 картинок вышло 3,7 бакса или 20 рублей за картинку)
@gptimage1bot
💯12🔥10😁6❤3
Безопасный ИИ в вашей компании?
Вчера мы проводили програму развития целому отделу ИБ (на тему безопасности и LLM)
Стартовали с того что же такое LLM и как они устроены закончили нашим видением на будущее
Обсудили базовые концепции GuardRails
Прошлись по базовым защитам чат-ботов
Проговорили про новые уязвимости, которые может создать внедрение LLM
Поделились опытом построения RAG систем и разграничения прав доступа на корпоративном уровне
Из нового в нашем формате это был лайв кодинг на примере разработки простых систем тестирования гипотез ллм через Курсор
Вчера мы проводили програму развития целому отделу ИБ (на тему безопасности и LLM)
Стартовали с того что же такое LLM и как они устроены закончили нашим видением на будущее
Обсудили базовые концепции GuardRails
Прошлись по базовым защитам чат-ботов
Проговорили про новые уязвимости, которые может создать внедрение LLM
Поделились опытом построения RAG систем и разграничения прав доступа на корпоративном уровне
Из нового в нашем формате это был лайв кодинг на примере разработки простых систем тестирования гипотез ллм через Курсор
🔥32👍10
n8n + Qwen 2.5 7b instruct + vLLM + SO = Мощный диджитал твин на своем железе!
Всем привет!
По следам экспериментов я решил собрать небольшой пост старт по тематике n8n здорового человека
Что это такое?
Low-code подход через n8n для построения логики "диджитал твина"
vLLM для оптимизации инференса модели на локальной инфре + под капотом есть xgrammar
Qwen 2.5 7b instruct(t-lite) - неожиданно эффективная для SO и классификации интентов под такие задачи
Интеграция с RAG Smart Platform как "знаниевый агент" в наборе инструментов
Как это работает?
Structured Output вместо встроенных агентов которые работат на tool которые ломаются чаще российского автопрома для классификации намерений
Гибкая архитектура инструментов через n8n ноды(пришлось попотеть через js Vibe Coding спасает)
Маршрутизация запросов на основе четкой классификации где нет места гибким условиям если есть только flow!
Интеграция с внешними API и базами знаний
Что сейчас умеет такой спрут? Причем n8n стоит локальной на моем сервере
Выбор инструмента на основе намерения пользователя
Роутинг между различными исполнителями задач
Универсальный метод для разных типов запросов (часто без необходимости переобучения модели)
Форматирование запросов от каждой внешней АПИ типо погоды или календаря под тот формат который я задумал для визуализации пользователю!
Система не идеальная, но уже можно автоматизировать множество процессов!
Если вам интересно то этот пост байт на коменты и реакции
Хочу понять стоит ли пилить отдельный пост разбор + выложить код всех нод на гит для повторения!
Всем привет!
По следам экспериментов я решил собрать небольшой пост старт по тематике n8n здорового человека
Что это такое?
Low-code подход через n8n для построения логики "диджитал твина"
vLLM для оптимизации инференса модели на локальной инфре + под капотом есть xgrammar
Qwen 2.5 7b instruct(t-lite) - неожиданно эффективная для SO и классификации интентов под такие задачи
Интеграция с RAG Smart Platform как "знаниевый агент" в наборе инструментов
Как это работает?
Structured Output вместо встроенных агентов которые работат на tool которые ломаются чаще российского автопрома для классификации намерений
Гибкая архитектура инструментов через n8n ноды(пришлось попотеть через js Vibe Coding спасает)
Маршрутизация запросов на основе четкой классификации где нет места гибким условиям если есть только flow!
Интеграция с внешними API и базами знаний
Что сейчас умеет такой спрут? Причем n8n стоит локальной на моем сервере
Выбор инструмента на основе намерения пользователя
Роутинг между различными исполнителями задач
Универсальный метод для разных типов запросов (часто без необходимости переобучения модели)
Форматирование запросов от каждой внешней АПИ типо погоды или календаря под тот формат который я задумал для визуализации пользователю!
Система не идеальная, но уже можно автоматизировать множество процессов!
Если вам интересно то этот пост байт на коменты и реакции
Хочу понять стоит ли пилить отдельный пост разбор + выложить код всех нод на гит для повторения!
6❤71🔥51👍17
Forwarded from red_mad_dev
MoscowJS 64 x red_mad_robot⚡️
15 мая встречаемся на митапе в Робохранилище в Москве.
Поговорим про качество кода, стандарты и то как это влияет на разработчиков и команды. Будем постепенно рассказывать про наших спикеров — следите за обновлениями здесь и в чате сообщества @moscowjs
🕔 15 мая, четверг, стартуем в 19:00
📍 Москва + онлайн
🔗 Регистрация по ссылке.
До встречи🟥
15 мая встречаемся на митапе в Робохранилище в Москве.
Поговорим про качество кода, стандарты и то как это влияет на разработчиков и команды. Будем постепенно рассказывать про наших спикеров — следите за обновлениями здесь и в чате сообщества @moscowjs
До встречи
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Vladislav Shevchenko
Материалы по Cursor
🔥 Рекомендуемые ресурсы:
• My LLM codegen workflow
• Как заставить ИИ работать в устаревших кодовых базах
• Видео-гайд по Cursor
📚 Дополнительные материалы:
• Awesome Cursor Rules
• A Structured Workflow for "Vibe Coding" Full-Stack Apps
• Гайд по вайб-кодингу от Anthropic
💡 Мнения:
• Почему я перестал использовать редакторы кода на основе ИИ
• Как заставить AI писать качественный код?
• Вся правда про Cursor
🔗 Официальные ресурсы:
• Документация
• Форум
🔥 Рекомендуемые ресурсы:
• My LLM codegen workflow
• Как заставить ИИ работать в устаревших кодовых базах
• Видео-гайд по Cursor
📚 Дополнительные материалы:
• Awesome Cursor Rules
• A Structured Workflow for "Vibe Coding" Full-Stack Apps
• Гайд по вайб-кодингу от Anthropic
💡 Мнения:
• Почему я перестал использовать редакторы кода на основе ИИ
• Как заставить AI писать качественный код?
• Вся правда про Cursor
🔗 Официальные ресурсы:
• Документация
• Форум
🔥22❤7👍6
Smart Platform - наша on-premise RAG платформа
Врываюсь с двух ног почти готовым релизом нашего внутреннего продукта почти коробка (а за плечами 7 месяцев исследований реальных интеграций и разработки)!
Нет ничего приятнее рабочих якорей (ссылок на источники, которые подсвечивают информацию в нужной вам интеграции, использовавшуюся при ответе LLM), которые показаны на нативной интеграции с Confluence в закрытом контуре
И еще больше кайфую, что это уже работает не только в теории, но и на наших внутренних тестах на демо стенде!
Такой RAG может работать и на моделях до 10b (LLM), а значит, сервер для корпоративного RAG начинает стоить адекватных денег
Целая цепочка router-агентов и долгий путь изучения лучших подходов и фреймворков для Q&A и диалоговых RAG-систем для закрытого контура
За всеми апдейтами по продукту предлагаю следить тут в канале нашего CPO Леши Жданова
Врываюсь с двух ног почти готовым релизом нашего внутреннего продукта почти коробка (а за плечами 7 месяцев исследований реальных интеграций и разработки)!
Нет ничего приятнее рабочих якорей (ссылок на источники, которые подсвечивают информацию в нужной вам интеграции, использовавшуюся при ответе LLM), которые показаны на нативной интеграции с Confluence в закрытом контуре
И еще больше кайфую, что это уже работает не только в теории, но и на наших внутренних тестах на демо стенде!
Такой RAG может работать и на моделях до 10b (LLM), а значит, сервер для корпоративного RAG начинает стоить адекватных денег
Целая цепочка router-агентов и долгий путь изучения лучших подходов и фреймворков для Q&A и диалоговых RAG-систем для закрытого контура
За всеми апдейтами по продукту предлагаю следить тут в канале нашего CPO Леши Жданова
❤21🔥18👍13
Forwarded from Pavel Zloi
Почему я считаю, что RAG это call?
Пару часов назад Александр на своем канале Dealer AI снова обратил внимание на RAG-системы с точки зрения важности тестирования и оценки метрик до внедрения указанных систем в продакшен.
Я полностью разделяю эту точку зрения и всегда прошу заказчиков, по возможности, предоставлять хотя бы общий тестовый датасет, на базе которого можно будет выполнить предварительную оценку точности работы проекта и произвести его тонкую настройку до публичного релиза.
Как-то раз общался с заказчиком по одному проекту и пытался объяснить ему важность предварительного сбора бенчмарков для оценки качества системы. Логика у меня была простая: если предположим, некая RAG-система состоит из трёх последовательных звеньев (эмбеддер, ретривер, LLM), каждое из которых имеет точность, скажем, 90%, то интуитивно кажется, что и общая точность будет примерно на том же уровне. Однако на самом деле всё сложнее.
Согласно теории надёжности, в последовательных системах ошибки наследуются, и итоговая точность определяется перемножением точностей всех звеньев. Если каждый из трёх модулей даёт точность 90% (0.9), то реальная точность системы будет равна:
Это значит, что при последовательном соединении звеньев системы и с увеличением их количества вероятность ошибки увеличивается.
Подробнее о наследовании ошибок можно почитать в публикации про закон Люссера.
С другой стороны, интуитивно (без учёта наследования ошибок) может показаться, что точность системы определяется её самым слабым компонентом, в нашем примере — 90%, и, как следствие, заказчик принимает решение пренебречь предрелизным тестированием, так как верит в надёжность RAG-системы, полагаясь на интуицию.
Подобное заблуждение, как мне кажется, связано с психологическими особенностями человеческого мышления, описанными Даниэлом Канеманом в его книге "Думай медленно... решай быстро". Канеман подчёркивает, что решения, принимаемые на основе интуиции, часто приводят к систематическим ошибкам, поскольку наш мозг упрощает сложные задачи или подменяет их более простыми, игнорируя важные факторы, такие как накопление ошибок в последовательных звеньях.
Приведу ещё один пример. Если мы используем сверхточный эмбеддер (99%), средний по качеству ретривер (90%) и относительно слабую языковую модель (70%), общая точность станет:
Иными словами, замена одного компонента на более точный не всегда существенно повышает общую точность, если остальные компоненты остаются слабыми.
Понимание того, какой компонент является критически важным в нашей RAG-системе, а какой даёт слишком большую ошибку, и есть причина, по которой необходимо иметь бенчмарки ещё в процессе разработки.
Пару часов назад Александр на своем канале Dealer AI снова обратил внимание на RAG-системы с точки зрения важности тестирования и оценки метрик до внедрения указанных систем в продакшен.
Я полностью разделяю эту точку зрения и всегда прошу заказчиков, по возможности, предоставлять хотя бы общий тестовый датасет, на базе которого можно будет выполнить предварительную оценку точности работы проекта и произвести его тонкую настройку до публичного релиза.
Как-то раз общался с заказчиком по одному проекту и пытался объяснить ему важность предварительного сбора бенчмарков для оценки качества системы. Логика у меня была простая: если предположим, некая RAG-система состоит из трёх последовательных звеньев (эмбеддер, ретривер, LLM), каждое из которых имеет точность, скажем, 90%, то интуитивно кажется, что и общая точность будет примерно на том же уровне. Однако на самом деле всё сложнее.
Согласно теории надёжности, в последовательных системах ошибки наследуются, и итоговая точность определяется перемножением точностей всех звеньев. Если каждый из трёх модулей даёт точность 90% (0.9), то реальная точность системы будет равна:
0.9 = 0.9
0.9 * 0.9 ≈ 0.81 (81%)
0.9 * 0.9 * 0.9 ≈ 0.729 (72.9%)
0.9 * 0.9 * 0.9 * 0.9 ≈ 0.656 (65.6%)
Это значит, что при последовательном соединении звеньев системы и с увеличением их количества вероятность ошибки увеличивается.
Подробнее о наследовании ошибок можно почитать в публикации про закон Люссера.
С другой стороны, интуитивно (без учёта наследования ошибок) может показаться, что точность системы определяется её самым слабым компонентом, в нашем примере — 90%, и, как следствие, заказчик принимает решение пренебречь предрелизным тестированием, так как верит в надёжность RAG-системы, полагаясь на интуицию.
Подобное заблуждение, как мне кажется, связано с психологическими особенностями человеческого мышления, описанными Даниэлом Канеманом в его книге "Думай медленно... решай быстро". Канеман подчёркивает, что решения, принимаемые на основе интуиции, часто приводят к систематическим ошибкам, поскольку наш мозг упрощает сложные задачи или подменяет их более простыми, игнорируя важные факторы, такие как накопление ошибок в последовательных звеньях.
Приведу ещё один пример. Если мы используем сверхточный эмбеддер (99%), средний по качеству ретривер (90%) и относительно слабую языковую модель (70%), общая точность станет:
0.99 * 0.9 * 0.7 ≈ 0.623 (62.3%)
Иными словами, замена одного компонента на более точный не всегда существенно повышает общую точность, если остальные компоненты остаются слабыми.
Понимание того, какой компонент является критически важным в нашей RAG-системе, а какой даёт слишком большую ошибку, и есть причина, по которой необходимо иметь бенчмарки ещё в процессе разработки.
Telegram
Dealer.AI
Жоский ИИ дядя.
Твой личный поставщик AI 💊💉🤖
Канал о мире интересного AI: ML, DL, NLP/NLU, RL, Retrieval, RecSys.
Для связи @dealer_ai
(реклама и консультации)
Руковожу ML, AI командами.
Habr: @Andriljo
Kaggle: https://www.kaggle.com/andrilko
Твой личный поставщик AI 💊💉🤖
Канал о мире интересного AI: ML, DL, NLP/NLU, RL, Retrieval, RecSys.
Для связи @dealer_ai
(реклама и консультации)
Руковожу ML, AI командами.
Habr: @Andriljo
Kaggle: https://www.kaggle.com/andrilko
👍23🔥12❤4
Forwarded from #безвотэтоговотвсего
Международный вояж #безвотэтоговотвсего продолжается и мы возвращаемся в наш любимый Баку!
На нашей пятой встрече сообщества в этом прекрасном городе мы решили взять тему, которая точно не оставит равнодушным никого из тех, кто хоть чуть-чуть связан с технологиями (а есть ли другие в 2025 году?).
Тема нашей встречи - “Мир после GPT: как AI меняет рынок IT и продуктов навсегда?”. Ведь здесь, помимо хайпа, просто море интересного:
⁃ Что именно изменилось в работе IT и продуктовых команд с приходом AI?
⁃ Что теперь значит "быть профессионалом"? Раньше — знания и опыт. Сейчас — умение работать с ИИ?
⁃ Что произойдет с ощущением профессиональной идентичности? Кто я, если мои навыки заменяемы моделью?
⁃ Какие новые этические дилеммы появляются с развитием AI? Если GPT написал код с багом — кто виноват?
⁃ Почему middle-специалисты стоят как senior, если GPT делает их работу?
⁃ и многое другое )
На эту тему собрались поговорить прекрасные эксперты:
⁃ Сергей Рыжиков, основатель Битрикс24
⁃ Иван Самсонов, CPO of AI, MTS Web Services
⁃ Валерий Ковальский, Head of AI red_mad_robot
⁃ Валех Набиев, CDO at Pasha Holding
Состав уникальный и точно позволяющий разобрать вопрос с разных сторон.
Обязательно регистрируйтесь и сохраняйте билеты.
Встречаемся 03 июня в 18:30 JW Mariott Absheron (674 Azadliq Square).
Будет огненно!)
На нашей пятой встрече сообщества в этом прекрасном городе мы решили взять тему, которая точно не оставит равнодушным никого из тех, кто хоть чуть-чуть связан с технологиями (а есть ли другие в 2025 году?).
Тема нашей встречи - “Мир после GPT: как AI меняет рынок IT и продуктов навсегда?”. Ведь здесь, помимо хайпа, просто море интересного:
⁃ Что именно изменилось в работе IT и продуктовых команд с приходом AI?
⁃ Что теперь значит "быть профессионалом"? Раньше — знания и опыт. Сейчас — умение работать с ИИ?
⁃ Что произойдет с ощущением профессиональной идентичности? Кто я, если мои навыки заменяемы моделью?
⁃ Какие новые этические дилеммы появляются с развитием AI? Если GPT написал код с багом — кто виноват?
⁃ Почему middle-специалисты стоят как senior, если GPT делает их работу?
⁃ и многое другое )
На эту тему собрались поговорить прекрасные эксперты:
⁃ Сергей Рыжиков, основатель Битрикс24
⁃ Иван Самсонов, CPO of AI, MTS Web Services
⁃ Валерий Ковальский, Head of AI red_mad_robot
⁃ Валех Набиев, CDO at Pasha Holding
Состав уникальный и точно позволяющий разобрать вопрос с разных сторон.
Обязательно регистрируйтесь и сохраняйте билеты.
Встречаемся 03 июня в 18:30 JW Mariott Absheron (674 Azadliq Square).
Будет огненно!)
🔥13 6❤5💯2
Media is too big
VIEW IN TELEGRAM
UI-Browser LLM automation песочница для автоматизация браузера на базе LLM
Давно обещал вылить свой форк тут показывал прошлые наработки browser-use-web-ui да еще и в одном из чатов попросили
Все внутри просто
И полетели!
Вот держите что я там наваял?
Единый интерфейс: Объединенный доступ к Gradio и VNC в одном окне браузера
Защищенный доступ: Авторизация по логину и паролю для контроля доступа
Разделенный экран: Фиксированное разделение экрана 50/50 для комфортной работы
Прямая интеграция: Прямой доступ к браузеру через VNC для полного контроля (буфер обемна можно самому что-то кликать)
Что меня удивило что офф версия не работает но моя старая версия работала пришлось совместить функционал новой офф версии и старого кода вышло вроде не плохо (работает и на том спасибо)
GitHub
Давно обещал вылить свой форк тут показывал прошлые наработки browser-use-web-ui да еще и в одном из чатов попросили
Все внутри просто
docker compose up -d
И полетели!
Вот держите что я там наваял?
Единый интерфейс: Объединенный доступ к Gradio и VNC в одном окне браузера
Защищенный доступ: Авторизация по логину и паролю для контроля доступа
Разделенный экран: Фиксированное разделение экрана 50/50 для комфортной работы
Прямая интеграция: Прямой доступ к браузеру через VNC для полного контроля (буфер обемна можно самому что-то кликать)
Что меня удивило что офф версия не работает но моя старая версия работала пришлось совместить функционал новой офф версии и старого кода вышло вроде не плохо (работает и на том спасибо)
GitHub
🔥16👍6👏4❤1
Forwarded from red_mad_robot
Подборка сервисов для быстрой оценки и сравнения LLM
Открытых моделей становится всё больше, а универсального ответа, какую ставить в продукт — нет. Одним важна точность, другим — стоимость, масштабируемость или устойчивость на длинных запросах.
Сравнительные сервисы упрощают этот выбор: они фиксируют поведение в реальных сценариях, агрегируют пользовательские оценки и показывают, какие решения уже в продакшене. Собрали подборку таких платформ.
1️⃣ OpenRouter: рейтинг LLM по реальному использованию
OpenRouter публикует открытый рейтинг моделей, основанный на частоте их использования в реальных продуктах. Это не лабораторные тесты, а фактические данные из прикладных сценариев: кодинг, маркетинг, финтех, технологии.
Рейтинг можно фильтровать по задачам и периоду: за день, неделю, месяц или по росту популярности. Это рыночный барометр: если модель стабильно удерживает лидерство в вашей категории — её используют в продакшене.
2️⃣ Chatbot Arena (LMSYS): парные сравнения моделей
Платформа предлагает формат арены: пользователь задаёт вопрос, а две модели отвечают параллельно. После этого выбирается лучший ответ. По итогам сравнений формируется рейтинг по системе Elo — как в шахматах, только для LLM.
Для моделей на русском языке есть аналог — LLM Arena. Сервис также поддерживает сравнения, голосование за лучший ответ и динамический рейтинг. Включены YandexGPT, GigaChat, MTS AI и другие модели.
3️⃣ Hugging Face: рейтинг по независимым бенчмаркам
В отличие от рейтингов популярности или пользовательских голосов, Hugging Face оценивает модели по результатам стандартных тестов: MMLU (общие знания), BBH (логика), IFEval (следование инструкциям), кодингу, математике и другим. Каждая модель получает баллы по ряду метрик, по которым можно отсортировать модели.
4️⃣ MERA: открытый бенчмарк для русскоязычных LLM
Лидерборд ранжирует модели по результатам фиксированного набора задач: логика, код, знания, этика. Оценка проходит в равных условиях: стандартизированные промпты, единые параметры, открытая методика.
Подходит, если вы работаете с русскоязычными моделями, и вам важна применимость и эффективность в конкретной области.
Какие выводы?
Выбор LLM — это управленческое решение с последствиями для качества, стоимости и скорости продукта. Сравнительные платформы не заменяют пилоты, но позволяют действовать быстрее и точнее:
📍 Отсекать слабые решения до интеграции
📍 Фокусироваться на моделях, которые уже работают в продакшене
📍 Оценивать зрелость open-source вариантов без риска потерь в качестве
Если вы внедряете LLM в продукт, рейтинги помогают действовать не по наитию, а по обоснованным критериям. Но важно не полагаться на один источник — первичную кросс-оценку стоит строить на данных из разных сервисов.
#AI_moment
@Redmadnews
Открытых моделей становится всё больше, а универсального ответа, какую ставить в продукт — нет. Одним важна точность, другим — стоимость, масштабируемость или устойчивость на длинных запросах.
Сравнительные сервисы упрощают этот выбор: они фиксируют поведение в реальных сценариях, агрегируют пользовательские оценки и показывают, какие решения уже в продакшене. Собрали подборку таких платформ.
OpenRouter публикует открытый рейтинг моделей, основанный на частоте их использования в реальных продуктах. Это не лабораторные тесты, а фактические данные из прикладных сценариев: кодинг, маркетинг, финтех, технологии.
Рейтинг можно фильтровать по задачам и периоду: за день, неделю, месяц или по росту популярности. Это рыночный барометр: если модель стабильно удерживает лидерство в вашей категории — её используют в продакшене.
Платформа предлагает формат арены: пользователь задаёт вопрос, а две модели отвечают параллельно. После этого выбирается лучший ответ. По итогам сравнений формируется рейтинг по системе Elo — как в шахматах, только для LLM.
Для моделей на русском языке есть аналог — LLM Arena. Сервис также поддерживает сравнения, голосование за лучший ответ и динамический рейтинг. Включены YandexGPT, GigaChat, MTS AI и другие модели.
В отличие от рейтингов популярности или пользовательских голосов, Hugging Face оценивает модели по результатам стандартных тестов: MMLU (общие знания), BBH (логика), IFEval (следование инструкциям), кодингу, математике и другим. Каждая модель получает баллы по ряду метрик, по которым можно отсортировать модели.
Лидерборд ранжирует модели по результатам фиксированного набора задач: логика, код, знания, этика. Оценка проходит в равных условиях: стандартизированные промпты, единые параметры, открытая методика.
Подходит, если вы работаете с русскоязычными моделями, и вам важна применимость и эффективность в конкретной области.
Какие выводы?
Выбор LLM — это управленческое решение с последствиями для качества, стоимости и скорости продукта. Сравнительные платформы не заменяют пилоты, но позволяют действовать быстрее и точнее:
Если вы внедряете LLM в продукт, рейтинги помогают действовать не по наитию, а по обоснованным критериям. Но важно не полагаться на один источник — первичную кросс-оценку стоит строить на данных из разных сервисов.
#AI_moment
@Redmadnews
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥18 12👍6👏3