Forwarded from Заметки Computer Vision инженера
DINOv3 прикольная штука. Плюсы и минусы более-менее понятны. Но вкратце попробовал пройтись по ним в видео.
Заодно побенчмаркал Intel-овскую NPU-шку на новом компе + AMD-шную NPU на доступном компе.
Вообще DINOv3 на удивление везде хуже работает.
https://youtu.be/HaJNyyWsio4
Заодно побенчмаркал Intel-овскую NPU-шку на новом компе + AMD-шную NPU на доступном компе.
Вообще DINOv3 на удивление везде хуже работает.
https://youtu.be/HaJNyyWsio4
YouTube
DINOv3 - running on Intel NPU and AMD NPU
My LinkedIn - https://www.linkedin.com/in/maltsevanton/
My Telegram channel - https://t.iss.one/CVML_team
e-mail: [email protected]
Twitter - https://twitter.com/Serious_WK
Do you have any questions about the board and ML around, or do you need advice? Feel…
My Telegram channel - https://t.iss.one/CVML_team
e-mail: [email protected]
Twitter - https://twitter.com/Serious_WK
Do you have any questions about the board and ML around, or do you need advice? Feel…
Forwarded from Канал Доброго Вани | Data Science и Продуктики
А вот так, давайте разбираться что к чему. Что из себя представляют товары на маркетплейсе? Для простоты, давайте разберем только текстовый аспект: это заголовок, описание, какие-то характеристики, отзывы, название бренда, производителя и др...
В таком случае мы можем взять два берта-башни (фото 2), подавать первые последовательности на вход первой башне, вторые последовательности на вход второй башне, выходы башен как-то совместно преобразовывать (например, считать по ним косинус или евклидово расстояние, конкатенировать и применять линейные слои и тд...) и по результату преобразования считать лосс. Таким образом, мы "сближаем" похожие элементы, обучая башни максимизировать скоры похожих элементов и минимизировать скоры непохожих. В качестве таргета можем взять бинарную величину (0 - элементы непохожи, 1 - элементы похожи, BCE Loss).
Важно отметить, что башен может быть и две, и три, и десять. Например, вы хотите не просто найти релевантный товар для пользователя, а сразу пару релевантных товаров. Тогда, как вариант, заиспользовать Башню пользователя, Башню товара №1 и Башню товара №2. Вобщем, фантазия здесь безграничная.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Korenev AI - GPT в тапочках🩴
5:30 утра. Не спалось. Вчера обсуждали метод расстановок в психологии - и я подумал: а почему бы не проверить это на себе?
Никогда ранее подобным не занимался, но подумал, вдруг это поможет избавиться от лишней суеты в некоторых сферах.
Работа с Клодом показала мне паттерны, которые раньше были скрыты - разбирали мои поступки через отношения с ближайшими родственниками. Местами - до слез.
Выкладываю промпт, собранный Клодом. Проверено на себе:
Ты - опытный мастер системных расстановок с 15-летним стажем, обученный методу Берта Хеллингера и современным подходам в расстановочной работе. Ты обладаешь глубоким пониманием системных динамик, родовых переплетений и порядков любви.
Твои ключевые компетенции:
1. Теоретическая база
- Глубокое понимание системных законов (принадлежность, иерархия, баланс давать-брать)
- Знание феноменологического подхода
- Понимание трансгенерационных связей и родовой травмы
- Владение концепциями "прерванного движения любви" и "исключенных из системы"
2. Практические навыки
- Умение создавать безопасное пространство для клиента
- Способность видеть скрытые динамики в системе
- Навык работы с заместителями (в онлайн формате - через визуализацию)
- Умение находить разрешающие фразы и ритуалы
3. Этические принципы
- Уважение к судьбе каждого члена системы
- Отсутствие осуждения
- Следование за энергией системы, а не навязывание решений
- Конфиденциальность и бережность
Формат работы:
При первом контакте:
1. Приветствуй клиента тепло и создай атмосферу доверия
2. Кратко объясни суть метода расстановок (если необходимо)
3. Спроси о запросе - с чем человек хочет работать
4. Уточни важную информацию о семейной системе
Ключевые вопросы для прояснения:
- "Что вы хотите изменить в своей жизни?"
- "Кто входит в вашу семейную систему?" (родители, братья/сестры, значимые партнеры, дети)
- "Были ли в роду тяжелые судьбы?" (ранние смерти, исключения, тайны, войны, репрессии)
- "Какие чувства вы испытываете, когда думаете об этой ситуации?"
Проведение расстановки:
1. Определение фигур - выясни, кого нужно поставить в поле
2. Расстановка - предложи клиенту мысленно расставить фигуры в пространстве
3. Наблюдение динамик - опиши, что происходит в поле (напряжения, движения, чувства)
4. Поиск решения - через разрешающие фразы, поклоны, принятие
5. Интеграция - помоги клиенту принять новый образ
Разрешающие фразы (примеры):
- "Я вижу тебя и уважаю твою судьбу"
- "Ты большой/большая, я маленький/маленькая"
- "Я принимаю от тебя жизнь и передаю её дальше"
- "То, что произошло, останется с тобой, а я пойду своим путём"
- "Я отдаю тебе твоё и беру своё"
Типичные системные динамики:
- Парентификация - ребёнок занимает место родителя
- Идентификация - человек повторяет судьбу исключенного
- Прерванное движение любви - блокировка чувств к родителям
- Треугольники - вовлечение третьего в отношения пары
- Системная совесть - лояльность роду через повторение судеб
Стиль коммуникации:
- Говори медленно, давая время для внутренней работы
- Используй простые, но глубокие фразы
- Избегай интерпретаций - следуй за тем, что показывает поле
- Будь внимателен к чувствам и телесным ощущениям клиента
- Периодически спрашивай: "Как это для вас?" "Что вы чувствуете?"
Важные напоминания:
- Не все можно решить за одну расстановку
- Некоторые вещи нужно оставить как есть
- Уважай сопротивление - оно тоже имеет смысл
- Решение приходит через принятие, а не через борьбу
- Любовь ребёнка к родителям безусловна и не может быть отменена
Завершение сессии:
1. Убедись, что клиент заземлён и находится в контакте с собой
2. Дай время на интеграцию опыта
3. Предложи не обсуждать расстановку 2-3 дня
4. Напомни, что изменения могут проявляться постепенно
Противопоказания для работы:
- Острые психотические состояния
- Суицидальные намерения (требуется помощь психиатра)
- Нежелание клиента работать с семейной системой
- Отсутствие запроса на изменения
Помни: ты работаешь с глубинными слоями психики и родовой памятью. Будь бережен, следуй за системой, доверяй полю и мудрости рода.
Всем любви и мира
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Neural Kovalskii
SGR vs Tools: когда использовать Schema-Guided Reasoning, а когда Function Calling в LLM-системах
Сегодня хочу поднять тему, которую у меня часто спрашивают: когда использовать Tool Calling, а когда Schema-Guided Reasoning (SGR) в LLM решениях под капотом?
Респект Ринату Абдуллину за отличную систематизацию подхода SGR!
Что забавно, я сам использовал похожие паттерны 4-5 месяцев назад загляните в гит, но именно Ринат дал этому четкое название и структуру!
SGR vs Tools по моему мнению
SGR заставляем LLM мыслить по четким шагам через Structured Output:
Анализ → Поиск → Обработка → Вывод в одном запросе
Tools даем LLM набор функций для взаимодействия с внешним миром
Кстати все больше вижу сдвиг именно в паттерн агент=tool_call MCP+SO(где надо) и теперь SGR:
Поиск, API, вычисления, полноценное агентское поведение
Пример SGR из моей практики:
Когда использовать SGR:
Анализ и структуризация данных
Разбор документов, классификация, отчеты
Сложные рассуждения
Пошаговый анализ с обоснованием
Обработка имеющихся данных
Все нужное уже в контексте, нужна предсказуемость но не детерминированность (запомним)
Когда использовать Tools:
Настоящее агентское поведение
LLM сам решает последовательность, адаптируется к результатам, может прерываться
Не зря появилась куча оберток типа LangGraph, AutoGen, CrewAI все строятся именно на свойствах
Tools когда модель сама принимает решение их вызвать
А MCP от Anthropic на мой взгляд это попытка стандартизировать агентские инструментарий
Взаимодействие с внешними системами
Интернет, email, календарь, API
Критически важно для production Evals и мониторинг!
SGR:
Все рассуждения видны и логированы
Легко тестировать каждый шаг
A/B тестирование предсказуемо
Tools:
LLM сам решает какой инструмент вызвать — черный ящик
Сложно понять WHY выбрана функция
Непредсказуемая цепочка вызовов
Дебаг в production = боль
Из реального опыта:
При настройке NSFW-фильтров с Tools ушло бы недели на понимание решений модели с SO было бы сложно дебажить.
С SGR за день увидел проблемы в reasoning и пофиксил качество!
Ключевое различие — агентность vs структурированность
SGR = мощное рассуждение без истинной агентности
Один запрос → один ответ
Для агентского поведения придется костылить
Tools = настоящее агентское поведение из коробки
LLM сам управляет workflow, нативные прерывания в большинстве фреймворков и API
Поэтому все современные агентские фреймворки базируются именно на Tools
Гибридный подход? Искал медь а нашел золото!
SGR для принятия решений какой инструмент использовать
Tools для выполнения действий получение данных и ощущение агентности
SGR для финальной обработки структуризация результата
Вывод финально
SGR когда нужно контролируемое рассуждение и мониторинг
Tools когда нужно настоящее агентское поведение
SGR работает даже на локальных 7B моделях и даже на qwen3 4B
Update:
Ринат подкинул очень интересную демку, смешение в сторону SGR в агентах
Как запускать вместе и то и другое
Можно и вместе.
См демку с многоходовым бизнес-ассистентом
Ребята из Сбера допилили это до запуска на Qwen 3 4B
В production качество мониторинга = выживание продукта
А как вы решаете эту дилемму? Поделитесь опытом!
P.S. Спасибо Ринату за системный подход к SGR это свежий глоток точности и постоянства в нашем мире LLM!
P.S.S Забирайте все ссылки как памятку, SGR это то что будет двигать production сектор дальше к внедрению LLM!
Сегодня хочу поднять тему, которую у меня часто спрашивают: когда использовать Tool Calling, а когда Schema-Guided Reasoning (SGR) в LLM решениях под капотом?
Респект Ринату Абдуллину за отличную систематизацию подхода SGR!
Что забавно, я сам использовал похожие паттерны 4-5 месяцев назад загляните в гит, но именно Ринат дал этому четкое название и структуру!
SGR vs Tools по моему мнению
SGR заставляем LLM мыслить по четким шагам через Structured Output:
Анализ → Поиск → Обработка → Вывод в одном запросе
Tools даем LLM набор функций для взаимодействия с внешним миром
Кстати все больше вижу сдвиг именно в паттерн агент=tool_call MCP+SO(где надо) и теперь SGR:
Поиск, API, вычисления, полноценное агентское поведение
Пример SGR из моей практики:
{
"reasoning": {
"query_analysis": {
"user_query": "Найди информацию о проекте X",
"query_interpretation": "Пользователь ищет документы по проекту"
},
"information_search": {
"search_strategy": "Ищу по ключевым словам в базе",
"relevant_documents": [...]
}
},
"response": "Полный ответ на основе найденной информации"
}Когда использовать SGR:
Анализ и структуризация данных
Разбор документов, классификация, отчеты
Сложные рассуждения
Пошаговый анализ с обоснованием
Обработка имеющихся данных
Все нужное уже в контексте, нужна предсказуемость но не детерминированность (запомним)
Когда использовать Tools:
Настоящее агентское поведение
LLM сам решает последовательность, адаптируется к результатам, может прерываться
Не зря появилась куча оберток типа LangGraph, AutoGen, CrewAI все строятся именно на свойствах
Tools когда модель сама принимает решение их вызвать
А MCP от Anthropic на мой взгляд это попытка стандартизировать агентские инструментарий
Взаимодействие с внешними системами
Интернет, email, календарь, API
Критически важно для production Evals и мониторинг!
SGR:
Все рассуждения видны и логированы
Легко тестировать каждый шаг
A/B тестирование предсказуемо
Tools:
LLM сам решает какой инструмент вызвать — черный ящик
Сложно понять WHY выбрана функция
Непредсказуемая цепочка вызовов
Дебаг в production = боль
Из реального опыта:
При настройке NSFW-фильтров с Tools ушло бы недели на понимание решений модели с SO было бы сложно дебажить.
С SGR за день увидел проблемы в reasoning и пофиксил качество!
Ключевое различие — агентность vs структурированность
SGR = мощное рассуждение без истинной агентности
Один запрос → один ответ
Для агентского поведения придется костылить
Tools = настоящее агентское поведение из коробки
LLM сам управляет workflow, нативные прерывания в большинстве фреймворков и API
Поэтому все современные агентские фреймворки базируются именно на Tools
Гибридный подход? Искал медь а нашел золото!
SGR для принятия решений какой инструмент использовать
Tools для выполнения действий получение данных и ощущение агентности
SGR для финальной обработки структуризация результата
Вывод финально
SGR когда нужно контролируемое рассуждение и мониторинг
Tools когда нужно настоящее агентское поведение
SGR работает даже на локальных 7B моделях и даже на qwen3 4B
Update:
Ринат подкинул очень интересную демку, смешение в сторону SGR в агентах
Как запускать вместе и то и другое
Можно и вместе.
См демку с многоходовым бизнес-ассистентом
Ребята из Сбера допилили это до запуска на Qwen 3 4B
В production качество мониторинга = выживание продукта
А как вы решаете эту дилемму? Поделитесь опытом!
P.S. Спасибо Ринату за системный подход к SGR это свежий глоток точности и постоянства в нашем мире LLM!
P.S.S Забирайте все ссылки как памятку, SGR это то что будет двигать production сектор дальше к внедрению LLM!
Forwarded from Neural Kovalskii
SGR Deep Research
А почему бы не взять все лучшие идеи из демо и идей ребят из чата
Собрать свои идеи по Deep Research
И сделать самый простой инструмент поиска инфы в интернете через Tavlily API?
А сделать, вот он https://github.com/vakovalskii/sgr-deep-research (звездочки приветствуются)
gpt-4o-mini
Tavily API (1000 реквестов в месяц фри)
SGR-concept
Из интересного что заметил такая модель сама определяет что например чипов M6 у applе не существует и на ходу меняет план рисерча потому что нашла это в данных из инета
Или что термин SGR ей не понятен и просит его расшифровать
Что я закинул туда "навайбкодил"
Соответствие концепту SGR верифицировало Ринатом 😂
Предлагайте ваши эксперименты! Вон даже ребята из Cбера подключились!
А почему бы не взять все лучшие идеи из демо и идей ребят из чата
Собрать свои идеи по Deep Research
И сделать самый простой инструмент поиска инфы в интернете через Tavlily API?
А сделать, вот он https://github.com/vakovalskii/sgr-deep-research (звездочки приветствуются)
gpt-4o-mini
Tavily API (1000 реквестов в месяц фри)
SGR-concept
Из интересного что заметил такая модель сама определяет что например чипов M6 у applе не существует и на ходу меняет план рисерча потому что нашла это в данных из инета
Или что термин SGR ей не понятен и просит его расшифровать
Что я закинул туда "навайбкодил"
1. 🤔 Clarification (ВЫСШИЙ ПРИОРИТЕТ)
- При любой неопределенности в запросе
- Неизвестные термины, акронимы, аббревиатуры
- Неоднозначные запросы с множественными интерпретациями
- Отсутствие контекста для специализированных областей
2. 📋 GeneratePlan
- Когда план не существует и запрос ясен
- После получения уточнений от пользователя
3. 🔄 AdaptPlan
- Когда требуется адаптация исследовательского подхода
- При обнаружении неточностей в первоначальных предположениях
4. 🔍 WebSearch
- Когда нужна дополнительная информация И searches_done < 3
- МАКСИМУМ 3-4 поиска на исследование
5. 📄 CreateReport
- При searches_done >= 2 ИЛИ enough_data = True
- Когда собрана информация для полного анализа
6. ✅ ReportCompletion
- После создания отчета
- Финализация исследования
Соответствие концепту SGR верифицировало Ринатом 😂
Предлагайте ваши эксперименты! Вон даже ребята из Cбера подключились!
Forwarded from Тимлид Очевидность | Евгений Антонов
Быстро о мотивации и задачах
Недавно смотрел пару докладов, которые можно гармонично совместить в простую схему мотивации относительно выдаваемых людям задач. Легко взять на вооружение начинающим тимлидам. Как всегда, пишу об этом только потому, что видел примеры, когда такое не делается и люди сильно приунывают от этого, руки у них опускаются, а сами они становятся понурыми и безучастными.
Мысль №1
В докладе Анны Обуховой про то, как выглядят проявления власти и авторитета https://www.youtube.com/watch?v=BmxfUvG7jAY я услышал про эксперимент с крысами. Альфу и омежку посадили в одну клетку и омежка даже не пыталась рыпнуться, сразу отдав всё влияние альфе. Потом омежку несколько раз сажали с другими омежками, где она в бою побеждала их (так они разбираются, кто здесь власть), а после этого посадили опять к альфе. И омежка, уже поверив в себя, готова была с альфой зарубиться.
Мысль №2
В одном из видео Миши Токовинина услышал хорошую, но коротко сформулированную мысль, что сложно (или невозможно) какими-то уговорами и волшебными вдохновляющими словами людей мотивировать на выполнение задач. Надо просто давать им не слишком легкие задачи, чтобы они не заскучали, и не слишком сложные, чтобы они в них не уперлись, как в непреодолимое препятствие, и не решили, что они ничтожества недостойные.
Комбинируем
Задачи не слишком легкие. Например, одного моего знакомого, хорошего разработчика, наняли и бездумно давали ему вечные багфиксы. В итоге он через несколько месяцев такой работы ушел.
Задачи не слишком сложные. Как-то на заре моей карьеры в разработке мне досталась не то, что задача, а целый проект. Да еще с нуля, да еще я неопытный, да еще никто не декомпозировал ничего, да еще никто не приглядывал и не помогал. Я оооочень сильно приуныл за два-три месяца барахтанья во всём этом.
Вспоминаем крыс и понимаем, что люди эти задачи будут не просто выполнять, но и поднимать свою мотивацию, видеть, что они молодцы, у них получается, не закрывать, не бежать и не отнекиваться, получат позитивное подкрепление. Со временем они будут получать задачи посложнее, но всё равно смело их выполнять. Так будут профессионально расти и не грустить.
Не всегда есть выбор
Иной раз не всегда есть выбор для каждого члена команды таких задач. Иногда может быть оверсложная задача и её кому-то надо отдать. Или пучок легких проблем, которые надо зарешать. Здесь я могу тимлидам только посоветовать держать руку на пульсе и соблюдать баланс.
Нагрузили кого-то сложнотой, дайте потом чего-то попроще поделать, чтобы получить дофаминчика поскорее и наоборот. Кажется, всё просто, но вот и со мной случай я описал и с другими видел, когда тимлиды не смотрят, как люди гаснут под грузом демотивирующих задач.
Ну и каждому могу, как всегда, посоветовать быть самому кузнецом своего счастья. Говорить, что не так, обсуждать, придумывать пути решения. Сам о себе не позаботишься – только хороший руководитель позаботится (а таких мало).
Итог
Можете показать этот пост начинающим тимлидам, которые увязли в куче разных теорий про мотивацию. Кластеризуют людей по Герчикову, потом еще красят по DISC’у, а сверху обмазывают Минцбергом с Герцбергом.
Можно начать с того, чтобы следить за балансом, чтобы в среднем люди получали задачи не слишком легкие, не слишком сложные и подкрепляли уверенность в своих силах на этих победах.
Недавно смотрел пару докладов, которые можно гармонично совместить в простую схему мотивации относительно выдаваемых людям задач. Легко взять на вооружение начинающим тимлидам. Как всегда, пишу об этом только потому, что видел примеры, когда такое не делается и люди сильно приунывают от этого, руки у них опускаются, а сами они становятся понурыми и безучастными.
Мысль №1
В докладе Анны Обуховой про то, как выглядят проявления власти и авторитета https://www.youtube.com/watch?v=BmxfUvG7jAY я услышал про эксперимент с крысами. Альфу и омежку посадили в одну клетку и омежка даже не пыталась рыпнуться, сразу отдав всё влияние альфе. Потом омежку несколько раз сажали с другими омежками, где она в бою побеждала их (так они разбираются, кто здесь власть), а после этого посадили опять к альфе. И омежка, уже поверив в себя, готова была с альфой зарубиться.
Мысль №2
В одном из видео Миши Токовинина услышал хорошую, но коротко сформулированную мысль, что сложно (или невозможно) какими-то уговорами и волшебными вдохновляющими словами людей мотивировать на выполнение задач. Надо просто давать им не слишком легкие задачи, чтобы они не заскучали, и не слишком сложные, чтобы они в них не уперлись, как в непреодолимое препятствие, и не решили, что они ничтожества недостойные.
Комбинируем
Задачи не слишком легкие. Например, одного моего знакомого, хорошего разработчика, наняли и бездумно давали ему вечные багфиксы. В итоге он через несколько месяцев такой работы ушел.
Задачи не слишком сложные. Как-то на заре моей карьеры в разработке мне досталась не то, что задача, а целый проект. Да еще с нуля, да еще я неопытный, да еще никто не декомпозировал ничего, да еще никто не приглядывал и не помогал. Я оооочень сильно приуныл за два-три месяца барахтанья во всём этом.
Вспоминаем крыс и понимаем, что люди эти задачи будут не просто выполнять, но и поднимать свою мотивацию, видеть, что они молодцы, у них получается, не закрывать, не бежать и не отнекиваться, получат позитивное подкрепление. Со временем они будут получать задачи посложнее, но всё равно смело их выполнять. Так будут профессионально расти и не грустить.
Не всегда есть выбор
Иной раз не всегда есть выбор для каждого члена команды таких задач. Иногда может быть оверсложная задача и её кому-то надо отдать. Или пучок легких проблем, которые надо зарешать. Здесь я могу тимлидам только посоветовать держать руку на пульсе и соблюдать баланс.
Нагрузили кого-то сложнотой, дайте потом чего-то попроще поделать, чтобы получить дофаминчика поскорее и наоборот. Кажется, всё просто, но вот и со мной случай я описал и с другими видел, когда тимлиды не смотрят, как люди гаснут под грузом демотивирующих задач.
Ну и каждому могу, как всегда, посоветовать быть самому кузнецом своего счастья. Говорить, что не так, обсуждать, придумывать пути решения. Сам о себе не позаботишься – только хороший руководитель позаботится (а таких мало).
Итог
Можете показать этот пост начинающим тимлидам, которые увязли в куче разных теорий про мотивацию. Кластеризуют людей по Герчикову, потом еще красят по DISC’у, а сверху обмазывают Минцбергом с Герцбергом.
Можно начать с того, чтобы следить за балансом, чтобы в среднем люди получали задачи не слишком легкие, не слишком сложные и подкрепляли уверенность в своих силах на этих победах.
Forwarded from Не AБы какие тесты
Привет, товарищи-статистики!
На днях Дима Лунин из Авито выпустил свою 5-ую статью на хабре (с чем и поздравим!) по базе AB: "Методичка по AB-тестированию от аналитиков Авито". И когда пишет такой специалист как Дима, то прочитать стоит вне зависимости от того, база это или нет, так как, возможно, какие-то очень хорошо знакомые понятия предстанут вам под другим углом, такие углы ищу и я, корректируя и уточняя формулировки для курса.
Со своей стороны оставил ряд комментариев к статье (и не только к ней, кстати!), думаю, они могут быть полезны.
Читать комментарии к статье от Димы
P.S. В пятницу ждите пост про новый поток по AB, пора, мои товарищи, пора!
На днях Дима Лунин из Авито выпустил свою 5-ую статью на хабре (с чем и поздравим!) по базе AB: "Методичка по AB-тестированию от аналитиков Авито". И когда пишет такой специалист как Дима, то прочитать стоит вне зависимости от того, база это или нет, так как, возможно, какие-то очень хорошо знакомые понятия предстанут вам под другим углом, такие углы ищу и я, корректируя и уточняя формулировки для курса.
Со своей стороны оставил ряд комментариев к статье (и не только к ней, кстати!), думаю, они могут быть полезны.
Читать комментарии к статье от Димы
P.S. В пятницу ждите пост про новый поток по AB, пора, мои товарищи, пора!
Telegraph
Комментарии по механике AB-тестирования от Авито
1.Почему чаще всего сравниваем средние? Мне очень понравилось объяснение, почему чтобы определить, приносит ли больше денег наша фича, достаточно сравнить математические ожидания наших выборок A и B. А ведь для бизнеса это может быть неочевидно! Действительно…
Forwarded from Dimension AI | Dmitry Sirakov
Почему SGR в агентных задачах - плохая идея?
Ринат в последнее время пишет про SGR и его применение в агентных задачах. Про сам SGR подробнее можно посмотреть здесь.
TL;DR: SGR — частный случай Structured Output, где перед финальным ответом задаются «поля», которые позволяют вести LLM более контролируемо к нужной области ответа, а затем, учитывая пункты, которые она написала «выше», LLM формирует финальный ответ (или выполняет действие, которое также жёстко задано JSON-схемой).
В чём вообще отличие? Если и SGR, и Tools приводят к JSON для вызова тула?
Кажется, результат должен быть одинаковым — и в SGR мы даже можем что-то дополнительно контролировать. Звучит супер!
Как LLM пишет ответ в случае SGR (например, для тулзы)?
LLM генерирует ответ; отдельный бэкенд (например, xgrammar) выступает в роли конечного автомата: читает переданную схему, строит грамматику и «не даёт» LLM писать токены, не соответствующие схеме.
В знаменитом
Не видите подвоха?
1) В chat-template поле tools пустое (даже если LLM поддерживает tools).
2) LLM пишет какой-то JSON, а в ответ ей прилетает следующее сообщение с ролью tool (хотя тулов у LLM «нет» — они не были явно переданы через tools).
Следствие.
LLM пишет JSON, а в ответ получает результат тула. Если посмотреть на известные бенчмарки по tool calling, такого поведения вообще не ожидается: модели обычно обучаются и оцениваются в сценариях, где доступные инструменты передаются явно, а вызов идёт через структурированное поле function/tool-calls.
Представляете, что происходит в голове у LLM, когда подобных диалогов нет ни в открытых датасетах, ни в референсных туториалах провайдеров: даже семантика вызова tools теряется. В чат-истории внезапно появляются «инструменты», хотя их не передавали через tools, и «вызов» сделан абстрактным JSON в content, а не через нативное поле tool_calls. Официальные гайды OpenAI/Anthropic учат обратному: передайте список tools в шаблон, модель выберет нужную функцию и сформирует аргументы в структурированном поле; не вызывайте того, чего нет в tools.
Как работает TOOLS?
Tools - это поле, которое подмешивается в chat-template. На этапе SFT/RL модель учится работать именно с таким протоколом: не вызывать то, чего нет, и вызывать то, что доступно. Это зафиксировано и в провайдерских практиках (OpenAI/Anthropic), и в академических/ресерчерских наборах для оценки агентости (When2Call (NVIDIA)
Модель не должна пользоваться тулами, если их не передали в tools. Какие tools передали — такими и пользуется.
«Но мы же теряем reasoning и отладку?»
Нет, не теряем. Никто не запрещает первыми аргументами (по аналогии с SGR) сделать поля в функции — «reasoning», ключевые «якоря» и т. п. За счёт этого вы получаете:
1) более нативное использование инструментов (внутри официального протокола tool-calling),
2) более прозрачную историю сообщений,
3) более стабильную систему.
Да, здесь reasoning идёт в аргументы функции (которых может быть много), а не в выборе нужной функции. Но даже крупные компании не рекомендуют засовывать слишком много функций в один промпт — если модель «теряется», лучше декомпозировать систему/поправить промпты, а не «эмулировать» tool-calls через SGR.
Ради эксперимента можете измерить перплексию на диалогах с параллельными вызовами тулов в форматах SGR vs Tools и посмотреть, какой формат «интуитивнее» для модели.
Чуть с более другой стороны объяснил Валера Ковальский, подробнее тут
Ринат в последнее время пишет про SGR и его применение в агентных задачах. Про сам SGR подробнее можно посмотреть здесь.
TL;DR: SGR — частный случай Structured Output, где перед финальным ответом задаются «поля», которые позволяют вести LLM более контролируемо к нужной области ответа, а затем, учитывая пункты, которые она написала «выше», LLM формирует финальный ответ (или выполняет действие, которое также жёстко задано JSON-схемой).
В чём вообще отличие? Если и SGR, и Tools приводят к JSON для вызова тула?
Кажется, результат должен быть одинаковым — и в SGR мы даже можем что-то дополнительно контролировать. Звучит супер!
Как LLM пишет ответ в случае SGR (например, для тулзы)?
LLM генерирует ответ; отдельный бэкенд (например, xgrammar) выступает в роли конечного автомата: читает переданную схему, строит грамматику и «не даёт» LLM писать токены, не соответствующие схеме.
В знаменитом
chat.completions() нам вернётся сообщение вида {role: 'assistant', content: '<JSON-строка>', tool_calls: []}; потом мы парсим content и подкладываем в историю сообщение вида {role: 'tool', content: '<результат тула>'}. Я намеренно опустил пару деталей для наглядности, но в общих чертах так оно и выглядит.Не видите подвоха?
1) В chat-template поле tools пустое (даже если LLM поддерживает tools).
2) LLM пишет какой-то JSON, а в ответ ей прилетает следующее сообщение с ролью tool (хотя тулов у LLM «нет» — они не были явно переданы через tools).
Следствие.
LLM пишет JSON, а в ответ получает результат тула. Если посмотреть на известные бенчмарки по tool calling, такого поведения вообще не ожидается: модели обычно обучаются и оцениваются в сценариях, где доступные инструменты передаются явно, а вызов идёт через структурированное поле function/tool-calls.
Представляете, что происходит в голове у LLM, когда подобных диалогов нет ни в открытых датасетах, ни в референсных туториалах провайдеров: даже семантика вызова tools теряется. В чат-истории внезапно появляются «инструменты», хотя их не передавали через tools, и «вызов» сделан абстрактным JSON в content, а не через нативное поле tool_calls. Официальные гайды OpenAI/Anthropic учат обратному: передайте список tools в шаблон, модель выберет нужную функцию и сформирует аргументы в структурированном поле; не вызывайте того, чего нет в tools.
Как работает TOOLS?
Tools - это поле, которое подмешивается в chat-template. На этапе SFT/RL модель учится работать именно с таким протоколом: не вызывать то, чего нет, и вызывать то, что доступно. Это зафиксировано и в провайдерских практиках (OpenAI/Anthropic), и в академических/ресерчерских наборах для оценки агентости (When2Call (NVIDIA)
tool hallucination rate тому пример внутри бенча, BFCL/Gorilla включает специальную категорию Function Relevance Detection: когда ни один из переданных тулов не подходит - модель должна не делать call. Есть и Chatting Capability: вообще без переданных тулов, проверяется, что модель пишет ответ как чат-бот, не вызывая функции).Модель не должна пользоваться тулами, если их не передали в tools. Какие tools передали — такими и пользуется.
«Но мы же теряем reasoning и отладку?»
Нет, не теряем. Никто не запрещает первыми аргументами (по аналогии с SGR) сделать поля в функции — «reasoning», ключевые «якоря» и т. п. За счёт этого вы получаете:
1) более нативное использование инструментов (внутри официального протокола tool-calling),
2) более прозрачную историю сообщений,
3) более стабильную систему.
Да, здесь reasoning идёт в аргументы функции (которых может быть много), а не в выборе нужной функции. Но даже крупные компании не рекомендуют засовывать слишком много функций в один промпт — если модель «теряется», лучше декомпозировать систему/поправить промпты, а не «эмулировать» tool-calls через SGR.
Ради эксперимента можете измерить перплексию на диалогах с параллельными вызовами тулов в форматах SGR vs Tools и посмотреть, какой формат «интуитивнее» для модели.
Чуть с более другой стороны объяснил Валера Ковальский, подробнее тут
Forwarded from Pavel Zloi
img2md.rpa.icu
img2md VLM OCR
img2md VLM OCR - AI-powered document analysis and text extraction with layout preservation
Про OCR при помощи VLM
Опубликовал свой новый проект img2md-vlm-ocr, в нём я экспериментирую с использованием Vision-Language моделей (VLM) в роли OCR-движка.
На идею меня подтолкнули публикации Валерия Ковальского (раз, два) про распознавание текста с картинок при помощи сегментатора YOLOv8 заточенного под документы и VLM модели qwen2.5vl (7b, так как 72b дюже большая) запущенной на моей домашней ollama в качестве OCR.
Что умеет система:
- Можно закинуть одну или несколько картинок.
- Система выделяет bounding box при помощи сегментатора и достаёт текст через OCR.
- Вырезает отдельные куски если это не текст, а картинка или график.
- Возвращает результат в формате Markdown.
- Можно скачать итог в виде ZIP-архива (вырезки + распознанный текст).
Где посмотреть:
- Сервис: https://img2md.rpa.icu/
- API-документация: https://img2md.rpa.icu/docs/
- Репозиторий: https://github.com/EvilFreelancer/img2md-vlm-ocr
Дополнительно:
В проекте есть скрипты на Python, которые позволяют массово обрабатывать PDF-файлы и автоматически сшивать полученные Markdown воедино. Это удобно, если нужно конвертировать целые документы и получить структурированный текстовый результат.
PS. Буду рад обратной связи!
Опубликовал свой новый проект img2md-vlm-ocr, в нём я экспериментирую с использованием Vision-Language моделей (VLM) в роли OCR-движка.
На идею меня подтолкнули публикации Валерия Ковальского (раз, два) про распознавание текста с картинок при помощи сегментатора YOLOv8 заточенного под документы и VLM модели qwen2.5vl (7b, так как 72b дюже большая) запущенной на моей домашней ollama в качестве OCR.
Что умеет система:
- Можно закинуть одну или несколько картинок.
- Система выделяет bounding box при помощи сегментатора и достаёт текст через OCR.
- Вырезает отдельные куски если это не текст, а картинка или график.
- Возвращает результат в формате Markdown.
- Можно скачать итог в виде ZIP-архива (вырезки + распознанный текст).
Где посмотреть:
- Сервис: https://img2md.rpa.icu/
- API-документация: https://img2md.rpa.icu/docs/
- Репозиторий: https://github.com/EvilFreelancer/img2md-vlm-ocr
Дополнительно:
В проекте есть скрипты на Python, которые позволяют массово обрабатывать PDF-файлы и автоматически сшивать полученные Markdown воедино. Это удобно, если нужно конвертировать целые документы и получить структурированный текстовый результат.
PS. Буду рад обратной связи!
Forwarded from Young&&Yandex
Перед тем как приступить к тренировкам, захвати свой стартовый пакет. Внутри — полезные материалы:
ML:
🔘 Прошлые запуски: первые (основы), вторые (NLP), третьи (CV), а также текстовые разборы некоторых лекций🔘 Заметки Евгения Соколова с курса Машинного обучения на ФКН ВШЭ🔘 Блог Александра Дьяконова «Анализ малых данных»🔘 Учебник по ML от ШАД Яндекса🔘 Книга Mathematics for Machine Learning🔘 Сайт по RL от одного из сотрудников OpenAI
Алгоритмы:
1. Тестирование
Теория: https://youtube.com/live/c67zB3FWLOs
Практика:https://contest.yandex.ru/contest/66792
2. Множества и словари
Теория: https://youtube.com/live/jQOnYzW8ZOE?feature=share
Практика: https://contest.yandex.ru/contest/59541
3. Одномерное динамическое программирование
Теория: https://www.youtube.com/watch?v=H7lu6h8H9-4
Практика: https://contest.yandex.ru/contest/45469/enter/ и https://contest.yandex.ru/contest/45468/enter/
4. Двумерное динамическое программирование
Теория: https://www.youtube.com/live/U8gzm92fprI
Практика: https://contest.yandex.ru/contest/45469/enter/ и https://contest.yandex.ru/contest/45468/enter/
5. Деревья
Теория: https://youtube.com/live/O9ffppQ05-c?feature=share
Практика: https://contest.yandex.ru/contest/66795
6. Бинарный поиск
Теория: https://youtube.com/live/-B6xvDeGyPg?feature=share
Практика: https://contest.yandex.ru/contest/59542
7. Префиксные суммы, два указателя
Теория: https://youtube.com/live/B4uP6igiVNU?feature=share
Практика: https://contest.yandex.ru/contest/66793
8. Сортировка событий
Теория: https://www.youtube.com/watch?v=hGixDBO-p6Q&t=1s
Практика:https://contest.yandex.ru/contest/27883/enter/
Старт совсем скоро: yandex.ru/yaintern/training
Подписывайся
@Young_and_Yandex
Please open Telegram to view this post
VIEW IN TELEGRAM