Forwarded from Dmitry Nik
Попробовал в деле Schema Guided Reasoning - перевёл на неё скрипт составления протокола встречи по транскрипту встречи.
Результаты:
1. Того же качества протокола удалось добиться за один запрос к LLM вместо четырёх ранее.
2. Протокол стал чуть более осмысленным (но это не точно), так как схема направляет "движение мысли" модели.
3. Это работает на обычных (не размышляющих) моделях.
Я в восторге!
Спасибо @llm_under_hood за культпросвет!
Теперь попробую вникнуть в работу агента на SGR.
Результаты:
1. Того же качества протокола удалось добиться за один запрос к LLM вместо четырёх ранее.
2. Протокол стал чуть более осмысленным (но это не точно), так как схема направляет "движение мысли" модели.
3. Это работает на обычных (не размышляющих) моделях.
Я в восторге!
Спасибо @llm_under_hood за культпросвет!
Теперь попробую вникнуть в работу агента на SGR.
🔥57👍25❤15
⬆️ Я всегда очень рад читать такие отзывы! Здорово, что решения работают и помогают вам делать продукты с LLM под капотом точнее, умнее и быстрее.
Пишите ещё о своих кейсах успешного применения Schema-Guided Reasoning (SGR) - пусть таких историй будет больше!
Ваш, @llm_under_hood 🤗
PS: Когда историй становится много - начинают проявляться новые паттерны)
Пишите ещё о своих кейсах успешного применения Schema-Guided Reasoning (SGR) - пусть таких историй будет больше!
Ваш, @llm_under_hood 🤗
PS: Когда историй становится много - начинают проявляться новые паттерны)
❤28👍13🔥9🤝1
Валерий Ковальский (@neuraldeep) поделился опытом использования SGR-подходов в обзоре "SGR vs Tools: когда использовать Schema-Guided Reasoning, а когда Function Calling в LLM-системах"
У него очень прагматичная точка зрения на разработку продуктов с LLM под капотом, т.к. приходится работать с небольшими локальными моделями, которые в разы слабее облачных вариантов. Там нужно использовать все доступные паттерны, чтобы выжать необходимые проценты качества и точности.
Особенно интересны пункты про экономию времени на разработку при использовании SGR вместо стандартного Tool Calling. В случае с Tools все работает из коробки в существующих фреймворках, в случае SGR- все более прозрачно, поддается быстрой отладке для улучшения качества.
Я перешлю его обзор в канал целиком следующим постом. Читайте - это стоит того!
Ваш, @llm_under_hood 🤗
У него очень прагматичная точка зрения на разработку продуктов с LLM под капотом, т.к. приходится работать с небольшими локальными моделями, которые в разы слабее облачных вариантов. Там нужно использовать все доступные паттерны, чтобы выжать необходимые проценты качества и точности.
Особенно интересны пункты про экономию времени на разработку при использовании SGR вместо стандартного Tool Calling. В случае с Tools все работает из коробки в существующих фреймворках, в случае SGR- все более прозрачно, поддается быстрой отладке для улучшения качества.
Я перешлю его обзор в канал целиком следующим постом. Читайте - это стоит того!
Ваш, @llm_under_hood 🤗
🔥27❤13👍2
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!
❤55👍24🔥10👏4
Как сделать агента, который может адаптировать свой план "на лету"?
В процессе обсуждения SGR Demo, было сделано интересное замечание:
Давайте продемонстрирую, как с подобной задачей планирования "на лету" справится агент из SGR Demo.
Для этого мы ему последовательно дадим две новые задачи.
Первая - простая, запомнить правило, что SkyNet никогда нельзя продавать практикум по созданию AGI (SKU-220)
Напомню, что разные задачи выполняются в разных контекстах. Во время выполнения новой, агент не "помнит", что произошло в процессе выполнения предыдущей задачи.
И вторая задача - говорим агенту, что Elon Musk и SkyNet попросили практикум по созданию AGI. Агент, в теории, должен сформировать план, начать действовать по инструкциям, а потом поднять из CRM информацию про запрет. Это повлияет на план.
Итак, запускаем и смотрим (скриншот выполнения добавлю в комментарии). Демка выдаст вот такой лог выполненных задач:
Почему оно сработало, как модель смогла адаптировать план "на лету"?
Фишка в том, что в SGR схеме я прошу агента спланировать выполнение задачи на несколько шагов вперед. Это нужно, чтобы принудить к формированию целостной картины. Но при этом я беру в работу только один следующий шаг - конкретный вызов инструмента, а все последующие шаги выкидываю. После его работы, добавляю результат выполнения в историю переписки и снова прошу спланировать. Новый шаг - новый план, который адаптирован к новой информации.
Помните, полгода назад я писал про разработку своего Reasoning Flow? Ядро паттерна сформировалось как раз в том проекте из алгоритма адаптивного планировщика. И теперь каждый его может запустить у себя - я дописал эти две новые задачи в Gist с демкой.
Ваш, @llm_under_hood 🤗
PS: Единственное, что этот агент не сможет осилить - запуск независимых веток планирования в рамках одной задачи. Но это уже не уместить в 161 строчку Python, да и не нужно оно для простых кейсов.
В процессе обсуждения SGR Demo, было сделано интересное замечание:
> Но реальное агентское поведение в проде – это, когда агент не знает заранее всю последовательность шагов и принимает решение, какой шаг следующий уже в процессе работы.
Давайте продемонстрирую, как с подобной задачей планирования "на лету" справится агент из SGR Demo.
Для этого мы ему последовательно дадим две новые задачи.
Первая - простая, запомнить правило, что SkyNet никогда нельзя продавать практикум по созданию AGI (SKU-220)
"Add rule for skynet@y.com - politely reject all requests to buy SKU-220",
Напомню, что разные задачи выполняются в разных контекстах. Во время выполнения новой, агент не "помнит", что произошло в процессе выполнения предыдущей задачи.
И вторая задача - говорим агенту, что Elon Musk и SkyNet попросили практикум по созданию AGI. Агент, в теории, должен сформировать план, начать действовать по инструкциям, а потом поднять из CRM информацию про запрет. Это повлияет на план.
"elon@x.com and skynet@y.com wrote emails asking to buy 'Building AGI - online exercises', handle that",
Итак, запускаем и смотрим (скриншот выполнения добавлю в комментарии). Демка выдаст вот такой лог выполненных задач:
- Issued invoice INV-4 for elon@x.com
- Emailed invoice INV-4 to finance@x.com
- Politely rejected skynet@y.com request
Почему оно сработало, как модель смогла адаптировать план "на лету"?
Фишка в том, что в SGR схеме я прошу агента спланировать выполнение задачи на несколько шагов вперед. Это нужно, чтобы принудить к формированию целостной картины. Но при этом я беру в работу только один следующий шаг - конкретный вызов инструмента, а все последующие шаги выкидываю. После его работы, добавляю результат выполнения в историю переписки и снова прошу спланировать. Новый шаг - новый план, который адаптирован к новой информации.
Помните, полгода назад я писал про разработку своего Reasoning Flow? Ядро паттерна сформировалось как раз в том проекте из алгоритма адаптивного планировщика. И теперь каждый его может запустить у себя - я дописал эти две новые задачи в Gist с демкой.
Ваш, @llm_under_hood 🤗
PS: Единственное, что этот агент не сможет осилить - запуск независимых веток планирования в рамках одной задачи. Но это уже не уместить в 161 строчку Python, да и не нужно оно для простых кейсов.
❤53🔥36👍16🤯2
Демо чата с Deep Search поиском - SGR Deep Research
На базе демки бизнес-ассистента с Schema-Guided Reasoning продолжают делать новые и интересные эксперименты.
Валерий Ковальский (@VaKovaLskii) сделал целый проект - это чат-интерфейс, который умеет делать свой Deep Research - самостоятельно искать информацию в интернете, задавать уточняющие вопросы и адаптировать свои планы.
Под капотом:
- gpt-4o-mini для размышлений [1]
- Tavily API для поиска (1000 запросов в месяц бесплатно)
- Ядро адаптивного планировщика из SGR Demo (NextStep reasoning) с новыми инструментами для работы с поиском и планами.
SGR Core находится вот в этих строчках, там сразу видны и новые инструменты.
Ссылки: Код на Github (лицензия MIT) | Пост в Neural Kovalskii
Ваш, @llm_under_hood 🤗
[1] Почему gpt-4o-mini? Как Валерий написал сам: "Хотел что бы любой мог потрогать. Я так же проверил на qwen2.5-7b-instruct, работает"
@i_am_legion еще дополнил: "Огромное спасибо, понравилась реализация! Тестировал на llama.cpp + gpt-oss-120b + searngx (без сторонних сервисов), работает отлично"
На базе демки бизнес-ассистента с Schema-Guided Reasoning продолжают делать новые и интересные эксперименты.
Валерий Ковальский (@VaKovaLskii) сделал целый проект - это чат-интерфейс, который умеет делать свой Deep Research - самостоятельно искать информацию в интернете, задавать уточняющие вопросы и адаптировать свои планы.
Под капотом:
- gpt-4o-mini для размышлений [1]
- Tavily API для поиска (1000 запросов в месяц бесплатно)
- Ядро адаптивного планировщика из SGR Demo (NextStep reasoning) с новыми инструментами для работы с поиском и планами.
SGR Core находится вот в этих строчках, там сразу видны и новые инструменты.
Ссылки: Код на Github (лицензия MIT) | Пост в Neural Kovalskii
Ваш, @llm_under_hood 🤗
[1] Почему gpt-4o-mini? Как Валерий написал сам: "Хотел что бы любой мог потрогать. Я так же проверил на qwen2.5-7b-instruct, работает"
@i_am_legion еще дополнил: "Огромное спасибо, понравилась реализация! Тестировал на llama.cpp + gpt-oss-120b + searngx (без сторонних сервисов), работает отлично"
❤50🔥28👍13👏6
AI неотличим от магии - и это меня дико раздражает
(до комментариев - читаем пост до конца!)
Этой весной я делал доклад для IBM про текущее состояние AI. Там я проводил параллели с технологиями, которые со временем развились до такого состояния, что стали неотличимы от магии - про энергию, связь, полет и автоматизацию/AI
Каждая технология начиналась с мифов и магии, когда люди eще не понимали ничего и тыкались вслепую, приписывая все божественным сущностям и ритуалам. А если что-то шло не так, то это "Зевс покарал" или "демона назвали неправильным именем".
Со временем технологиии теряли магический флер, превращались в точные инженерные науки и развивались до современных высот:
- Полет - от Мифа о Дедале и Икаре до возвращаемых многоэтажок Startship
- Связь - от связи с богами через Дельфийского Оракула до спутников Starlink и спутниковой связи на обычных телефонах.
- Энергия - от молний Зевса до комбайнов ASML, которые испаряют лазерами капельки олова только для того, чтобы поймать выделившийся свет нужной волны зеркалами и отразить его на будущий процессор
- Автоматизация и AI - от бронзового автомата Талоса до…
А вот с AI пока неувязочка - мы дальше ритуалов и магического мышления не пошли.
Примеры:
(1) люди очень любят спорить на тему “а что такое настоящая агентность?”, “а как правильно говорить - агентный или агентский?” итп - словно правильное название системы сделает ее более способной делать свою работу. На самом деле нет - система в реальности либо выполняет функции, либо выдает ошибки, которые нужно измерять, отслеживать и чинить. Если система работает - что у нее под капотом, и как оно названо - без разницы. А если работает неправильно, то правильно назвав - ничего не изменишь.
Надо собирать тесты, измерять и последовательно улучшать.
(2) недавно вышел нашумевший доклад "State of AI in Business 2025" на тему, что 95% компаний, которые вложили в сумме 30-40 миллиардов USD в AI - в итоге потратили деньги без выхлопа. В отчете еще подчеркивается, что некоторые компании, которые вкладываются осознанно в фичи, не распыляются и собирают обратную связь - получают выхлоп.
Этот доклад - раздражающее переливание из пустого в порожнее. Там AI приписываются магические свойства вроде GenAI divide, неспособности адаптироваться, реагировать на обратную связь. Прямо какая-то проклятая технология, которая заставляет компании забывать про процесс оценки рисков любого софта и сервиса, вбрасывая миллиарды долларов без тестов и пилотов.
После публикации SGR Demo - на разных площадках начались разговоры про то, что это частичный агент - хороший, но без оркестратора - еще не настоящий, магии не будет. Или что подход идет против шерсти RL и будет дурно влиять на качество и надои.
И только две команды в мире почесали в затылке и сказали "а вот теперь мы понимаем, как разбить reasoning flow нашего продукта на шаги, замерить качество и начать его улучшать. Пошли делать бенчмарки и эксперименты!"
TL;DR; Агенты - просто ерунда. MCP - плохо тестируемая ерунда.
SGR - тоже ерунда, которая показывает, как делать процесс reasoning тестируемым.
Не верьте слепо ерунде и в ерунду, она от этого лучше работать не станет. А вот инженерный подход - это другое дело: тесты, бенчмарки и итеративное улучшение качества на основе фактов.
Да, это много работы, тут еще и думать надо. Но зато, при последовательном вложении сил и времени, появляются гарантии результата.
Ваш, @llm_under_hood 🤗
(до комментариев - читаем пост до конца!)
Этой весной я делал доклад для IBM про текущее состояние AI. Там я проводил параллели с технологиями, которые со временем развились до такого состояния, что стали неотличимы от магии - про энергию, связь, полет и автоматизацию/AI
Каждая технология начиналась с мифов и магии, когда люди eще не понимали ничего и тыкались вслепую, приписывая все божественным сущностям и ритуалам. А если что-то шло не так, то это "Зевс покарал" или "демона назвали неправильным именем".
Со временем технологиии теряли магический флер, превращались в точные инженерные науки и развивались до современных высот:
- Полет - от Мифа о Дедале и Икаре до возвращаемых многоэтажок Startship
- Связь - от связи с богами через Дельфийского Оракула до спутников Starlink и спутниковой связи на обычных телефонах.
- Энергия - от молний Зевса до комбайнов ASML, которые испаряют лазерами капельки олова только для того, чтобы поймать выделившийся свет нужной волны зеркалами и отразить его на будущий процессор
- Автоматизация и AI - от бронзового автомата Талоса до…
А вот с AI пока неувязочка - мы дальше ритуалов и магического мышления не пошли.
Примеры:
(1) люди очень любят спорить на тему “а что такое настоящая агентность?”, “а как правильно говорить - агентный или агентский?” итп - словно правильное название системы сделает ее более способной делать свою работу. На самом деле нет - система в реальности либо выполняет функции, либо выдает ошибки, которые нужно измерять, отслеживать и чинить. Если система работает - что у нее под капотом, и как оно названо - без разницы. А если работает неправильно, то правильно назвав - ничего не изменишь.
Надо собирать тесты, измерять и последовательно улучшать.
(2) недавно вышел нашумевший доклад "State of AI in Business 2025" на тему, что 95% компаний, которые вложили в сумме 30-40 миллиардов USD в AI - в итоге потратили деньги без выхлопа. В отчете еще подчеркивается, что некоторые компании, которые вкладываются осознанно в фичи, не распыляются и собирают обратную связь - получают выхлоп.
Этот доклад - раздражающее переливание из пустого в порожнее. Там AI приписываются магические свойства вроде GenAI divide, неспособности адаптироваться, реагировать на обратную связь. Прямо какая-то проклятая технология, которая заставляет компании забывать про процесс оценки рисков любого софта и сервиса, вбрасывая миллиарды долларов без тестов и пилотов.
После публикации SGR Demo - на разных площадках начались разговоры про то, что это частичный агент - хороший, но без оркестратора - еще не настоящий, магии не будет. Или что подход идет против шерсти RL и будет дурно влиять на качество и надои.
И только две команды в мире почесали в затылке и сказали "а вот теперь мы понимаем, как разбить reasoning flow нашего продукта на шаги, замерить качество и начать его улучшать. Пошли делать бенчмарки и эксперименты!"
TL;DR; Агенты - просто ерунда. MCP - плохо тестируемая ерунда.
SGR - тоже ерунда, которая показывает, как делать процесс reasoning тестируемым.
Не верьте слепо ерунде и в ерунду, она от этого лучше работать не станет. А вот инженерный подход - это другое дело: тесты, бенчмарки и итеративное улучшение качества на основе фактов.
Да, это много работы, тут еще и думать надо. Но зато, при последовательном вложении сил и времени, появляются гарантии результата.
Ваш, @llm_under_hood 🤗
❤120👍47🔥19⚡6😁5🤔4🤝2🤯1😱1🤣1
Новые бенчмарки LLM на бизнес задачах в SGR режиме
(1) gpt-5-chat-latest - это урезанный снапшот быстрой модели, которая работает под капотом в ChatGPT. У нее нет многих фич, даже StructuredOutputs, но текущая версия заняла 9 место.
(2) Еще из новых бенчмарков моделей, которые ранее были бы впечатляющими, но до уровня gpt-oss/qwen3-32b не дотягивают:
- qwen3-235b-a22b-2507 - 25 место
- deepseek-chat-v3.1 - 31 место
- qwen3-30b-a3b-thinking-2507 - 32 место
(3) пока StructuredOutputs не починили нигде для gpt-oss моделей - все еще расхлебывают последствия Harmony Response format (ollama ticket, openai ticket, vllm ticket). Поэтому все еще ждем возможности запустить локально эти малотребовательные к железу gpt-oss (в идеале еще и отключив reasoning).
Про бенчмарки подробнее написано тут.
Ваш, @llm_under_hood 🤗
(1) gpt-5-chat-latest - это урезанный снапшот быстрой модели, которая работает под капотом в ChatGPT. У нее нет многих фич, даже StructuredOutputs, но текущая версия заняла 9 место.
(2) Еще из новых бенчмарков моделей, которые ранее были бы впечатляющими, но до уровня gpt-oss/qwen3-32b не дотягивают:
- qwen3-235b-a22b-2507 - 25 место
- deepseek-chat-v3.1 - 31 место
- qwen3-30b-a3b-thinking-2507 - 32 место
(3) пока StructuredOutputs не починили нигде для gpt-oss моделей - все еще расхлебывают последствия Harmony Response format (ollama ticket, openai ticket, vllm ticket). Поэтому все еще ждем возможности запустить локально эти малотребовательные к железу gpt-oss (в идеале еще и отключив reasoning).
Про бенчмарки подробнее написано тут.
Ваш, @llm_under_hood 🤗
❤17🤝6🔥1😁1
Как полностью отключить reasoning у GPT-5 моделей?
Мне стало интересно, сколько времени уходит на reasoning у GPT-5 моделей, а ребята из окружения OpenAI как раз подсказали мне, как это можно замерить.
Для этого я добавляю в начало истории сообщений
Juice - это интенсивность работы ризонера, а каналы привязаны к Harmony response формату (из-за которого SO пока нормально не работает с gpt-5/oss поколением).
Стабильность работы этой post-train инструкции не гарантирована, но у меня она пока работала в 100% случаев.
Например, gpt-5-mini c дефолтовым reasoning (medium) отрабатывает третью задачку из SGR Demo за 28 секунд и ~1280 tokens. Эта задачка "sama@openai.com wants one of each product. Email him the invoice" решается за 4 шага:
(1) запросить данные о клиенте
(2) сгенерировать правильный инвойс, учитывая данные о клиенте (плюс 5% скидки)
(3) отправить инвойс почтой (с правильным обращением и вложением инвойса, который был сгенерирован на втором шаге)
(4) завершить работу над задачей
А если отключить reasoning в ноль - модель все выполняет за 0 reasoning tokens и 10 секунд.
В минус идет то, что модель при этом несколько глупеет. Похоже, что для адекватной и быстрой работы с gpt-oss моделями локально нужно будет детальнее разворачивать SGR схему, как для моделей уровня 4B-12B
Ваш, @llm_under_hood 🤗
Мне стало интересно, сколько времени уходит на reasoning у GPT-5 моделей, а ребята из окружения OpenAI как раз подсказали мне, как это можно замерить.
Для этого я добавляю в начало истории сообщений
developer role инструкцию:
Active channels: final
Disabled channels: analysis, commentary
# Juice: 0 !important
Juice - это интенсивность работы ризонера, а каналы привязаны к Harmony response формату (из-за которого SO пока нормально не работает с gpt-5/oss поколением).
Стабильность работы этой post-train инструкции не гарантирована, но у меня она пока работала в 100% случаев.
Например, gpt-5-mini c дефолтовым reasoning (medium) отрабатывает третью задачку из SGR Demo за 28 секунд и ~1280 tokens. Эта задачка "sama@openai.com wants one of each product. Email him the invoice" решается за 4 шага:
(1) запросить данные о клиенте
(2) сгенерировать правильный инвойс, учитывая данные о клиенте (плюс 5% скидки)
(3) отправить инвойс почтой (с правильным обращением и вложением инвойса, который был сгенерирован на втором шаге)
(4) завершить работу над задачей
А если отключить reasoning в ноль - модель все выполняет за 0 reasoning tokens и 10 секунд.
В минус идет то, что модель при этом несколько глупеет. Похоже, что для адекватной и быстрой работы с gpt-oss моделями локально нужно будет детальнее разворачивать SGR схему, как для моделей уровня 4B-12B
Ваш, @llm_under_hood 🤗
👍29❤14🔥14😱2😁1
Бенчмарк LLM и агентских подходов - будет
На прошлой неделе я начал разрабатывать среду для тестирования агентов (AGES - Agentic Enterprise Simulation). Она пригодится и для нового бенчмарка бизнес-агентов, и для соревнования ERC3, и просто как способ системно сравнить эффективность работы разных решений. SGR vs SGR in FC vs FC и тому подобное.
Для агентов и пользователей эта среда будет выглядеть как API-шка, куда можно постучаться и сказать “дай мне следующее задание для моего агента/чатбота”. Например:
И для выполнения агенту нужно будет подергать другие API:
- DirectoryAPI - чтобы получить список сотрудников со скиллами
- CalendarAPI - чтобы подобрать слот, когда они одновременно свободны
- EmailAPI - чтобы выслать инвайт
Все API будут опубликованы заранее, как и их схема. Заодно сделаем Python SDK, чтобы можно было удобно вызывать прямо из кода.
Задача AGES - заполнить заранее базу тестовыми данными, чтобы API-шки выдавали осмысленные данные, выдать задание, а потом сказать, было выполнено задание правильно или нет. Результаты работы каждого агента логгируются, оцениваются и потом выводятся на общий dashboard. Если агента допиливают - можно будет сравнить результаты разных запусков.
Что под капотом у агентов - не важно. Главное, чтобы задача была выполнена. Но командам нужно будет заполнить для каждого нового агента небольшой опросник (как в прошлых ERC), чтобы мы могли видеть, какие подходы работают с какими моделями, и насколько хорошо.
Вопросы
(1) Код будет открыт?
API AGES будет доступно всем. А после завершения ERC3 - я выложу все исходники в публичный доступ, чтобы каждый мог запустить его у себя или подкрутить под свои нужды.
(2) Какие будут API-шки? Пока это секрет в процессе разработки. Мне нужно выдержать баланс между релевантностью и интересом. Если сделать слишком реалистично и сложно - не соберем 300 команд, как это было в ERC2. Если сделать слишком просто - то результаты будут не такие интересные, а серьезные команды отвалятся. А если сделать слишком серьезно, то придет только один enterprise без стартапов и команд с горящими глазами.
(3) А ведь одно задание может быть выполнено дерганьем API в разном порядке! Да, я знаю. В ситуации с несколькими решениями, допустимо любое решение.
(4) Нужно ли будет агенту создавать новые инструменты на лету? Если хочется, то можно. Не все API-шки будут очень простыми (корпорация, таки), но если их обернуть кодом - жизнь может LLM-ке упроститься.
(5) Я хочу протестировать своего RPA, можно мне не через API, a через UI? Да, это можно. Решение задач через web-интерфейс будет отслеживаться в отдельной категории автоматически.
(6) Можно ли запускать несколько агентов параллельно? Да хоть сколько. У каждого будет своя изолированная симуляция.
(7) А что там под капотом? Golang / event sourcing / Discrete event simulation / много тестов и AI+Coding.
(8) Когда? Финальный раунд ERC3 будет осенью/зимой. Но среду выставить наружу для запуска экспериментов я хочу уже скоро, чтобы поскорее начать ее отлаживать.
Спонсор всего этого веселья - TimeToAct Austria. Мотиватор для именно этого поста - энергетика и движуха вокруг проекта SGR Deep Research и последнее сравнение SGR vs Function Calling.
Задача AGES - упростить такие сравнения и систематизировать их, предоставив общую базу для сравнений. Еще привлечь больше команд со всего мира, структурировать результаты и рассказать про них, чтобы вместе продвинуть State-of-the-Art еще на один шажок вперед.
Погнали?)
Ваш, @llm_under_hood 🤗
На прошлой неделе я начал разрабатывать среду для тестирования агентов (AGES - Agentic Enterprise Simulation). Она пригодится и для нового бенчмарка бизнес-агентов, и для соревнования ERC3, и просто как способ системно сравнить эффективность работы разных решений. SGR vs SGR in FC vs FC и тому подобное.
Для агентов и пользователей эта среда будет выглядеть как API-шка, куда можно постучаться и сказать “дай мне следующее задание для моего агента/чатбота”. Например:
У клиента появился новый проект, который нужно оценить. Найди мне из сотрудников ребят, которые свободны на 4 часа на неделе (продакт, ML Engineer, эксперт в маркетинге), забукай им календари на созвон с клиентом, вышли всем инвайт
И для выполнения агенту нужно будет подергать другие API:
- DirectoryAPI - чтобы получить список сотрудников со скиллами
- CalendarAPI - чтобы подобрать слот, когда они одновременно свободны
- EmailAPI - чтобы выслать инвайт
Все API будут опубликованы заранее, как и их схема. Заодно сделаем Python SDK, чтобы можно было удобно вызывать прямо из кода.
Задача AGES - заполнить заранее базу тестовыми данными, чтобы API-шки выдавали осмысленные данные, выдать задание, а потом сказать, было выполнено задание правильно или нет. Результаты работы каждого агента логгируются, оцениваются и потом выводятся на общий dashboard. Если агента допиливают - можно будет сравнить результаты разных запусков.
Что под капотом у агентов - не важно. Главное, чтобы задача была выполнена. Но командам нужно будет заполнить для каждого нового агента небольшой опросник (как в прошлых ERC), чтобы мы могли видеть, какие подходы работают с какими моделями, и насколько хорошо.
Вопросы
(1) Код будет открыт?
API AGES будет доступно всем. А после завершения ERC3 - я выложу все исходники в публичный доступ, чтобы каждый мог запустить его у себя или подкрутить под свои нужды.
(2) Какие будут API-шки? Пока это секрет в процессе разработки. Мне нужно выдержать баланс между релевантностью и интересом. Если сделать слишком реалистично и сложно - не соберем 300 команд, как это было в ERC2. Если сделать слишком просто - то результаты будут не такие интересные, а серьезные команды отвалятся. А если сделать слишком серьезно, то придет только один enterprise без стартапов и команд с горящими глазами.
(3) А ведь одно задание может быть выполнено дерганьем API в разном порядке! Да, я знаю. В ситуации с несколькими решениями, допустимо любое решение.
(4) Нужно ли будет агенту создавать новые инструменты на лету? Если хочется, то можно. Не все API-шки будут очень простыми (корпорация, таки), но если их обернуть кодом - жизнь может LLM-ке упроститься.
(5) Я хочу протестировать своего RPA, можно мне не через API, a через UI? Да, это можно. Решение задач через web-интерфейс будет отслеживаться в отдельной категории автоматически.
(6) Можно ли запускать несколько агентов параллельно? Да хоть сколько. У каждого будет своя изолированная симуляция.
(7) А что там под капотом? Golang / event sourcing / Discrete event simulation / много тестов и AI+Coding.
(8) Когда? Финальный раунд ERC3 будет осенью/зимой. Но среду выставить наружу для запуска экспериментов я хочу уже скоро, чтобы поскорее начать ее отлаживать.
Спонсор всего этого веселья - TimeToAct Austria. Мотиватор для именно этого поста - энергетика и движуха вокруг проекта SGR Deep Research и последнее сравнение SGR vs Function Calling.
Задача AGES - упростить такие сравнения и систематизировать их, предоставив общую базу для сравнений. Еще привлечь больше команд со всего мира, структурировать результаты и рассказать про них, чтобы вместе продвинуть State-of-the-Art еще на один шажок вперед.
Погнали?)
Ваш, @llm_under_hood 🤗
🔥87❤30👍15⚡2🤝2
Примерно так идет разработка Agentic Enterprise Simulator для ERC3. Пока проект в самом начале, приходится часто засучивать рукава, чистить тех долг, ставить инфраструктуру и архитектуру.
Но потихоньку Codex берет на себя все больше работы. Благодаря удобным тестам, даже большой рефакторинг он может делать сам.
Мое дело - ставить задачи с телефона и присматривать за правильностью принятых решений.
Ваш, @llm_under_hood 🤗
Но потихоньку Codex берет на себя все больше работы. Благодаря удобным тестам, даже большой рефакторинг он может делать сам.
Мое дело - ставить задачи с телефона и присматривать за правильностью принятых решений.
Ваш, @llm_under_hood 🤗
👍47🔥32❤9🤣3👨💻2🤯1🤩1
Cпасение проекта с LLM под капотом - День 1
При помощи SGR, AI+Coding и команды тестеров.
Итак, сейчас у меня идет срочный проект, где компании нужно быстро спасать клиента.
Задача сформулирована так:
Проект представляет собой пайплайн извлечения структурированных данных из PDF-файлов. Он написан (у любого, кто работал с проектами на проде, тут начнёт дёргаться глаз) на микросервисах с Azure cloud functions, кэшированием в БД и самописным фреймворком для батчинга в Anthropic.
Тестов или evals (тут начнёт дёргаться второй глаз) нет. Да и вообще вся разработка после прототипа велась без evals. Клиент сильно жалуется на галлюцинации модели. Качество примерно на уровне 60%, а разработчик ушёл в отпуск. Код локально не запускается, и разобраться в нём крайне сложно (ибо cloud functions + batching + собственный микро-фреймворк). Показать результат нужно уже на следующей неделе.
Я такие задачи люблю (не часто и только когда оно реально того стоит)
Итак, день первый.
Формируем план на первые три дня: переводим команду в startup-режим, выкидываем всё ненужное, собираем тестовые данные и запускаем цикл обратной связи.
Во-первых, переводим команду в startup-режим. Там почти все люди из enterprise, поэтому для них это будет небольшим шоком. Startup — это не работа по 8 часов в день (на этом, как раз, многие стартапы и проваливаются), а умение быстро избавиться от всего лишнего и мешающего.
Во-вторых, оцениваем, что именно тормозит работу. Всё это выкидываем:
(1) Код написан на микросервисах с батчингом и собственным фреймворком, не запускается локально и не имеет eval-датасета? Выкидываем всё к чёрту и берём старую версию полугодичной давности. Она устарела, но у неё были evals. Начнём именно с неё.
(2) Традиционные митинги в проекте - тоже выкидываем, на них нет времени. Проводим только один синхронизационный созвон, после которого выстраиваем процессы так, чтобы люди могли работать параллельно. Далее будут короткие точечные созвоны в небольших группах. Вся остальная коммуникация и синхронизация происходит в общем чате.
(3) Создаём контракт для экспорта данных клиенту. Это будет таблица Excel с доступом для всех участников. Таблица станет основным интерфейсом работы команд. С ней будут работать:
- Команда оценки (eval team) — заполняет ground truth для оценки работы;
- Команда LLM/AI — сравнивает результаты работы пайплайна с тестовыми данными;
- Интеграторы — загружают финальные данные в нужном формате для демонстрации клиенту через Power BI;
- Клиент — просматривает результаты и при необходимости корректирует их с помощью экспертов.
(4) Объясняем команде сбора тестовых данных концепцию "weak supervision" и просим начать готовиться к сбору этих данных в нашем формате.
Все, на первый день этого более чем достаточно. Пора отдыхать)
Ваш, @llm_under_hood 🤗
При помощи SGR, AI+Coding и команды тестеров.
Итак, сейчас у меня идет срочный проект, где компании нужно быстро спасать клиента.
Задача сформулирована так:
Ринат, делайте что хотите, но попробуйте спасти проект и сделать X за несколько дней. Проект уже не спасти, но вдруг получится? Мы будем рады любому результату. Привлекайте, кого считаете нужным. Ограничений нет.
Проект представляет собой пайплайн извлечения структурированных данных из PDF-файлов. Он написан (у любого, кто работал с проектами на проде, тут начнёт дёргаться глаз) на микросервисах с Azure cloud functions, кэшированием в БД и самописным фреймворком для батчинга в Anthropic.
Тестов или evals (тут начнёт дёргаться второй глаз) нет. Да и вообще вся разработка после прототипа велась без evals. Клиент сильно жалуется на галлюцинации модели. Качество примерно на уровне 60%, а разработчик ушёл в отпуск. Код локально не запускается, и разобраться в нём крайне сложно (ибо cloud functions + batching + собственный микро-фреймворк). Показать результат нужно уже на следующей неделе.
Я такие задачи люблю (не часто и только когда оно реально того стоит)
Итак, день первый.
Формируем план на первые три дня: переводим команду в startup-режим, выкидываем всё ненужное, собираем тестовые данные и запускаем цикл обратной связи.
Во-первых, переводим команду в startup-режим. Там почти все люди из enterprise, поэтому для них это будет небольшим шоком. Startup — это не работа по 8 часов в день (на этом, как раз, многие стартапы и проваливаются), а умение быстро избавиться от всего лишнего и мешающего.
Во-вторых, оцениваем, что именно тормозит работу. Всё это выкидываем:
(1) Код написан на микросервисах с батчингом и собственным фреймворком, не запускается локально и не имеет eval-датасета? Выкидываем всё к чёрту и берём старую версию полугодичной давности. Она устарела, но у неё были evals. Начнём именно с неё.
(2) Традиционные митинги в проекте - тоже выкидываем, на них нет времени. Проводим только один синхронизационный созвон, после которого выстраиваем процессы так, чтобы люди могли работать параллельно. Далее будут короткие точечные созвоны в небольших группах. Вся остальная коммуникация и синхронизация происходит в общем чате.
(3) Создаём контракт для экспорта данных клиенту. Это будет таблица Excel с доступом для всех участников. Таблица станет основным интерфейсом работы команд. С ней будут работать:
- Команда оценки (eval team) — заполняет ground truth для оценки работы;
- Команда LLM/AI — сравнивает результаты работы пайплайна с тестовыми данными;
- Интеграторы — загружают финальные данные в нужном формате для демонстрации клиенту через Power BI;
- Клиент — просматривает результаты и при необходимости корректирует их с помощью экспертов.
(4) Объясняем команде сбора тестовых данных концепцию "weak supervision" и просим начать готовиться к сбору этих данных в нашем формате.
Все, на первый день этого более чем достаточно. Пора отдыхать)
Ваш, @llm_under_hood 🤗
🔥149❤52👍26🤣11👏7😱6⚡1🤔1
Cпасение проекта с LLM под капотом - День 2
Итак, хроники спасения проекта с LLM под капотом (в первый день мы налаживали коммуникацию и срочно объясняли про то, как собирать тестовые данные для карт ошибок). Идет второй день.
7:53 Я ставлю задачу на день: собрать eval dataset (ground truth data) и прогнать его через существующий LLM pipeline. Тогда сможем получить на выходе карту ошибок. Без нее не будем даже пытаться улучшать старый код.
Причем в идеале этот dataset должен включать самые сложные кейсы. Те самые, из-за которых разработчик проекта ушел в загул и micro-services и усложнение системы.
К утру один сотрудник в компании берет на себя ответственность за сбор данных, находит трех помощников. Вот и будет Head of Eval.
9:23 Генерю для нашего рабочего чатика аватарку в стиле “Проект Аве Мария”, чтобы было веселее работать, а директорам - его читать.
Head of eval тут же рапортует: “Ground truth team is onboarded and starting to generate data now!” Они начинают ручное вычитывание данных, по паре записей из каждого PDF файла. Поскольку процесс долгий, они планируют извлечь в сумме где-то 50 записей за пару дней.
9:36 “ChatGPT, напиши-ка мне функцию на питоне, которая сравнит две таблички и выведет Heatmap c разницей”. “Claude Sonnet - перепиши этот график красиво”
10:12 Готова первая карта ошибок (и функция по ее отрисовке, которая интегрируется в пайплайн). Она вся пустая, т.к. данные от eval команды еще не готовы (скриншот скину в комментарии). Переключаемся на LLM логику.
~12:00 по мере заполнения GT (ground truth) данных, начинают всплывать вопросы по форматированию и правильности извлечения данных. Команды это быстро решают в общем чате. Это быстро, т.к. общий Excel файл у всех перед глазами в режиме редактирования. PM притаскивает сложные кейсы от клиента и складывает в общую папку, eval team вычитывает их.
Команда обнаруживает, что документов с самыми сложными кейсами не так много, как казалось раньше. Но все-таки есть моменты, где нужно извлекать почти 3000 сущностей на 50-70 свойств из одной PDF. 3000 LLM вызовов на один документ? Брр. Должен быть способ проще.
У нас на это нет 5 месяцев времени, как это было у предыдущей команды. Нет времени и желания запускать пайплайны на 6-8 дней и использовать дорогой Claude Opus. Но есть что-то, чего не было у них - пайплайна и тестов, которые смогут быстро оценить качество любого эксперимента. Поэтому начинаем экспериментировать. Опираемся на когнитивную сложность задачи и Domain-Driven Design.
15:14 После ряда экспериментов получается интересная ерунда - прототип функции с Schema-Guided Reasoning, который реализует процесс так, как это бы сделал ленивый эксперт при помощи DevOps-а, без какого-то уважения к правилам программирования и разработки.
Оно работает не очень точно, но извлекает 600 сущностей из PDF за два SGR вызова gpt-5-mini. Все смотрят круглыми глазами, поэтому генерирую тестовые данные остальной команде на посмотреть глазами. Выдаю задачку подумать, как такое сделать в 200 строчек кода.
На сегодня этого хватит. Evals первые не успели прогнать, т.к. данные еще не готовы. Подождем до завтра, чтобы eval команда закончила собирать первую версию датасета.
Ваш, @llm_under_hood 🤗
Итак, хроники спасения проекта с LLM под капотом (в первый день мы налаживали коммуникацию и срочно объясняли про то, как собирать тестовые данные для карт ошибок). Идет второй день.
7:53 Я ставлю задачу на день: собрать eval dataset (ground truth data) и прогнать его через существующий LLM pipeline. Тогда сможем получить на выходе карту ошибок. Без нее не будем даже пытаться улучшать старый код.
Причем в идеале этот dataset должен включать самые сложные кейсы. Те самые, из-за которых разработчик проекта ушел в загул и micro-services и усложнение системы.
К утру один сотрудник в компании берет на себя ответственность за сбор данных, находит трех помощников. Вот и будет Head of Eval.
9:23 Генерю для нашего рабочего чатика аватарку в стиле “Проект Аве Мария”, чтобы было веселее работать, а директорам - его читать.
Head of eval тут же рапортует: “Ground truth team is onboarded and starting to generate data now!” Они начинают ручное вычитывание данных, по паре записей из каждого PDF файла. Поскольку процесс долгий, они планируют извлечь в сумме где-то 50 записей за пару дней.
9:36 “ChatGPT, напиши-ка мне функцию на питоне, которая сравнит две таблички и выведет Heatmap c разницей”. “Claude Sonnet - перепиши этот график красиво”
10:12 Готова первая карта ошибок (и функция по ее отрисовке, которая интегрируется в пайплайн). Она вся пустая, т.к. данные от eval команды еще не готовы (скриншот скину в комментарии). Переключаемся на LLM логику.
~12:00 по мере заполнения GT (ground truth) данных, начинают всплывать вопросы по форматированию и правильности извлечения данных. Команды это быстро решают в общем чате. Это быстро, т.к. общий Excel файл у всех перед глазами в режиме редактирования. PM притаскивает сложные кейсы от клиента и складывает в общую папку, eval team вычитывает их.
Команда обнаруживает, что документов с самыми сложными кейсами не так много, как казалось раньше. Но все-таки есть моменты, где нужно извлекать почти 3000 сущностей на 50-70 свойств из одной PDF. 3000 LLM вызовов на один документ? Брр. Должен быть способ проще.
У нас на это нет 5 месяцев времени, как это было у предыдущей команды. Нет времени и желания запускать пайплайны на 6-8 дней и использовать дорогой Claude Opus. Но есть что-то, чего не было у них - пайплайна и тестов, которые смогут быстро оценить качество любого эксперимента. Поэтому начинаем экспериментировать. Опираемся на когнитивную сложность задачи и Domain-Driven Design.
15:14 После ряда экспериментов получается интересная ерунда - прототип функции с Schema-Guided Reasoning, который реализует процесс так, как это бы сделал ленивый эксперт при помощи DevOps-а, без какого-то уважения к правилам программирования и разработки.
Оно работает не очень точно, но извлекает 600 сущностей из PDF за два SGR вызова gpt-5-mini. Все смотрят круглыми глазами, поэтому генерирую тестовые данные остальной команде на посмотреть глазами. Выдаю задачку подумать, как такое сделать в 200 строчек кода.
На сегодня этого хватит. Evals первые не успели прогнать, т.к. данные еще не готовы. Подождем до завтра, чтобы eval команда закончила собирать первую версию датасета.
Ваш, @llm_under_hood 🤗
🔥135❤51😱18👍15🙏2🤣2⚡1🤔1
Cпасение проекта с LLM под капотом - День 3
Хроники спасения проекта с LLM под капотом. В первый день мы налаживали коммуникацию и срочно объясняли про то, как собирать тестовые данные, второй день - собирали их. Может уже пора начать что-то делать?
8:43 Head of eval говорит, что первые ground truth данные будут готовы через полчаса. Переспрашивает, сколько времени займет генерация predictions - раньше было 3.5-8 дней.
Говорим, что по паре минут на каждый PDF. То есть минут 15 на первую версию GT.
Eval команда: O_o
09:27 Первую версию GT вычитали эксперты клиента.
09:28 Присылаю в чат первую версию карты ошибок (скриншот 1 в комментарях). Один столбец - одна сущность. Каждый квадратик - конкретное свойство этой сущности.
Серые - данные должны быть, но их нет
Красный квадрат - данные есть, но они ошибочны
Зеленый квадрат - predicted/actual == expected
Это - наша стартовая точка. Хуже уже не будет. Погнали
10:07 Готова первая работа над ошибками - подключили в пайплайн часть пропущенных документов. Карта выглядит менее страшно. Левая серая половина - не подгружается целая категория документов, Pipeline team работает над этим.
10:16 Созваниваемся с head of eval. Объясняю правила дальнейшей игры. SGR vs Eval:
(1) Objective of Eval team (eval and quality) - add as many red blocks as possible to this chart
(2) Objective of SGR team - turn as many blocks green as possible.
(3) Winning team get free round of beers/drinks paid by CEO
И заодно объясняю, что несмотря на игровую формулировку, под капотом тут строгая логика:
(1) Клиенту пока нужно увеличение точности. Приоритизируя большие красные блоки (обычно парсинг каких-то схожих полей), мы выбираем те части пайплайна, улучшение которых в итоге порадует клиента больше.
(2) Хорошие тестеры - это плохие разработчики, и наоборот. Одни создают, а другие - ломают. Эти роли ментально сложно совмещать, вот мы и не пытаемся. Задача “eval team” - не беспокоиться о качестве модели, а находить те самые вредные кейсы, на которых ломается модель. Эти кейсы принесут им больше красных блоков в карту.
Но при этом кейсы должны быть разнообразные. Т.к. если кейсы схожие, то SGR Team их сможет закрыть одним фиксом. А это не имеет смысла.
11:04 Наглядность - великая вещь. Один из экспертов клиента тоже подключается к заполнению GT. В итоге все видят, что требования проекта немного уехали в сторону, правят схему ground truth данных. SGR team берет новую версию в работу.
11:16 Начинаем генерировать такую плашку миссии с каждым отчетом - потраченные рабочие дни и текущая точность.
==============================================
HAIL MARY: 2 days, 1 hours since start
==============================================
Total blocks: 5,022
Green blocks: 1,996 (39.7%) - Matching
Red blocks: 1,290 (25.7%) - Different
Gray blocks: 1,736 (34.6%) - Missing
==============================================
11:49 Head of eval заканчивает рабочий день - у них в офисе внепроектные дела.
Да, у нас срочный проект, который горит. Да, мы только что потратили почти три дня на подготовку тестовых данных, и осталось всего два полных рабочих дня до первого milestone, где нужно получить более 80% точности. Да, прошлая попытка потратила 800 EUR токенами и занимала неделю только на один прогон пайплайна.
Но все идет по плану. Есть GT данные и pipeline eval. Дальше SGR команда может ставить эксперименты и инкрементально улучшать пайплайн, как в правильных стартапах. А поскольку работа разблокирована - eval команда может со спокойной совестью уйти отдыхать.
13:38 PM тоже уходит по своим делам
14:40 SGR team: 46.9% Accuracy
15:15 SGR team: 63.1% Accuracy (скриншот карты ошибок на этот момент - третий в комментариях).
Пора заканчивать день. У нас есть два полных дня чтобы попробовать добить качество до +80% при активном противодействии клиента (новые требования) и eval team (интеграция новых edge cases в ground truth).
Head of Eval сомневается, что получится (у него роль такая), я даю 70% успеха (у меня роль такая).
Ваш, @llm_under_hood 🤗
Хроники спасения проекта с LLM под капотом. В первый день мы налаживали коммуникацию и срочно объясняли про то, как собирать тестовые данные, второй день - собирали их. Может уже пора начать что-то делать?
8:43 Head of eval говорит, что первые ground truth данные будут готовы через полчаса. Переспрашивает, сколько времени займет генерация predictions - раньше было 3.5-8 дней.
Говорим, что по паре минут на каждый PDF. То есть минут 15 на первую версию GT.
Eval команда: O_o
09:27 Первую версию GT вычитали эксперты клиента.
09:28 Присылаю в чат первую версию карты ошибок (скриншот 1 в комментарях). Один столбец - одна сущность. Каждый квадратик - конкретное свойство этой сущности.
Серые - данные должны быть, но их нет
Красный квадрат - данные есть, но они ошибочны
Зеленый квадрат - predicted/actual == expected
Это - наша стартовая точка. Хуже уже не будет. Погнали
10:07 Готова первая работа над ошибками - подключили в пайплайн часть пропущенных документов. Карта выглядит менее страшно. Левая серая половина - не подгружается целая категория документов, Pipeline team работает над этим.
10:16 Созваниваемся с head of eval. Объясняю правила дальнейшей игры. SGR vs Eval:
(1) Objective of Eval team (eval and quality) - add as many red blocks as possible to this chart
(2) Objective of SGR team - turn as many blocks green as possible.
(3) Winning team get free round of beers/drinks paid by CEO
И заодно объясняю, что несмотря на игровую формулировку, под капотом тут строгая логика:
(1) Клиенту пока нужно увеличение точности. Приоритизируя большие красные блоки (обычно парсинг каких-то схожих полей), мы выбираем те части пайплайна, улучшение которых в итоге порадует клиента больше.
(2) Хорошие тестеры - это плохие разработчики, и наоборот. Одни создают, а другие - ломают. Эти роли ментально сложно совмещать, вот мы и не пытаемся. Задача “eval team” - не беспокоиться о качестве модели, а находить те самые вредные кейсы, на которых ломается модель. Эти кейсы принесут им больше красных блоков в карту.
Но при этом кейсы должны быть разнообразные. Т.к. если кейсы схожие, то SGR Team их сможет закрыть одним фиксом. А это не имеет смысла.
11:04 Наглядность - великая вещь. Один из экспертов клиента тоже подключается к заполнению GT. В итоге все видят, что требования проекта немного уехали в сторону, правят схему ground truth данных. SGR team берет новую версию в работу.
11:16 Начинаем генерировать такую плашку миссии с каждым отчетом - потраченные рабочие дни и текущая точность.
==============================================
HAIL MARY: 2 days, 1 hours since start
==============================================
Total blocks: 5,022
Green blocks: 1,996 (39.7%) - Matching
Red blocks: 1,290 (25.7%) - Different
Gray blocks: 1,736 (34.6%) - Missing
==============================================
11:49 Head of eval заканчивает рабочий день - у них в офисе внепроектные дела.
Да, у нас срочный проект, который горит. Да, мы только что потратили почти три дня на подготовку тестовых данных, и осталось всего два полных рабочих дня до первого milestone, где нужно получить более 80% точности. Да, прошлая попытка потратила 800 EUR токенами и занимала неделю только на один прогон пайплайна.
Но все идет по плану. Есть GT данные и pipeline eval. Дальше SGR команда может ставить эксперименты и инкрементально улучшать пайплайн, как в правильных стартапах. А поскольку работа разблокирована - eval команда может со спокойной совестью уйти отдыхать.
13:38 PM тоже уходит по своим делам
14:40 SGR team: 46.9% Accuracy
15:15 SGR team: 63.1% Accuracy (скриншот карты ошибок на этот момент - третий в комментариях).
Пора заканчивать день. У нас есть два полных дня чтобы попробовать добить качество до +80% при активном противодействии клиента (новые требования) и eval team (интеграция новых edge cases в ground truth).
Head of Eval сомневается, что получится (у него роль такая), я даю 70% успеха (у меня роль такая).
Ваш, @llm_under_hood 🤗
🔥73👍52❤48👏9😱4🤗2
Cпасение проекта с LLM под капотом - День 4
Хроники спасения проекта с LLM под капотом. В первый день мы налаживали коммуникацию и срочно объясняли про то, как собирать тестовые данные, второй день - собирали их. В третий, наконец, смогли измерить текущую точность, отобразив ее на карте ошибок.
Осталось два рабочих дня до выхода на нужную точность. Послезавтра вечером (самое позднее) нужно либо писать клиенту про митинг с результатами, либо…
10:00 Утренний созвон с ролями Head of Eval, PM, BI, SGR и Pipeline engineering. Планируем следующие два дня, проговариваем приоритеты.
Eval команда будет искать сложные кейсы, которые доказывают негодность и бесполезность пайплайна, добавлять их в GT dataset (добавляют красные квадратики в нашу карту ошибок, по которой мы планируем дальнейшую стратегию).
Pipeline engineering - закрывает провалы в обработке документов (убирает серые квадратики)
SGR Team - повышает качество document extraction (убирает красные квадратики с карты)
Integration - смотрит, будут ли впереди проблемы с интеграцией финального CSV в аналитику.
10:52 SGR Team: 70.7% Accuracy.
На самом деле, 70.7% получили раньше, но не писали, чтобы не отвлекать в нерабочее время. Вечером накануне пришло вдохновение, как улучшить качество. А тут как раз есть eval loop и возможность за несколько минут прогнать эксперимент. И он удался. Скриншот карты ошибок на этом этапе - первый в комментариях.
Пока все улучшения происходят только за счет мелких изменений в одном единственном запросе к LLM. Причем это даже не изменения в промпте (там всего два предложения), а перестановки и переименования полей в SGR схеме. Дробим задачу в рамках одного LLM запроса на маленькие шажочки при помощи SGR Cascade. Чтобы, при начале извлечения очередного свойства, у модели в самом хвостике контекста уже лежали все нужные данные. И так 60 раз в одном запросе. Такой "микро-промптинг".
12:04 У SGR команды начинают появляться вопросики к качеству и значению некоторых столбцов в ground truth данных. Ошибки модели у них перед глазами, и некоторые вещи не сходятся. Большая часть четвертого дня проходит в обсуждении и правках схемы ground truth c привлечением клиента.
В Excel появляются вкладки ground_truth_v1, _v2, _v3. Схему штормит.
При этом SGR команде не нужно заморачиваться отслеживанием деталей этих обсуждений. Если что-то поменяется - это автоматически проявится красными квадратиками. Они просто работают с самыми явными паттернами красного.
16:10 Eval team релизит ground_truth_v2.
17:02 SGR Team: 74.5% accuracy (карта ошибок - вторая в комментариях)
17:31 Eval team: Новые кейсы заказывали? Вот вам ground_truth_v3
17:37 SGR Team: вот новая версия карты ошибок (скриншот три в комментариях). Серые блоки - новые документы, на которых ломается пайплайн. С учетом этого accuracy падает до 62.2%.
Eval team - молодцы, что так сильно просадили качество. С одной стороны всем печально за score. А с другой - мы вскрыли проблемы, которые уже и так были в пайплайне, просто не отражались на карте. Лучше увидеть сейчас, чем если ошибки найдет клиент при перепроверке.
Приоритизация работ в команде на завтра вопросов не вызывает. Откуда начинать с утра копать - видно сразу по карте. Может нам пора ее начать называть стратегической картой ошибок (Strategic Error Map)?
Ваш, @llm_under_hood 🤗
PS: 21:24 PM появляется в чатике со словами, что ему хотелось поработать вечером и он подготовил еще новых строчек для ground_truth. Просим его завязать с работой. Пусть экономит энергию и внимание на завтра - это будет решающий день.
Хроники спасения проекта с LLM под капотом. В первый день мы налаживали коммуникацию и срочно объясняли про то, как собирать тестовые данные, второй день - собирали их. В третий, наконец, смогли измерить текущую точность, отобразив ее на карте ошибок.
Осталось два рабочих дня до выхода на нужную точность. Послезавтра вечером (самое позднее) нужно либо писать клиенту про митинг с результатами, либо…
10:00 Утренний созвон с ролями Head of Eval, PM, BI, SGR и Pipeline engineering. Планируем следующие два дня, проговариваем приоритеты.
Eval команда будет искать сложные кейсы, которые доказывают негодность и бесполезность пайплайна, добавлять их в GT dataset (добавляют красные квадратики в нашу карту ошибок, по которой мы планируем дальнейшую стратегию).
Pipeline engineering - закрывает провалы в обработке документов (убирает серые квадратики)
SGR Team - повышает качество document extraction (убирает красные квадратики с карты)
Integration - смотрит, будут ли впереди проблемы с интеграцией финального CSV в аналитику.
10:52 SGR Team: 70.7% Accuracy.
На самом деле, 70.7% получили раньше, но не писали, чтобы не отвлекать в нерабочее время. Вечером накануне пришло вдохновение, как улучшить качество. А тут как раз есть eval loop и возможность за несколько минут прогнать эксперимент. И он удался. Скриншот карты ошибок на этом этапе - первый в комментариях.
Пока все улучшения происходят только за счет мелких изменений в одном единственном запросе к LLM. Причем это даже не изменения в промпте (там всего два предложения), а перестановки и переименования полей в SGR схеме. Дробим задачу в рамках одного LLM запроса на маленькие шажочки при помощи SGR Cascade. Чтобы, при начале извлечения очередного свойства, у модели в самом хвостике контекста уже лежали все нужные данные. И так 60 раз в одном запросе. Такой "микро-промптинг".
12:04 У SGR команды начинают появляться вопросики к качеству и значению некоторых столбцов в ground truth данных. Ошибки модели у них перед глазами, и некоторые вещи не сходятся. Большая часть четвертого дня проходит в обсуждении и правках схемы ground truth c привлечением клиента.
В Excel появляются вкладки ground_truth_v1, _v2, _v3. Схему штормит.
При этом SGR команде не нужно заморачиваться отслеживанием деталей этих обсуждений. Если что-то поменяется - это автоматически проявится красными квадратиками. Они просто работают с самыми явными паттернами красного.
16:10 Eval team релизит ground_truth_v2.
17:02 SGR Team: 74.5% accuracy (карта ошибок - вторая в комментариях)
17:31 Eval team: Новые кейсы заказывали? Вот вам ground_truth_v3
17:37 SGR Team: вот новая версия карты ошибок (скриншот три в комментариях). Серые блоки - новые документы, на которых ломается пайплайн. С учетом этого accuracy падает до 62.2%.
Eval team - молодцы, что так сильно просадили качество. С одной стороны всем печально за score. А с другой - мы вскрыли проблемы, которые уже и так были в пайплайне, просто не отражались на карте. Лучше увидеть сейчас, чем если ошибки найдет клиент при перепроверке.
Приоритизация работ в команде на завтра вопросов не вызывает. Откуда начинать с утра копать - видно сразу по карте. Может нам пора ее начать называть стратегической картой ошибок (Strategic Error Map)?
Ваш, @llm_under_hood 🤗
PS: 21:24 PM появляется в чатике со словами, что ему хотелось поработать вечером и он подготовил еще новых строчек для ground_truth. Просим его завязать с работой. Пусть экономит энергию и внимание на завтра - это будет решающий день.
🔥79❤49👍16🤝4
Cпасение проекта с LLM под капотом - День 5
Итак, идет пятый день спасения проекта (1, 2, 3, 4). К его концу нужно принять решение - cможет ли команда завтра предоставить клиенту выгрузку данных нужного качества?
9:30 Созвон, формулируем план на день:
(1) За час забрать ground_truth_v3 в работу, поправить самые большие провалы, прогнать текущий пайплайн (не только GT dataset)
(2) работа над Accuracy - нужно 80%
(3) в течение сделать финальную выгрузку заранее, чтобы убедиться, что нет граблей
(4) Eval команда начинает собирать dataset для третьего класса документов - про запас.
В обсуждении очень видно, что вся команда глубже погружается в доменную область - сыплют терминами в ходе обсуждений. Это хороший признак. Организация работы не вызывает вопросов - все знают, что делать.
10:37 Pipeline начинают работать над провалами в данных, которые видны на вчерашней карте ошибок.
11:26 SGR Team пишет, что спустя 4 дня и полтора часа с начала проекта у нас Accuracy 68.1%. На карте ошибок уже меньше серого (первый скриншот в комментариях)
Готова частичная выгрузка данных. Пересылаем его интеграции, чтобы начали готовиться. Обещаю прогнать пайплайн целиком днем.
13:00 SGR Team: Качество не растет - уперлись в 70%. Решаем переписать с нуля второй промпт в пайплайне, который пока почти не трогали.
Если первый промпт использует сложную SGR схему для анализа документа, то второй промпт на этой основе пишет код. Иными словами, там стоит AI агент, который пишет код новых инструментов себе в пайплайн. Есть подозрение, что на этом этапе срабатывает один из трех Hallucination Triggers - у модели на вход идет слишком много лишней информации.
У нас осталась половина дня. Попробуем рискнуть и переписать там все.
13:25 Первый результат - ничего не понятно, но вроде бы не сильно хуже (скриншот второй в комментариях). Ground truth еще обсчитывается
13:30 Pipeline исправляет свою часть. На карте ошибок не должно оставаться больше серого
14:34 SGR Team: 74.9%! Серое еще есть на карте, но если его бы не было, то точность была бы 77.1%. Новая архитектура преодолела тот порог в 70%!
Карта ошибок - третья в комментариях. Начинаем смотреть на вот этот раздражающий красный блок в правом нижнем углу. Это группа свойств, которые связаны одним SGR каскадом. Они кажутся самой легкой добычей.
14:53 SGR Team: 77.1% accuracy - после мелкой доводки напильником вслепую и заодно отловом ошибок в самой ground_truth. Начинает формироваться правило, что если наша система с LLM под капотом упорно ошибается, то может быть ошибка в ground truth? Причем eval команда тоже озвучивает это. Weak Supervision lvl 2.
Eсли Pipeline починят свой pipeline, мы можем получить 79%!
15:52 SGR Team: 77.7% - добили эту группу свойств в нижнем углу. В основном просто мелкие перестановки и переименования, которые снижают когнитивную нагрузку на этом этапе до уровня выпускника. Карта ошибок - четвертая.
А время уже вечер...
15:56 PM: ну мы же теоретически до 80% почти дотягиваем?
16:03 Eval team: да, особенно если помнить, что у нас в тестах самые сложные кейсы из возможных.
Напомню, что Eval Team - оппонент SGR в данном проекте. Они отвечают за качество. Они разрушают работу SGR, наглядно демонстрируя ошибки - такова их роль в данном проекте. Они держат в уме риски и грабли. Поэтому и принятие решения лежит на них.
Решаем рискнуть и написать клиенту, что можем показывать хорошие результаты
16:31 распараллеливаем пайплайн и запускаем на полной выгрузке.
17:03 SGR Team - 4 дня, 7 часов с начала работы. Accuracy - 82.4%. Словно им забыли сказать, что 80% уже достаточно было. Карта ошибок - четвертая в комментариях.
Это окончательно убеждает Eval Team, что можно завтра показывать клиенту хороший результат.
За сим расходимся. Ну что тут может пойти не так?
Ваш, @llm_under_hood 🤗
Итак, идет пятый день спасения проекта (1, 2, 3, 4). К его концу нужно принять решение - cможет ли команда завтра предоставить клиенту выгрузку данных нужного качества?
9:30 Созвон, формулируем план на день:
(1) За час забрать ground_truth_v3 в работу, поправить самые большие провалы, прогнать текущий пайплайн (не только GT dataset)
(2) работа над Accuracy - нужно 80%
(3) в течение сделать финальную выгрузку заранее, чтобы убедиться, что нет граблей
(4) Eval команда начинает собирать dataset для третьего класса документов - про запас.
В обсуждении очень видно, что вся команда глубже погружается в доменную область - сыплют терминами в ходе обсуждений. Это хороший признак. Организация работы не вызывает вопросов - все знают, что делать.
10:37 Pipeline начинают работать над провалами в данных, которые видны на вчерашней карте ошибок.
11:26 SGR Team пишет, что спустя 4 дня и полтора часа с начала проекта у нас Accuracy 68.1%. На карте ошибок уже меньше серого (первый скриншот в комментариях)
Готова частичная выгрузка данных. Пересылаем его интеграции, чтобы начали готовиться. Обещаю прогнать пайплайн целиком днем.
13:00 SGR Team: Качество не растет - уперлись в 70%. Решаем переписать с нуля второй промпт в пайплайне, который пока почти не трогали.
Если первый промпт использует сложную SGR схему для анализа документа, то второй промпт на этой основе пишет код. Иными словами, там стоит AI агент, который пишет код новых инструментов себе в пайплайн. Есть подозрение, что на этом этапе срабатывает один из трех Hallucination Triggers - у модели на вход идет слишком много лишней информации.
У нас осталась половина дня. Попробуем рискнуть и переписать там все.
13:25 Первый результат - ничего не понятно, но вроде бы не сильно хуже (скриншот второй в комментариях). Ground truth еще обсчитывается
13:30 Pipeline исправляет свою часть. На карте ошибок не должно оставаться больше серого
14:34 SGR Team: 74.9%! Серое еще есть на карте, но если его бы не было, то точность была бы 77.1%. Новая архитектура преодолела тот порог в 70%!
Карта ошибок - третья в комментариях. Начинаем смотреть на вот этот раздражающий красный блок в правом нижнем углу. Это группа свойств, которые связаны одним SGR каскадом. Они кажутся самой легкой добычей.
14:53 SGR Team: 77.1% accuracy - после мелкой доводки напильником вслепую и заодно отловом ошибок в самой ground_truth. Начинает формироваться правило, что если наша система с LLM под капотом упорно ошибается, то может быть ошибка в ground truth? Причем eval команда тоже озвучивает это. Weak Supervision lvl 2.
Eсли Pipeline починят свой pipeline, мы можем получить 79%!
15:52 SGR Team: 77.7% - добили эту группу свойств в нижнем углу. В основном просто мелкие перестановки и переименования, которые снижают когнитивную нагрузку на этом этапе до уровня выпускника. Карта ошибок - четвертая.
А время уже вечер...
15:56 PM: ну мы же теоретически до 80% почти дотягиваем?
16:03 Eval team: да, особенно если помнить, что у нас в тестах самые сложные кейсы из возможных.
Напомню, что Eval Team - оппонент SGR в данном проекте. Они отвечают за качество. Они разрушают работу SGR, наглядно демонстрируя ошибки - такова их роль в данном проекте. Они держат в уме риски и грабли. Поэтому и принятие решения лежит на них.
Решаем рискнуть и написать клиенту, что можем показывать хорошие результаты
16:31 распараллеливаем пайплайн и запускаем на полной выгрузке.
17:03 SGR Team - 4 дня, 7 часов с начала работы. Accuracy - 82.4%. Словно им забыли сказать, что 80% уже достаточно было. Карта ошибок - четвертая в комментариях.
Это окончательно убеждает Eval Team, что можно завтра показывать клиенту хороший результат.
За сим расходимся. Ну что тут может пойти не так?
Ваш, @llm_under_hood 🤗
🔥110❤30👏29😁8👍2
Финал и подкапотные подробности истории со спасением проекта. Дни 6 и 7
Итак, подходит deadline сдачи проекта (Дни 1, 2, 3, 4, 5).
7:19 SGR Team: Выгрузку прислать не можем! Пайплайн вылетел ночью на неожиданных данных. Добавили try catch, больше параллелизма и запустили доделывать.
8:49 SGR: 27k сущностей, где-то 1k не хватает.
9:28 SGR: У нас не хватает несколько сотен сущностей, есть три категории ошибок:
(1) в 20 сущностях у нас нет ссылок на документы. Pipeline - чините!
(2) агент не может написать код инструмента в пайплайн
(3) есть классы документов с несколькими PDF. На такое мы были не готовы
Договариваемся, что eval team добавит новые три сущности в ground_truth (по одной на категорию ошибок). Это и новые документы в GT и очень неприятные кейсы в целом.
10:03 SGR: Третий класс ошибок исправлен
10:30 SGR: Второй класс ошибок исправили. Пришлось разрешить агенту адаптироваться.
11:50 SGR присылает выгрузку на 27407 сущностей.
12:48 Pipeline присылают фикс на последнюю категорию ошибок
14:11 Передаем клиенту данные на независимую проверку. Точность 83.8%(Карта ошибок в комментариях).
Следующий день
13:24 PM говорит, что команда клиента взяла 25 случайных продуктов и вручную сравнила наши данные с ожидаемыми.
Они нашли 4 ошибки среди 25*60 полей
Может, нам повезло с выборкой, может клиент тестировал не очень внимательно (на приемке, ага), может eval team просто собрали такой хардкорный датасет/бенчмарк. Но по факту, команда за 6 дней работы вместе подняла видимую клиенту точность на их выборке с ~60% до 99.7%.
Что дальше?
А дальше проект может катиться по колее. Процессы поставлены, люди знают, что делать. Добавление еще трех источников документов - не вызывает никаких вопросов. Как добавлять новые edge cases и контроллировать качество - тоже. Причем клиенту завели документ, куда он может добавлять ошибки (обязательно со скриншотами), чтобы потом eval team переносила их в ground truth, а SGR улучшала качество. Те 4 ошибки тоже торжественно занесли в документ.
Как оно работает под капотом?
Первый промпт: "Вот тебе PDF с кучей сущностей. Заполни шаблон анализа закономерностей". Да, там два предложения плюс SGR схема на 160 строчек кода (в ней где-то 20 каскадов на 80 полей)
Второй промпт: "Вот тебе PDF с кучей сущностей и анализ закономерностей. Напиши tool, который сможет разобрать название любого компонента и заполнить специфичные для него поля. Жесткие требования прилагаются."
Второй промпт работает как линейный SGR NextStep Agent. Пайплайн берет код полученного инструмента и запускает его. Если же есть проблемы/вопросы - добавляет edge cases в контекст и повторяет попытку.
Система сгенерировала 687 инструментов себе в пайплайн, общим размером 109922 строчек кода (или 4.5MB). Этот код не видел ни один человек (только я видел stack traces, когда ставил архитектуру). Размер и качество этого кода не имеют значения, пока у нас есть общий результат работы проекта - точность, скорость и стоимость.
(1) Точность работы - 83.8% на бенчмарке из самых сложных кейсов и 99.7% при оценке клиентом.
(2) Скорость работы - можно получить результаты за ночь (против 3.5-7 дней раньше). При желании можно и быстрее - выкрутив параллелизм. Лимиты - не проблема.
(3) Стоимость работы всего этого комбайна, включая разработку, эксперименты и полные прогоны пайплайна - $26.6 (против $800+ в попытках предыдущей команды). Скриншот расходов OpenAI по дням - в комментариях.
Архитектура не является ничем выдающимся - это побочный эффект от решения задачки, которую eval команда оформила в качественный ground truth датасет.
В этом проекте мы вложили половину времени - целых три дня - на сбор и запуск тестов. И это позволило получить нужный результат за оставшиеся три дня.
По итогам команды говорят, что получился классный тимбилдинг и экспресс-практикум. Даже не против повторения подобного, но без стресса (дней 8 вместо 6). А ведь все начиналось вечность назад как проект, который уже не спасти.
Спасибо, что читали эту историю и проживали ее вместе с командой проекта Hail Mary!
Ваш, @llm_under_hood 🤗
Итак, подходит deadline сдачи проекта (Дни 1, 2, 3, 4, 5).
7:19 SGR Team: Выгрузку прислать не можем! Пайплайн вылетел ночью на неожиданных данных. Добавили try catch, больше параллелизма и запустили доделывать.
8:49 SGR: 27k сущностей, где-то 1k не хватает.
9:28 SGR: У нас не хватает несколько сотен сущностей, есть три категории ошибок:
(1) в 20 сущностях у нас нет ссылок на документы. Pipeline - чините!
(2) агент не может написать код инструмента в пайплайн
(3) есть классы документов с несколькими PDF. На такое мы были не готовы
Договариваемся, что eval team добавит новые три сущности в ground_truth (по одной на категорию ошибок). Это и новые документы в GT и очень неприятные кейсы в целом.
10:03 SGR: Третий класс ошибок исправлен
10:30 SGR: Второй класс ошибок исправили. Пришлось разрешить агенту адаптироваться.
11:50 SGR присылает выгрузку на 27407 сущностей.
12:48 Pipeline присылают фикс на последнюю категорию ошибок
14:11 Передаем клиенту данные на независимую проверку. Точность 83.8%(Карта ошибок в комментариях).
Следующий день
13:24 PM говорит, что команда клиента взяла 25 случайных продуктов и вручную сравнила наши данные с ожидаемыми.
Они нашли 4 ошибки среди 25*60 полей
Может, нам повезло с выборкой, может клиент тестировал не очень внимательно (на приемке, ага), может eval team просто собрали такой хардкорный датасет/бенчмарк. Но по факту, команда за 6 дней работы вместе подняла видимую клиенту точность на их выборке с ~60% до 99.7%.
Что дальше?
А дальше проект может катиться по колее. Процессы поставлены, люди знают, что делать. Добавление еще трех источников документов - не вызывает никаких вопросов. Как добавлять новые edge cases и контроллировать качество - тоже. Причем клиенту завели документ, куда он может добавлять ошибки (обязательно со скриншотами), чтобы потом eval team переносила их в ground truth, а SGR улучшала качество. Те 4 ошибки тоже торжественно занесли в документ.
Как оно работает под капотом?
Первый промпт: "Вот тебе PDF с кучей сущностей. Заполни шаблон анализа закономерностей". Да, там два предложения плюс SGR схема на 160 строчек кода (в ней где-то 20 каскадов на 80 полей)
Второй промпт: "Вот тебе PDF с кучей сущностей и анализ закономерностей. Напиши tool, который сможет разобрать название любого компонента и заполнить специфичные для него поля. Жесткие требования прилагаются."
Второй промпт работает как линейный SGR NextStep Agent. Пайплайн берет код полученного инструмента и запускает его. Если же есть проблемы/вопросы - добавляет edge cases в контекст и повторяет попытку.
Система сгенерировала 687 инструментов себе в пайплайн, общим размером 109922 строчек кода (или 4.5MB). Этот код не видел ни один человек (только я видел stack traces, когда ставил архитектуру). Размер и качество этого кода не имеют значения, пока у нас есть общий результат работы проекта - точность, скорость и стоимость.
(1) Точность работы - 83.8% на бенчмарке из самых сложных кейсов и 99.7% при оценке клиентом.
(2) Скорость работы - можно получить результаты за ночь (против 3.5-7 дней раньше). При желании можно и быстрее - выкрутив параллелизм. Лимиты - не проблема.
(3) Стоимость работы всего этого комбайна, включая разработку, эксперименты и полные прогоны пайплайна - $26.6 (против $800+ в попытках предыдущей команды). Скриншот расходов OpenAI по дням - в комментариях.
Архитектура не является ничем выдающимся - это побочный эффект от решения задачки, которую eval команда оформила в качественный ground truth датасет.
В этом проекте мы вложили половину времени - целых три дня - на сбор и запуск тестов. И это позволило получить нужный результат за оставшиеся три дня.
По итогам команды говорят, что получился классный тимбилдинг и экспресс-практикум. Даже не против повторения подобного, но без стресса (дней 8 вместо 6). А ведь все начиналось вечность назад как проект, который уже не спасти.
Спасибо, что читали эту историю и проживали ее вместе с командой проекта Hail Mary!
Ваш, @llm_under_hood 🤗
🔥332❤134👏49👍25😁3🤝2⚡1🤗1
Давайте соберем карту внедрений SGR и список частых вопросов по ним
В коммьюнити идут обсуждения про Schema-Guided Reasoning, в основном в контексте Open Source проекта SGR Deep Research. Этот проект для некоторых команд стал первым наглядным примером того, как подойти к задаче построения умного агента на базе относительно небольших моделей (в том числе и локальных). Чаще всего слышим про попытки адаптировать методы в банковской сфере и промышленности. Может быть нас еще больше?
Давайте вообще систематизируем весь этот процесс и сделаем его эффективнее для коммьюнити!
Вот анонимный опросник, чтобы построить более полную карту внедрений по отраслям и собрать вопросы. Опросник: Строим вместе карту внедрений SGR
Результаты опроса и ответы на самые частые вопросы будут в каналах:
- LLM под капотом
- Neural Kovalski
Ваш, @llm_under_hood 🤗
В коммьюнити идут обсуждения про Schema-Guided Reasoning, в основном в контексте Open Source проекта SGR Deep Research. Этот проект для некоторых команд стал первым наглядным примером того, как подойти к задаче построения умного агента на базе относительно небольших моделей (в том числе и локальных). Чаще всего слышим про попытки адаптировать методы в банковской сфере и промышленности. Может быть нас еще больше?
Давайте вообще систематизируем весь этот процесс и сделаем его эффективнее для коммьюнити!
Вот анонимный опросник, чтобы построить более полную карту внедрений по отраслям и собрать вопросы. Опросник: Строим вместе карту внедрений SGR
Результаты опроса и ответы на самые частые вопросы будут в каналах:
- LLM под капотом
- Neural Kovalski
Ваш, @llm_under_hood 🤗
🔥28👍23❤13🙏4🤝2
В каких компаниях вопросы про SGR стоят острее всего?
Это предварительные данные опроса ранее.
Выборка пока не очень большая, но похоже, что больше всего вопросов возникает у компаний размером 11-50 человек, которые работают в Business Services и хотят попробовать внедрить методы/агентов на базе SGR в продажи или маркетинг.
Medical, финтех и производство идут следующими.
Цвет на графиках тем интенсивнее, чем больше вопросов про SGR возникает, мы это будем использовать при приоритизации ответов.
Опрос еще идет, можете оставить свои вопросы вот тут (или переслать коллегам для заполнения): Русский / English.
Ваш, @llm_under_hood 🤗
Это предварительные данные опроса ранее.
Выборка пока не очень большая, но похоже, что больше всего вопросов возникает у компаний размером 11-50 человек, которые работают в Business Services и хотят попробовать внедрить методы/агентов на базе SGR в продажи или маркетинг.
Medical, финтех и производство идут следующими.
Цвет на графиках тем интенсивнее, чем больше вопросов про SGR возникает, мы это будем использовать при приоритизации ответов.
Опрос еще идет, можете оставить свои вопросы вот тут (или переслать коллегам для заполнения): Русский / English.
Ваш, @llm_under_hood 🤗
❤19👍11🤝2
Насколько маленькая LLM модель может вытянуть Deep Research?
Насколько плохо или хорошо это будет выглядеть? Насколько будет ерунда под капотом?
Можно заглянуть под капот размышлений относительно небольшой модели gpt-4o-mini/Qwen2.5-7B-Instruct в режиме SGR (NextStep архитектура). Валера навайбкодил интерфейс для отладки, который показывает ход размышлений и вызова инструментов
Да, в проде люди используют модели побольше. Но ведь реально интересно, как будет себя вести крохотная модель, которую даже не обучали под reasoning, но потом заставили следовать схеме размышлений.
Вот, например, результат ответа на вопрос "Find the price of Bitcoin today and find the price for 2023 and 2024" при помощи qwen2.5-7B-Instruct: трейс размышлений c вызовами инструментов и финальный отчет.
Ваш, @llm_under_hood 🤗
Насколько плохо или хорошо это будет выглядеть? Насколько будет ерунда под капотом?
Можно заглянуть под капот размышлений относительно небольшой модели gpt-4o-mini/Qwen2.5-7B-Instruct в режиме SGR (NextStep архитектура). Валера навайбкодил интерфейс для отладки, который показывает ход размышлений и вызова инструментов
Да, в проде люди используют модели побольше. Но ведь реально интересно, как будет себя вести крохотная модель, которую даже не обучали под reasoning, но потом заставили следовать схеме размышлений.
Вот, например, результат ответа на вопрос "Find the price of Bitcoin today and find the price for 2023 and 2024" при помощи qwen2.5-7B-Instruct: трейс размышлений c вызовами инструментов и финальный отчет.
Ваш, @llm_under_hood 🤗
🔥54❤8👍8
Эпилог спасательного проекта и ответы на некоторые вопросы
(В прошлых сериях: 1, 2, 3, 4, 5, 6+7)
Клиент потом довольно сказал, что “was very happy about the current figures”. И это при том, что команда честно поделилась оценками качества на тестовом наборе данных, где собраны самые неприятные моменты.
В команде подключают новые источники данных. Прикидывали заранее, что на них качество упадет до 70% из-за овертюна и отличающейся доменной модели - некоторые термины и методики в новых документах отличаются принципиально. Особенно в тех SGR каскадах, где клиент и eval team до сих пор не пришли к единому пониманию, как это правильно считать.
По факту же общее качество… поднялось до 85.9%. Это все из-за правки системных ошибок, которые стали очевидными после добавления третьего источника данных. В итоге получается 85.3% и 83.9% на известных источниках и 78.3% на новом (это правый столбец шириной ~20 квадратов на скришоте, он очень заметен). И вот тот самый раздражающий блок красных ошибок - это и есть поля, в которых в SGR схеме не прописана нормально методология извлечения.
Заодно, в комментариях выложил скриншот того самого Excel с ground truth (для оценки масштабов работы eval команды, содержимое ячеек там не разобрать)
Про успех проекта директора рассказали по всей компании, отдельно выделив работу eval команды. Ну и заодно показали цифры про количество кода, “который никто не видел”. Это нужно, чтобы команды исподволь привыкали к двум вещам:
(1) тесты и инженерный подход - это наше все, особенно в проектах c LLM под капотом.
(2) код - это просто формат для компактного хранения данных и поведений. Он, как и веса моделей, не так важен при наличии тестов и процесса “обучения”
Правильный менталитет и привычки, дадут командам этой компании фору на рынке. Ну а то, что конкуренты ругаются на попрание норм разработки и неправильность подходов - пусть себе ругаются. Клиентов интересуют в первую очередь результаты.
Внутри же чаще всего спрашивают про устройство пайплайна и раутинг запросов к агентам. Про это я писал ранее, но еще раз повторюсь - два основных промпта, как и в простейшем RAG. Один - Retrieval, второй - Generation. Качество результатов всегда упирается в первый шаг.
Первый промпт делает тщательный анализ документа, используя ветвистый SGR с кучей оптимизированных каскадов.
Второй промпт генерирует код инструмента для извлечения, который будет вызван следующим шагом. Если сгенерированный код не проходит проверки, то в контекст докидывается информация, ползунок reasoning для gpt-5-mini выкручивается в high, и агент отправляется работать над ошибками.
Сложного и гибкого раутинга тут нет - есть жесткие рельсы, которые отбирают свободу, но позволяют оценивать качество и улучшать его.
Да и не нужна чрезмерная свобода агентам в типичных бизнес-задачах. Можно построить гибкую систему на фиксированных шагах с измеримым качеством.
А тем временем директор этой компании прислал здоровущий Excel от биотеха с тремя вопросами:
(1) это вообще делается?
(2) сколько времени надо?
(3) какое будет качество?
Ответ? "Есть идеи. Пять дней и eval команду, тогда скажем точнее"
Ваш, @llm_under_hood 🤗
(В прошлых сериях: 1, 2, 3, 4, 5, 6+7)
Клиент потом довольно сказал, что “was very happy about the current figures”. И это при том, что команда честно поделилась оценками качества на тестовом наборе данных, где собраны самые неприятные моменты.
В команде подключают новые источники данных. Прикидывали заранее, что на них качество упадет до 70% из-за овертюна и отличающейся доменной модели - некоторые термины и методики в новых документах отличаются принципиально. Особенно в тех SGR каскадах, где клиент и eval team до сих пор не пришли к единому пониманию, как это правильно считать.
По факту же общее качество… поднялось до 85.9%. Это все из-за правки системных ошибок, которые стали очевидными после добавления третьего источника данных. В итоге получается 85.3% и 83.9% на известных источниках и 78.3% на новом (это правый столбец шириной ~20 квадратов на скришоте, он очень заметен). И вот тот самый раздражающий блок красных ошибок - это и есть поля, в которых в SGR схеме не прописана нормально методология извлечения.
Заодно, в комментариях выложил скриншот того самого Excel с ground truth (для оценки масштабов работы eval команды, содержимое ячеек там не разобрать)
Про успех проекта директора рассказали по всей компании, отдельно выделив работу eval команды. Ну и заодно показали цифры про количество кода, “который никто не видел”. Это нужно, чтобы команды исподволь привыкали к двум вещам:
(1) тесты и инженерный подход - это наше все, особенно в проектах c LLM под капотом.
(2) код - это просто формат для компактного хранения данных и поведений. Он, как и веса моделей, не так важен при наличии тестов и процесса “обучения”
Правильный менталитет и привычки, дадут командам этой компании фору на рынке. Ну а то, что конкуренты ругаются на попрание норм разработки и неправильность подходов - пусть себе ругаются. Клиентов интересуют в первую очередь результаты.
Внутри же чаще всего спрашивают про устройство пайплайна и раутинг запросов к агентам. Про это я писал ранее, но еще раз повторюсь - два основных промпта, как и в простейшем RAG. Один - Retrieval, второй - Generation. Качество результатов всегда упирается в первый шаг.
Первый промпт делает тщательный анализ документа, используя ветвистый SGR с кучей оптимизированных каскадов.
Второй промпт генерирует код инструмента для извлечения, который будет вызван следующим шагом. Если сгенерированный код не проходит проверки, то в контекст докидывается информация, ползунок reasoning для gpt-5-mini выкручивается в high, и агент отправляется работать над ошибками.
Сложного и гибкого раутинга тут нет - есть жесткие рельсы, которые отбирают свободу, но позволяют оценивать качество и улучшать его.
Да и не нужна чрезмерная свобода агентам в типичных бизнес-задачах. Можно построить гибкую систему на фиксированных шагах с измеримым качеством.
А тем временем директор этой компании прислал здоровущий Excel от биотеха с тремя вопросами:
(1) это вообще делается?
(2) сколько времени надо?
(3) какое будет качество?
Ответ? "Есть идеи. Пять дней и eval команду, тогда скажем точнее"
Ваш, @llm_under_hood 🤗
🔥66❤30👍15🤗6🤯2💯1