Валера топ, списался с ним, было пару вопросов по ллм аппке - рассказал и показал как что лучше реализовать! Если хотите построить что то на ллмке и с чем то есть трудности, не стесняйтесь - пишите ему, сориентирует и направит) спасибо!

У @VaKovaLskii из @neuraldeep есть RAG бот, который может отвечать на вопросы по материалам канала и чата нашего комьюнити.

Бот появился впервые месяцев 8 назад и недавно ожил снова, пополнился новыми постами.

Бот работает как Custom ChatGPT - находит релевантные сообщения и на их основе синтезирует ответ. Ответы не всегда точные, но всегда сопровождаются ссылками на оригинальные сообщения, поэтому все можно перепроверить.

Пообщаться с ботом можно тут: @neuraldeepbot. Прочитать о нем тут.

Ваш, @llm_under_hood 🤗

LLM/RAG Мониторинг с первого дня - это не роскошь, а необходимость!

Когда я запускал @neuraldeepbot 8 месяцев назад, думал "сделаю MVP, а потом посмотрю"

Результат? Система работала, потом, когда-то, запущу в докере и улучшу
Но с развитием кодовых агентов и IDE таких как Cursor у меня чуть сильнее развязались руки

Сейчас подход кардинально другой — с первого запроса у меня есть:

Детализация реакций по дням (видно на графике)
Процент лайков по каждому этапу развития
Классификация сложности запросов через LLM
Трекинг используемых навыков в ReAct цепочке

И знаете что? Это реально работает!
За 6 дней метрики выросли с 48.8% до 96.0% положительных реакций

ReAct архитектура когда LLM сама решает как искать

Вместо жестко заданного пайплайна "вектора → реранкер → ответ" внедрил ReAct подход:

User Query → 

1) LLM классификатор навыка
Защита
Уточнение
Мета вопросы
RAG поиск
→ 
2) LLM классификатор сложности
 
ReAct агент выбирает навыки:
   - FTS поиск по ключевым словам
   - Векторный поиск (bge embedding)  
   - Комбинированный поиск
   - Временная фильтрация
   - Поиск по коментам vs постам
→ Синтез финального ответа

Еще одним полем отечает последовательность запуска (ему так же прописаны связи и возможности)
gpt-5-mini показала себя прям очень хорошо 

Кстати все взаимодействия с навыками я построил через SO никакого tool call

Конкретные цифры улучшений:

12.08: Запуск наивного RAG бота — 48.8% лайков
13.08: Анализ первых 200 запросов — 76.0% лайков
14.08: Добавил 4 навыка и классификатор — 78.3% лайков
16.08: Переход на GPT-4o-mini — 95.0% лайков
18.08: Финальные улучшения — 96.0% лайков

Аналитика запросов ваш компас в темноте это проблема почти 90% инициатив которые я встречаю

Самые болезненные инсайты пришли из анализа реальных пользовательских запросов:
Проблема №1: "Какой последний пост был?"

Система отвечала защитой из промпта
Фикс: Добавил навык временного поиска

Проблема №2: "Лучшая локальная LLM?"

Тащила посты 2024 года вместо свежих
Фикс: Приоритизация по датам через ReAct

Проблема №3: Нехватка контекста из разных каналов

Добавил данные из @llm_under_hood и @denissexy, @seeallochnaya
Сразу видно улучшение по реакциям!

Мой чек-лист для каждой итерации Q&A системы
Неделя 1: Базовый MVP + мониторинг реакций
Неделя 2: Анализ первых 100-200 запросов глазами (далее зовем LLM что бы сверится)
Неделя 3: Добавление недостающих навыков поиска
Неделя 3: Оптимизация промптов под реальные кейсы

Далее: Еженедельные итерации по метрикам
Техническая кухня что реально двигает метрики
Стек убийца:

ReAct агент для выбора стратегии поиска
gpt-5-mini как основной LLM (переход дал +19% к лайкам!)
SO на всех этапах вызова навыков
FTS + векторный поиск в зависимости от запроса
bge реранкер для финальной фильтрации
Qdrant для хранения эмбеддингов
PGSQL как основная база
teleton
fastapi
python

Система оценок:

Лайк/дизлайк после каждого ответа
Дизлайк = я лично смотрю кейс и думаю что пошло не так
Никаких A/B тестов — итерируем по общим метрикам(но только на старте)

Главные ошибки, которые убивают Q&A системы

"Сделаю идеальную архитектуру, а потом запущу" — НЕТ!
Запускай MVP и итерируй по реальным запросам
Игнорирование мониторинга без метрик ты летишь вслепую
Жесткий пайплайн поиска на цепочках n8n? Выкинуть, пилим адаптивный ReAct который дает LLM выбирать стратегию поиска
Недооценка важности промптов 80% успеха Q&A системы в правильных промптах

Ребята реально общались со мной через запросы и давали детальные советы по улучшению промптов

Честно говоря, RAG как RPG нужно быстро лечиться (хотфиксы),
крафтить экипировку (промпты), управлять инвентарем (данные)
и качать скиллы через квесты (Cursor). Каждый день фармишь опыт и лут для апгрейда системы

Но с правильным мониторингом и планом итераций
можно довести систему до production-ready за несколько недель вместо месяцев блужданий

Кто строил похожие Q&A системы без четкого понимания сценариев?
Какие метрики отслеживаете?
И главное как быстро итерируете по фидбеку пользователей?

Паша early adopter который получил доступ к моему API!

Красава что такое замутил!

👇

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 из моей практики:

{
  "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!

SGR Deep Research

А почему бы не взять все лучшие идеи из демо и идей ребят из чата
Собрать свои идеи по Deep Research
И сделать самый простой инструмент поиска инфы в интернете через Tavlily API?

А сделать, вот он https://github.com/vakovalskii/sgr-deep-research (звездочки приветствуются)

gpt-4o-mini
Tavily API (1000 реквестов в месяц фри)
SGR-concept

Из интересного что заметил такая модель сама определяет что например чипов M6 у applе не существует и на ходу меняет план рисерча потому что нашла это в данных из инета
Или что термин SGR ей не понятен и просит его расшифровать

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

1. 🤔 Clarification (ВЫСШИЙ ПРИОРИТЕТ)
- При любой неопределенности в запросе
- Неизвестные термины, акронимы, аббревиатуры
- Неоднозначные запросы с множественными интерпретациями
- Отсутствие контекста для специализированных областей

2. 📋 GeneratePlan
- Когда план не существует и запрос ясен
- После получения уточнений от пользователя

3. 🔄 AdaptPlan
- Когда требуется адаптация исследовательского подхода
- При обнаружении неточностей в первоначальных предположениях

4. 🔍 WebSearch
- Когда нужна дополнительная информация И searches_done < 3
- МАКСИМУМ 3-4 поиска на исследование

5. 📄 CreateReport
- При searches_done >= 2 ИЛИ enough_data = True
- Когда собрана информация для полного анализа

6. ✅ ReportCompletion
- После создания отчета
- Финализация исследования

Соответствие концепту SGR верифицировало Ринатом 😂

Предлагайте ваши эксперименты! Вон даже ребята из Cбера подключились!

Агент или Пайплайн?

Середина 25го года – хайп вокруг агентов начал перерастать в рабочие решения: claude code, perplexity labs, computer use и т.д.

Правда почему-то сейчас любые два запроса к API зовут агентом. А если еще с разными промптами, то, уууууу, аж система агентов.

Это бред. Большая часть того, что называют агентами – просто пайплайны – жестко заданные наборы шагов. Часть из них – запросы к LLM, часть – просто логика, например, запустить код, который сгенерировала LLM на прошлом шаге.

Агентность – способность системы самой принимать решения о типе следующего действия на основе результатов предыдущих.

Агентность – это шкала, а не бинарное значение. У системы ее может быть больше, а можем быть меньше. Как у людей.

Но для простоты, я использую вот такое разделение:

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

———

Примеры

Задача – сделать систему, которая будет отвечать на запрос пользователя используя информацию из интернета.

1. Сначала ищем странички, потом делаем запрос к LLM, подставляя их в контекст

relevant_sites = await search_google(query)
response = await generate_response(query, relevant_sites)

Агент? Нет – шаги жестко зафиксированы

———

2. Усложняем. Смотрим, что если нашли слишком мало страниц, то пытаемся поменять запрос пользователя и искать еще

relevant_sites = await search_google(query)
if len(relevant_sites) < 10:
  optimized_query = await optimize_user_query(query)
  more_sites = await search_google(optimized_query)
  relevant_sites.extend(more_sites)

response = await generate_response(query, relevant_sites)

Вооо, теперь агент. Мы же не знаем заранее, по какому пути пойдем, да? Но решение принимает не ИИ, а программист, который написал if. Так что это тоже не агент.

———

3. Пишем агента. Теперь LLM сама определяет в check_enough_info, готовы ли генерировать ответ, или нужно добавить еще результатов.

relevant_sites = await search_google(query)

if not await check_enough_info(query, relevant_sites):
  optimized_query = await optimize_user_query(query)
  more_sites = await search_google(optimized_query)
  relevant_sites.extend(more_sites)

response = await generate_response(query, relevant_sites)

Уже лучше, но на самом деле это еще не полноценный агент. Все равно явная последовательность шагов – модель выбирает только одну ветку, а дальше все снова определено. Но мы уже близко

———

4. Настоящему агенту нужно прописать набор действий и дать их совершать (подсовывая ему после выполнения каждого действия новую информацию в контекст)

state["query"] = query
state["sites"] = []

while "response" not in state:
  next_step = await choose_next_step(state)
  if next_step == "search_google":
    state["sites"].extend(await search_google(query))
  elif next_step == "optimize_query":
    state["query"] = await optimize_user_query(query)
  elif next_step == "generate_response":
    state["response"] = await generate_response(query, state["sites"])

А чтобы делать такие системы надежными и масштабируемыми, нужно использовать Structured Output и определять шаги через pydantic/zod классы. Так задаем структуру размышлений для модели, чтобы она хорошо выбирала следующий шаг (SGR).

Почитать:

- Разгоняли с @neuraldeep в комментах про агентность, а через пару часов он сделал свой диприсерч всего в 600 строк кода. Особенно полезно посмотреть на pydantic классы
- База по SGR (structured guided reasoning) от @llm_under_hood
- Моя серия из 3 постов про structured_output

Сегодня я проснулся знаменитым

Спасибо! Ребят!

SGR + Tool, Hybrid Deep Research

И так мы продолжаем рубрику эксперименты!

1) Спасибо Диме что предоставил новую ветку где перевел SGR внутрь tool

2) Дальше я уже с легкой руки добавил около ~6 навыков, проработал управление контекстом всего теперь 12 навыков есть у системы и она помнит все предыдущие события

Детально с решением можно ознакомиться в ридми в ветке hybrid_reasoner_sgr_with_tools

Что имеем?
Без фреймворков с сохранением SGR который обернут в tool, более автономную систему которая понимает предыдущий контекст может работать с файловой системой и может искать в интернете

Что дальше?
3) Я приведу обе ветки к единому кол-ву навыком и мы попробуем собрать небольшой датасет дабы проверить надежность таких систем в разных сценариях рисерча

P.S система все еще работает на gpt-4o-mini но для лучшего экспириенса советую поменять на 4o так же хорошо проработан подход работы с кешом и система стала в 2-3 раза быстрее

Прошло 3 часа и комьюнити уже добавили интерфейс на базе chainlit

Если вы уже развернули последнюю версию гибридного подхода то берем такой набор действий


нужно сделать

git pull

pip install -r requirements.

chainlit run gui_app.py -w

Давайте добьем до 100 звезд!!!
https://github.com/vakovalskii/sgr-deep-research

В тему моих постов про новую эру монетизации с GenAI, будет вполне полезно ознакомиться и с Customer Journey.👇👇👇

SGR vs Function Calling: ghost busters edition

TL;DR: 3 дня копания в FC решениях, даже достал MacBook Pro с 32GB RAM чтобы 100% проверить на моделях до 5B → SGR решение а не костыль, наш общий проект с вами за неделю набрала 170+ звезд на GitHub

Как обсуждали ранее, tool_choice на первом шаге часть агентного подхода, тут я полностью согласен, но хотелось прям глубже разобраться где есть еще одна сторона SGR

На моделях касты OpenAI/Anthropic такие рекомендации работают потому что метрики у них 80+ по BFCL (это лишь пример на какой бенч нужно смотреть) и агентность сохраняется

Когда мы спускаемся ниже 35 по секции Agentic на BFCL то тут SGR не костыль а решение


FC реальность на локал моделях
Взял модель из Ollama она мне шиш (говорит не умеет в tool)
BFCL показывает Qwen3-4B = 2% в Agentic режиме O_o
Разбираемся а GGUF конвертация и руки убилаи chat template с поддержкой tools при переводе модели в ollama
Лезу в карточку Unsloth а там умеет
Собираю правильный chat template и беру от unsloth/Qwen3-4B-Instruct-2507-GGUF FP16 при сборке модели в Ollama

И о чудо она начала принимать tool

Но модель умеет КАК, но не КОГДА:

{"tool_calls": null, "content": "Текст вместо вызова тула"}

Принудительный tool_choice = 3-5 вызовов, парсинг XML, валидация

При переносе оригинального chat template Ollama напрочь не парсит эту секцию в XML
Сделаем обработку не поднялось
А все почему?
Вспоминаем метрики Agentic
Все стало понятно

Дальше попробовал 7B, 14B, 32B
Все встало на свои места я даже выдохнул!
У нас в проекте поддерживается 2 ветки: SGR FULL и где SGR поместили в tool
Переключился на SGR FULL и протестировал - 100% работа системы!

# Phase 1: Structured Output reasoning
reasoning = model.generate(format="json_schema")

# Phase 2: Детерминированное выполнение
result = execute_plan(reasoning.actions)

Дима предложил гибрид - SGR обернуть в tool для нормальных моделей:

Принудительный reasoning перед любым действием через tool_choice
Результат: 12 навыков системы, память между сессиями, работает на любых моделях
Паша сделал API - FastAPI с OpenAI совместимостью
Дима добавил веб-интерфейс - Chainlit UI
Пару ребят предложили по-другому собирать env - улучшили deployment
На gpt-4o FC ветка с историей и бесконечным диалогом дает хорошие ощущения

Метрики еще предстоит измерить, но система работает
На gpt-4o-mini: ребята говорили что очень даже достойно в режиме FC
На локальных 4B: SGR FULL отрабатывает простые запросы на 100% и генерит вменяемые отчеты

SGR как tool = лучшее из миров для моделей <32B где Overall Acc Agentic ниже 35
Связано это с тем что именно тут кроется сложная часть тюна и корректировки


Anthropic/OpenAI добавили принуждение через спец токены, но это ли агентность? Скорее принуждение

Традиционный FC:
- Модель сама решает КОГДА думать ❌
- Непредсказуемые решения ❌

SGR в FC:  
- Первое поле reasoning ЗАСТАВЛЯЕТ думать ✅
- Структурированное планирование ✅
- Потом извлекает tool из SO ✅
- Вставляем в role tool что тулинг был вот он в истории ✅

Архитектурные пороги

<14B: Pure SGR JSON
14-32B: SGR tool + FC hybrid (наш случай)
32B+: Native FC + SGR fallback

Обсудили мои выводы в ЛС с Димой из Dimension AI - пришли к консенсусу

Не заставляйте <32B притворяться gpt-4o
Дайте структурированно мыслить через SGR, действовать через эмуляцию FC

На локал на m1 pro 4b модель работает при использовании FULL_SGR

P.S. Много кто писал что такой подход на чистом SO где тулы вшиты в схемы давно использовал, но интересно - подавали ли вы в истории вызвание тулы после?


GitHub: https://github.com/vakovalskii/sgr-deep-research

BOOST https://t.iss.one/boost/neuraldeep