История трёх технологий которые изменили AI (часть 1/3)

После марафона на 30 дней по sgr-deep-research (спасибо вам за 500+ звезд) сел разбираться за историю и матчасть Structured Output, Function Calling и MCP, оказалось это история полная косяков провайдеров и года потраченного на исправление того что должно было работать с первого релиза

И так составил вот такой вот таймлайн дабы закрепить изученный материал и передаю его вам =)

Июнь 2023: Function Calling появился первым и сломанным

OpenAI 13 июня выкатили Function Calling для GPT-4 и GPT-3.5-turbo, идея была крутая, LLM может вызывать функции с аргументами через JSON Schema контракт, разработчики обрадовались но радость длилась недолго

Проблема была жосткая, аргументы функций приходили невалидными!
LLM могла выдать temperature как строку "twenty degrees" вместо числа 20, могла забыть кавычки у ключей, могла написать "celsuis" вместо "celsius"
Все лепили костыли в виде retries и validation вручную (я тут менял работу из DevOps в CEO)

OpenAI не сказали об этой проблеме явно, просто в документации было "рекомендуется валидировать аргументы", на деле reliability меньше 60%, в production такое не работает

Июль 2023: Structured Output как отдельное решение

Параллельно появилась библиотека Outlines, она решала другую задачу, как заставить LLM генерировать строго валидных структур
Механика простая, генерировать маски для токенов через logit-bias, блокировать невалидные токены на уровне бэкенда внутри модели

Вышла научная работа "Efficient Guided Generation for Large Language Models", там описали как через Context-Free Grammar (CFG) контролировать генерацию на уровне токенов

Параллельно развивался guidance от Microsoft Research, их guidance реализовала constrained decoding
Она работает очень быстро: ~50 микросекунд на токен через CFG parser с алгоритмом Earley

Вся соль в том что Structured Output, Function Calling и guidance развивались ОТДЕЛЬНО почти год КАРЛ!
Как будто изобрели руль и колёса по отдельности а потом удивлялись почему машина не едет

Ноябрь 2023: JSON Mode не решил проблему

OpenAI добавили JSON Mode, он гарантировал валидный JSON синтаксически, но НЕ гарантировал соответствие schema!
Могли прилететь другие поля, неправильные типы данных

В тот же месяц Anthropic выкатили Claude 2.1с beta версией Tool Use на 200K контекстном окне, у них была та же проблема, аргументы могли быть невалидными

Индустрия билась над одной проблемой, как заставить LLM генерировать валидные аргументы для функций, каждый провайдер решал по своему, единого стандарта не было

Май 2024: Anthropic первыми сделали Tool Use стабильным

30 мая Anthropic объявили что Tool Use стал generally available для всего семейства Claude 3, reliability значительно вырос Проблема с невалидными аргументами почти исчезла, я предполагаю что они видимо встроили аналог Structured Output внутрь Tool Use первыми

Август 2024: 100% reliability достигнут

6 августа OpenAI выпустили gpt-4o-2024-08-06 которая достигла 100% reliability через комбинацию constrained decoding и fine-tuning, до этого gpt-4-0613 показывал меньше 40%

Важный момент: в официальном acknowledgments OpenAI признали что Structured Outputs вдохновлён работами open-source, включая outlines, jsonformer, instructor, guidance и lark

Ушёл ровно год чтобы довести до production-ready, целый год разработчики мучились с невалидными аргументами и писали костыли

Near-zero overhead в JSON generation означало что Structured Output почти не замедляет inference, это сделало технологию production-ready для высоконагруженных систем, интегрировали в MLC-LLM, SGLang, а в январе 2025 в vLLM и TensorRT-LLM на офф уровне

Ноябрь 2024: MCP как решение проблемы N×M интеграций

25 ноября Anthropic анонсировали Model Context Protocol, ответ на проблему что каждый AI агент требовал кастомную интеграцию с каждым data source

Апрель 2025: Google и OpenAI поддержали MCP
Google DeepMind с CEO Demis Hassabis публично подтвердили поддержку MCP, OpenAI тоже анонсировали поддержку протокола, это означало что MCP может стать стандартом де-факто

История трёх технологий которые изменили AI (часть 2/3) (1часть)

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

AI Coding
Deep Research
Data Extraction
Search Assistant

Градация от простого к сложному

AI Coding: когда компилятор не врет

GitHub Copilot используют 77 000+ организаций (90% Fortune 100). Рынок $4.91B в 2024, adoption 97%. Cursor собрал 1M+ пользователей за два года. Devin - результаты лучше 74.2% людей ($500/месяц). Windsurf приобретен за $4B+

Почему первый?
Детерминированная валидация компилятор говорит работает или нет
Action space ограничен edit, create, delete, run tests

Microsoft: рост продуктивности на 26.4% через две недели
Acceptance rate 35% - каждая третья подсказка без изменений
Курсор вообще сделал дичь недавно на RL c acceptance табов

Function Calling для LSP, linters, компиляторов чтения файлов редактирование
MCP для Git, CI/CD, документации

Deep Research: когда час искать ответ

Три игрока выпустили решения почти одновременно: Google Gemini (11 дек 2024), OpenAI ChatGPT (2 фев 2025), Perplexity (14 фев 2025) Все работают одинаково: задача → сбор с десятков сайтов → синтез → report за минуты

Perplexity показывает 93.9% на SimpleQA (фактическая корректность)
На Humanity's Last Exam (100+ предметов) - 21.1% vs 6.2% у раннего Gemini

Проблема: нет ground truth для валидации синтеза
Можно проверить что sources существуют, что citations правильные, но правильные ли выводы?
Пока решают через human-in-the-loop

Cost: 50-150 searches + report на 5-30 страниц = $5-15 за request на GPT-5/Claude4.5

Structured Output для citation tracking каждого факта к source
Function Calling для search APIs, PubMed, ArXiv. MCP для internal knowledge bases, Confluence, SharePoint GDrive

Data Extraction: OCR/VL на стероидах

Современные решения: 95-99% accuracy, 0.5-4 сек на документ based пока не взяли VL

Переход от традиционного OCR к AI-powered. Старый OCR: templates для каждого типа документа, работал на standardized forms, ломался на разных форматах
Новый: LLM-VL, понимают context без templates а если присыпать SO можно извлечь еще больше и контролируемое

Два подхода: OCR engine + VL (Tesseract/EasyOCR → parsing) vs Vision LLM direct (image → data).
Первый дешевле и flexible, второй точнее и быстрее нужно соединять!

Structured Output критичен: output по strict schema для ERP/accounting
Function Calling для OCR APIs, validation. MCP для document management, ERP, accounting software

Search Assistant: RAG для всех

Самый простой технически, самый массовый по adoption

Почему последний по complexity но первый по массовости? Limited reasoning, простая validation (нашел или нет), понятный ROI (saved hour = экономия).

Технически: user query → embedding → vector search → context retrieval → LLM generation → answer с citations

Structured Output для форматирования: ranking, metadata, citations
Function Calling для vector databases (Pinecone, Weaviate), search engines
MCP для simultaneous access: Confluence, Drive, Slack, Jira

Почему такой порядок

Coding → Deep Research → Data Extraction → Search Assistant это текущее состояние и roadmap куда в моей голове бежит весь это снежный ком ИИ

AI Coding лидирует через deterministic validation и я сам оцениваю время которое я за ним стал проводить
Deep Research растет через improved fact-checking
Data Extraction показывает fastest growth благодаря clear ROI
Search Assistant становится commodity feature в каждой SaaS

Это приобретает все больший вайб агентности за счет растущих метрик FC по всем фронтам

Structured Output + Function Calling + MCP это инфраструктура всех четырех доменов

Без SO мы бы парсили невалидный JSON
Без FC агенты не могли бы использовать tools надежно и строить крутых агентов
Без MCP каждая интеграция требовала бы custom code

История трёх технологий которые изменили AI (часть 3/3)

[Часть 1] | [Часть 2]

От технологий к людям

Технологии решены:
- XGrammar дал 100% reliability
- MCP упростил интеграции до registry
- Function Calling стал стандартом

Проблема в трансформации компаний и людей

Что я вижу внедряя AI в компаниях

Компания№1: "Сделайте как ChatGPT для наших данных"
Реальность: 80% времени объясняю что агента нужно учить, он не знает все сам, да и данные у вас не очень

Компания№2: Compliance требует "всегда правильные ответы"
Реальность: учим принимать вероятностную природу AI, строить checkpoints

Компания№3: Разработчики боятся замены
Реальность: превращаем code writers в AI directors роль усложняется, не исчезает
Джуны нужны?

Наблюдения которые не ложатся в метрики:

→ Переход на AI = смена типа людей с исполнителя на менеджера
Не все переживут (вчера ребята на конфе это проговорили)
Цикл "постановка → ожидание → проверка" невыносим для некоторых

→ Tacit knowledge в организациях
Люди не могут четко выразить что знают
Им кажется очевидным, но вытащить крайне сложно

→ Неравенство усилилось
Роль конкретной личности резко возросла (сужу по себе)

→ Сеньоры открытые к AI — искал медь, нашел золото!
Внедрение сверху ("купим подписки и курсы") не работает

→ Разработка сместилась к спекам и верификации
Код генерит AI. Отбирает кайф у тех кто любит писать нужен цикл смены

→ Личная трансформация: куда девать время?
Задачи решаются в 3-5x быстрее. Свободное время появилось, но что с ним делать?
Одни идут глубже в архитектуру, другие теряются

Внедрение AI = структурные изменения = рефакторинг организаций

Технически-культурно-психологические вызовы
Надо думать над всем спектром сразу

---

"Вайб Цех"

Я совместно с red_mad_robot решил организовать "Вайб Цех" в Питере обсудить с вами то как меняется роль человека в разработке
Хотелось собрать небольшое кол-во ребят в оффлайне кто связан с AI
Показать слайды которые накопились
И поделится с вами своими мыслями
Давайте разлогинемся на один день!
Буду весь день на площадке

Обсудим трансформацию 25 октября

Не про фреймворки
Про людей

Программа:
- 10:00 — Я: от писателя кода к AI-дирижеру
- 10:20 — Саша Абрамов (SberAI): почему LLM так хороши в программировании
- 11:00 — Макс Скорченко: как перестать работать и начать управлять
- 12:00 — Секретный production case
- 12:40 — Панель: место человека в системе с AI (модерирую) СберТех, Cloud.ru и SberAI

Обсудим практически:
- Куда девать время когда продуктивность выросла в 3-5x
- Как вытащить tacit knowledge из команды для агентов
- Кто справляется с переходом исполнитель→менеджер, а кто нет
- Реальные кейсы внедрения без теории

📍 Not Bad Loft, Курляндская 48, СПб
📅 25 октября, 10:00-15:00
🎟 https://red-mad-robot.timepad.ru/event/3605115/

Offline (платно, личное общение + кейтеринг и классный лофт)

Online free link

После 15:00 — нетворкинг, разбираем ваши кейсы

P.S. Пишите в комментах: какие проблемы трансформации видите в командах?
Соберу для панельной дискуссии

#llm #petproject

SGR Deep Research топ 3 в open-source!

Пока кипит работа по финализированнию наших тестов и выявлению лучшей архитектуры агента для небольших и недорогих моделей

Хочу с вами поделится очень крутыми новостями!

Бенчмарк и новые фичи!

Что было сделано:
1) Был добавлен MCP как клиент (теперь вы можете подключить любой набор тулов внутрь агента)
2) Проработаны и оптимизированы промпты для читаемости и понимания LLM

<MAIN_TASK_GUIDELINES>
<DATE_GUIDELINES>
<CORE_PRINCIPLES>
<REASONING_GUIDELINES>

3) Проработаны докстринги у каждого тула
Осмысленные и протестированы description

4) Использован гибридный подход: агент строится на концепции SGR и подходах ReAct+PlanAct, также был применён чистый Function Calling (со схемой решения можно ознакомиться в комментариях под постом)

5) Я разнес тул вэб поиска на /search и /extract

5) Я лично провел огромное кол-во экспериментов по созданию разных tool_kit для проверки агента

Самое важное этот агент sgr_tools_agent.py мой личный фаворит для использования моделей по типу
gpt-4o-mini
gpt-4.1-mini
И схожих им по размеру (как говорит интернет это что-то в районе 40-80b)

Сначала мы занялись поиском бенчмарка, на котором можно протестировать SGR Deep Research
Выбирали из: BESPOKE, FRAMES, MS MARCO, SimpleQA, SealQA
Остановились на SimpleQA так как хотелось проверить возможности агента на поиск фактов!

Нашим ориентиром стал лидерборд из репозитория фреймворка ROMA, в нем приведено сравнение точности различных LLM на SimpleQA, встроенных в поисковый движок

Тестовый прогон на SimpleQA Verified

Перед запуском на SimpleQA (4326 вопросов/ответов)
решили провести тестирование на урезанной версии SimpleQA Verified (1000 вопросов/ответов).

Для оценки правильности ответов мы использовали подход LLM-as-a-judge, где в качестве судьи выбрали gpt-4o

Для старта в качестве агента для SGR Deep Research взяли sgr_auto_tool_calling_agent.py,
Точность оценивали у двух LLM: gpt-4.1-mini и gpt-4o-mini.

Результат на SimpleQA Verified получили следующий:
gpt-4.1-mini → Accuracy: 0.792
gpt-4o-mini → Accuracy: 0.705

Вывод: gpt-4.1-mini оказался точнее
А режим auto мешал агенту и превращал его в чатбота, такое нам не надо

С ним идем на полный SimpleQA но убираем режим auto у тулов и переключаемся в required sgr_tools_agent.py.

Оценка SGR Deep Research на SimpleQA

В качестве LLM выбрали gpt-4.1-mini, а в качестве агента - sgr_tool_calling_agent.
Произвели все изменения что я описал выше учитывая незначительные дополнительные правила и указания
(фититься под бенчмарк не хотелось бы как ROMA)

Результат бенчмарка получили следующий:
gpt-4.1-mini → Accuracy: 0.861

Таким образом, опираясь на лидерборд из ROMA, мы смогли занять 7 место среди общего списка, а также 3 МЕСТО среди open-source решений на недорогой модели и самом базовом поиске от Tavily!
Если быть честными на gpt-4.1-mini это первое место так как был использован Tavily Basic (с ограничением на экстракт в 33к символов, что сильно экономит токены)

Более подробное описание параметров запуска, а также результатов тестирования мы выложили репозиторий

Тут есть все
Коды запуска
Коды от Зиона =)
LLM-as-a-judge
Таблица с ответами

Кстати мы не поленились и собрали полный лог каждого прогона можно посмотреть тут
Так что теперь можете не только брать данное решение как лишенное готовых агентных фреймворков,
так и доказать перед командой точность результатами бенчмарка!

Отдельное спасибо нашей open-source команде которая смогла реализовать это:
Ревью кода - Артём
Координирование - я
Подготовка данных и реализация логики тестирования: Максим
Паша наш MCP гуру
Ринат собирает кейсы, и распространяет проект на EN уровне!


Цифры:
232 млн токенов
8к запросов на /search
1200 запросов на /extract

Полный тест такого бенчмарка обошелся в $170

Далее мы планируем оценить работу агента уже на локальных LLM

Репо: https://github.com/vamplabAI/sgr-deep-research

P.S замену tool calling не нужно делать!
Но если очень хочется можно
Мы всех слышим и умеем читать пейперы =)

#cv #llm #petproject

Рейтинг моделей по распознаванию англоязычных документов

Для сравнения выкладываю рейтинг по английским документам. По нему видно, что в среднем распознается 82% информации, тогда как для русскоязычных текстов - это 68%. Конечно, не совсем корректно их сравнивать, но это хотя бы что-то.

Метрики из таблицы:

Извлечение ключевой информации (KIE): Оценка способности извлекать структурированную информацию из документов
Визуальные вопросы и ответы (VQA): Проверка понимания содержимого документа через вопросы
Оптическое распознавание символов (OCR): Измерение точности распознавания текста в различных типах документов
Классификация документов: Оценка возможностей категоризации
Обработка длинных документов: Оценка производительности на объёмных документах
Извлечение таблиц: Проверка понимания и извлечения табличных данных
Оценка достоверности: Измерение надёжности и калибровки прогнозов модели

Еще есть интересная колонка "цена" в центах. Gemini-flash - в топе по этому параметру

#database #systemdesign

#llm #interview

#llm #cv #search #petproject

#llm #petproject #agents

Написал на Хабре небольшой туториал, как запилить простой пример MCP-сервера.

Разработка MCP-сервера на примере CRUD операций

Model Context Protocol (MCP) это такой единый протокол, который описывает как создавать API сервисов, с которыми могут взаимодействовать LLM.

#rag #llm

#RAG #retriever

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

Сами по себе LLM уже умеют обрабатывать цепочку сообщений (ее также называют диалог или беседа) - для этого надо использовать Chat Templates (https://t.iss.one/llm_is_all_you_need/62). Но ее нельзя просто так подать в RAG.

Рассмотри такой пример беседы с LLM:

- Вопрос: Как звали жену Цезаря?
- Ответ: Корнелия Цинилла.
- Вопрос: А его детей?

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

Чтобы это исправить нам нужно предварительно трансформировать последний вопрос примерно в такой вид: Как звали детей Цезаря?.

В этом нам поможет LLM:
1. Получаем цепочку сообщений.
2. Просим LLM переформулировать последний вопрос.

messages = [
    {"role": "user", "content": 'Как звали жену Цезаря?'},
    {"role": "assistant", "content": 'Корнелия Цинилла.'},
    {"role": "user", "content": 'А его детей?'},
    {"role": "user", "content": 'Выше история переписки в чате и последний вопрос пользователя, который может касаться контекста в этой истории. Переформулируй последний вопрос так, чтобы его можно было понять без истории чата. Постараяся максимально сохранить слова из исходного вопроса. Если вопрос понятен без контекста - напиши его без изменений.'}
]

3. Этот единственный переформулированный вопрос (и только его) подаем в ретривер, где он превращается в вектор и по нему ищутся чанки.
4. Дальше работаем как обычно.

Паттерны и анти-паттерны использования паттерн-матчинга в Питоне

Наткнулся на доклад про паттерны паттерн-матчинга 😁 и мне он понравился: Patterns and Anti-Patterns in Python's Structural Pattern Matching
Доклад очень понравился, несмотря на то, что паттерн-матчингом я пользуюсь с самого его появления (кажется в 3.10), я подчерпнул полезное для себя. Что понравилось? Последний пример, где Brett показывает обработку semi-structured JSON. Я вспомнил, что часто внешние API могут возвращать разный формат JSON в зависимости от состояния, но мне в голову никогда не приходила идея обернуть обработку этого в match/case.

Элегантно! 💡