#llm #petproject

Hybrid: SGR + Tools - закрываем дыры, не ломая протокол

После горячих обсуждений и двух предыдущих постов (пост 1, пост 2) я решил показать рабочий гибридный паттерн и сделать вклад в опенсорс-подход к SGR (линк в конце поста).

TLDR пост1 и пост2: SGR пишет ответ через «поля» и якоря [благодаря чему, приводит к более предсказуемым и верным ответам], но в чистом виде легко размывает семантику tool-calling (если мы ее задействуем): в истории появляются вызовы инструментов, которых не было в объявленном наборе и не передались в чат-темплейт, а если неаккуратно обрабатывать вызовы - нас ждёт еще больше проблем. И всё это расходится с практиками провайдеров и публичными бенчмарками по агентости.

Что я сделал:
Я вынес рассуждение в отдельный инструмент generate_reasoning и заставляю модель вызывать его принудительно сразу после любого пользовательского сообщения с помощью управления tool_choice. Внутри reasoning используется SGR: цель, план, ограничения, проверка предпосылок, сигналы о том, нужно ли звать инструменты и какие именно. Далее "агент", опираясь на получившееся рассуждение, вызывает только те функции, которые явно объявлены в tools, строго через нативный механизм вызовов.

Ключевые свойства подхода:
1. Никакого «динамического tools из воздуха». Всё, чем пользуется модель, заранее объявлено; в истории нет инструментов, которых нет в tools. Контроль с помощью tool_choice.
2. История сообщений валидна и читаема: отдельно видно этап рассуждения и отдельно - действия и финальный ответ.
3. Совместимость с практиками провайдеров и бенчами: снижается риск tool-hallucination, корректнее проходит проверка релевантности функций.
4. Контроль внимания вместо хаоса: сначала гарантированное рассуждение, потом действия. Это делает маршрутизацию детерминированной и устойчивой. Тк много трейновых датасетов, как и в каких ситуациях вызывать тулы, мы используем очень много компьюта в свою пользу: не только будущая корректная оценка цепочек ризонинга (для метрик), но и адаптивный выбор тулов.

Почему это устойчивее, чем «SGR-only»:
- Нативные tool_calls, а не эмуляция вызовов через content (да, можно этого избежать, подкладывая вызов SGRв tool_calls, но не решается следующий пункт:
- Меньше неожиданностей для модели: нет сценария «ответил JSON -> внезапно прилетел tool», когда tools пусты.
- Проще поддерживать качество: reasoning становится обычным шагом workflow. Его вообще можно вынести на значительно более мощные модели или наоборот, более слабые. Позволяет нам давать больше контроля.

Получается стабильный и интерпретируемый паттерн: чат-темплейт согласован с историей, вызовы инструментов не идут «против шерсти», а модель ведёт себя предсказуемо.

Рекомендую попробовать гибрид SGR + Tools на своих задачках

линк на код

поддержите реакциями ❤️

#python #courses #novice

#llm #code #petproject

#llm #petproject

📖 В конце рабочей недели этот пост попадёт вам в самое сердечко, потому что вокруг так много интересного, а сил и времени всё это почитать уже нет, правда? 🌚

🧚 NotebookLM и Нейроэксперт
Эти инструменты помогут вам не сойти с ума в следующих ситуациях:
1. у вас в руках pdf-документ на десятки страниц, а вы даже не знаете, есть ли в нём полезное для вас;
2. несколько статей на тему, в которую надо срочно погрузиться;
3. микс из статей, pdf, копипастов текста (а если брать NotebookLM, то прибавьте к этому Google Drive и ролики с YouTube) -- чтоб разобраться в теме максимально основательно!

Как это работает:
- Грузите нужные вам данные в эти инструменты (оба работают на вебе и бесплатные, но как обычно в мире GPT -- есть лимиты, проконсультируйтесь с тарифами). NDA не грузите;
- Получаете саммари документов, чтобы понять о чём речь;
- Чатитесь с загруженными документами: если данных в документе есть, то вы получите ответ на свой вопрос со ссылкой на конкретный абзац, чтобы всё проверить, а если нет, то сервис так про это и скажет.

Отдельно круто то, что:
- закинуть данные вы можете на английском, а задавать вопросы и получать ответы -- на русском;
- если в документе картинки с графиками или табличками, LLM их тоже "прочитает" и сможет использовать для ответов.

Плюсы и минусы вариантов:
📘 NotebookLM сильно фукнциональнее. Например, он может сделать майндмеп контента, квиз по контенту или флэш-карточки для заучивания. Есть инстурументы для подкастеров и видео-блоггеров, но я у мамы не могу быть ими всеми, так что обзора не будет 🙂
Минусы: 1) плохо доступен из России без VPN... 2) ответы пишет тяжеловатым языком.

📕 Нейроэксперт пока попроще, без квизов и майндмепов, но хорошо справляется с базовым -- ответить на вопросы по документам, чтобы сэкономить ваше время. И прекрасно доступен из России. А ещё он как-то очень легко и понятно пишет ответы.
Минусы: пока невозможность попасть в нужное место исходного документа по ссылке, есть только цитата. Иногда не хватает контекста для правильного понимания.

Лайфхак для жизни:
- закидываете в такой сервис договор с банком и просите перечисли всё, что в нём плохо для вас, как для клиента;
- ура, вы знаете всё, что от вас пытались скрыть сноски, звездочки, мелкий шрифт и канцелярский язык.

#ab #analytics

Почему статистика в науке в среднем сложнее

В прошлом посте я писала, что в индустрии A/B тестеров в основном используются t-тесты и z-тесты конверсий. Понятно, что и здесь хватает нюансов: проблема SRM, ratio-метрик, снижение дисперсии через CUPED, а еще можно пойти в сторону causal inference, но это совсем отдельная история. В целом методология сравнительно проста, как правило, дизайн ограничен одним фактором и двумя группами.

При этом данных много (иногда очень много), эксперименты идут на десятках тысяч пользователей, и ЦПТ работает. Поэтому применяются относительно простые статистические методы: t-тесты, z-тесты (при необходимости с поправками на множественное тестирование, чаще всего используется Бонферрони), продвинутым разделом считается CUPED (вариация на тему ANCOVA). Этот набор уже закрывает ~90% стандартных A/B тестов. Основная сложность здесь не в математике, а в понимании метрик и продукта, работе с некачественными данными и в согласовании процессов с разработкой.

В академических исследованиях все иначе. Дизайн эксперимента часто многомерный: исследуется влияние сразу нескольких факторов и их взаимодействий. При этом выборки нередко маленькие, и центральная предельная теорема может не работать. Поэтому простого t-теста обычно недостаточно (а даже в простых дизайнах ученые часто применяют тест Манна–Уитни).

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

Что касается поправок на множественное тестирование, в науке применяются разные подходы, от пост хок тестов в сложных дизайнах до расчета FDR при работе с транскриптомными данными. В аналитике же обычно ничего сложнее Бонферрони и не требуется, иногда применяют поправку Холма, а FDR вообще противопоказан, на мой взгляд, так как решает другую задачу (почему так, можно почитать в разборе поправок).

Поэтому ученому, который привык к более сложной статистике, сравнительно легко перейти в продуктовую аналитику: статистический бэкграунд обычно выше того, что требуется в индустрии, а многие модные аналитические термины на деле оказываются лишь переименованными или упрощёнными версиями давно известных методов 😏

#stats #analytics