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 ей не понятен и просит его расшифровать

Что я закинул туда "навайбкодил"

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бера подключились!

Быстро о мотивации и задачах

Недавно смотрел пару докладов, которые можно гармонично совместить в простую схему мотивации относительно выдаваемых людям задач. Легко взять на вооружение начинающим тимлидам. Как всегда, пишу об этом только потому, что видел примеры, когда такое не делается и люди сильно приунывают от этого, руки у них опускаются, а сами они становятся понурыми и безучастными.

Мысль №1
В докладе Анны Обуховой про то, как выглядят проявления власти и авторитета https://www.youtube.com/watch?v=BmxfUvG7jAY я услышал про эксперимент с крысами. Альфу и омежку посадили в одну клетку и омежка даже не пыталась рыпнуться, сразу отдав всё влияние альфе. Потом омежку несколько раз сажали с другими омежками, где она в бою побеждала их (так они разбираются, кто здесь власть), а после этого посадили опять к альфе. И омежка, уже поверив в себя, готова была с альфой зарубиться.

Мысль №2
В одном из видео Миши Токовинина услышал хорошую, но коротко сформулированную мысль, что сложно (или невозможно) какими-то уговорами и волшебными вдохновляющими словами людей мотивировать на выполнение задач. Надо просто давать им не слишком легкие задачи, чтобы они не заскучали, и не слишком сложные, чтобы они в них не уперлись, как в непреодолимое препятствие, и не решили, что они ничтожества недостойные.

Комбинируем
Задачи не слишком легкие. Например, одного моего знакомого, хорошего разработчика, наняли и бездумно давали ему вечные багфиксы. В итоге он через несколько месяцев такой работы ушел.

Задачи не слишком сложные. Как-то на заре моей карьеры в разработке мне досталась не то, что задача, а целый проект. Да еще с нуля, да еще я неопытный, да еще никто не декомпозировал ничего, да еще никто не приглядывал и не помогал. Я оооочень сильно приуныл за два-три месяца барахтанья во всём этом.

Вспоминаем крыс и понимаем, что люди эти задачи будут не просто выполнять, но и поднимать свою мотивацию, видеть, что они молодцы, у них получается, не закрывать, не бежать и не отнекиваться, получат позитивное подкрепление. Со временем они будут получать задачи посложнее, но всё равно смело их выполнять. Так будут профессионально расти и не грустить.

Не всегда есть выбор
Иной раз не всегда есть выбор для каждого члена команды таких задач. Иногда может быть оверсложная задача и её кому-то надо отдать. Или пучок легких проблем, которые надо зарешать. Здесь я могу тимлидам только посоветовать держать руку на пульсе и соблюдать баланс.

Нагрузили кого-то сложнотой, дайте потом чего-то попроще поделать, чтобы получить дофаминчика поскорее и наоборот. Кажется, всё просто, но вот и со мной случай я описал и с другими видел, когда тимлиды не смотрят, как люди гаснут под грузом демотивирующих задач.

Ну и каждому могу, как всегда, посоветовать быть самому кузнецом своего счастья. Говорить, что не так, обсуждать, придумывать пути решения. Сам о себе не позаботишься – только хороший руководитель позаботится (а таких мало).

Итог
Можете показать этот пост начинающим тимлидам, которые увязли в куче разных теорий про мотивацию. Кластеризуют людей по Герчикову, потом еще красят по DISC’у, а сверху обмазывают Минцбергом с Герцбергом.
Можно начать с того, чтобы следить за балансом, чтобы в среднем люди получали задачи не слишком легкие, не слишком сложные и подкрепляли уверенность в своих силах на этих победах.

Привет, товарищи-статистики!

На днях Дима Лунин из Авито выпустил свою 5-ую статью на хабре (с чем и поздравим!) по базе AB: "Методичка по AB-тестированию от аналитиков Авито". И когда пишет такой специалист как Дима, то прочитать стоит вне зависимости от того, база это или нет, так как, возможно, какие-то очень хорошо знакомые понятия предстанут вам под другим углом, такие углы ищу и я, корректируя и уточняя формулировки для курса.

Со своей стороны оставил ряд комментариев к статье (и не только к ней, кстати!), думаю, они могут быть полезны.

Читать комментарии к статье от Димы

P.S. В пятницу ждите пост про новый поток по AB, пора, мои товарищи, пора!

#llm #ml #systemdesign

Почему SGR в агентных задачах - плохая идея?

Ринат в последнее время пишет про 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 и посмотреть, какой формат «интуитивнее» для модели.

Чуть с более другой стороны объяснил Валера Ковальский, подробнее тут

#llm #petproject

#ml #algo #courses

#llm #code

Почему LLM без Alignment — это риск?

Обучение на миллиардах токенов даёт языковой модели грамотность, но не гарантирует адекватность. Без Alignment она может:

📌 выдавать логически неверные ответы,
📌 генерировать небезопасный контент,
📌 игнорировать бизнес-ограничения.

Что такое Alignment? Это дообучение с учётом предпочтений и ограничений, которое делает модель предсказуемой и управляемой.
Написали статью на Хабр, в которой разбираем:

📝 Методы Alignment: от PPO (Proximal Policy Optimization) до новых подходов DPO и KTO.
📝 Наш опыт: как мы в Точка Банк настроили LLM под конкретные сценарии, обучили модель наград и сократили затраты по сравнению с классическим RLHF.
📝 Грабли и лайфхаки: как работать с несбалансированным датасетом и не дать модели обмануть функцию награды.
📝 Где применять Alignment за пределами LLM: от cost-sensitive классификации до vision-language моделей.

Точно будет полезно, если строите собственную LLM — читайте и задавайте вопросы в комментариях!

#systemdesign #courses

https://www.youtube.com/@ByteMonk/playlists

#dl #courses

#dl #cv #courses