Коммуникация Agent <-> Agent : чем полезна и куда развивается

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

Например, онбординг нового сотрудника, которому нужно создать учетную запись, выдать доступы, завести почту и познакомить его с документацией.

В простом случае этим управляет агент-оркестратор: он поочередно вызывает агентов, передаёт им входные данные и собирает результат.

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

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

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

— Управление заданиями. Агент получает задачу, отслеживает её статус и возвращает результат — артефакт. Если задача длительная, агенты синхронизируют статусы и сохраняют контекст.

— Коллаборация. Агенты могут передавать друг другу инструкции, промежуточные артефакты, ответы и контекст. Это позволяет выстраивать сложные цепочки действий.

На 2025 год уже существуют протоколы, реализующих эти принципы. В свежем обзоре исследователей из университета Shanghai Jiao Tong проведено детальное сравнение и категоризация таких протоколов (и не только).

Наиболее нашумевшие в последнее время:

A2A от Google — протокол и библиотека ADK, ориентированные на промышленное применение. ADK доступен на GitHub и позволяет быстро строить системы взаимодействия агентов на основе A2A.

ACP от IBM — так же протокол взаимодействия агентов между собой, который немного отличается от A2A выбором технологий и форматом общения агентов.

Главная проблема всех протоколов на данный момент — отсутствие широкого adoption в индустрии, и как следствие, фрагментированность в сообществе.

В интеграции LLM с внешними системами роль стандарта уже выполняет MCP и на наш (и не только) взгляд может в будущем стать основой стандартизации даже и в системах агентного взаимодействия.

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

#игорь_латкин #MCP #Agents

Главная проблема агентов: прототип сделать просто, а работающую систему на порядок сложнее

Когда мы работаем с ChatGPT, мы общаемся с ним как с ассистентом: задаём вопрос, получаем ответ, берём нужное, игнорируем лишнее. Если ответ не тот — переспрашиваем или корректируем.

Примерно то же самое происходит и при создании прототипа. Загружаем данные, смотрим, как отвечает система, убеждаемся, что «в целом работает» — и на этом этапе говорим, что прототип готов. При этом часто игнорируем ошибки, потому что в прототипе они кажутся незначительными.

Даже если система ошибается в 1 случае из 100 и точность правильных ответов — 99%, оставшийся 1% может нанести репутационный ущерб. А подобных типов ошибок может быть много.

Например: в 2023 году делали ИИ чат-бота для магазина. Клиент спрашивает у бота: «Где находится ближайший магазин?», а бот галюцинирует, ошибается с адресом, клиент приходит — магазина нет.

Поэтому требования к качеству резко возрастают, и простой «работающий прототип» уже не подходит. Исходя из этого, существует 2 стратегии внедрения:

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

Сработать такая система может только там, где цена ошибки низкая.

Пример: бот, который продаёт бетон. Его задача — взять телефон и проконсультировать для дальнейших продаж. Он может ошибиться с деталями доставки, но в среднем даёт больше конверсии, чем человек за счёт скорости ответов.

2. Автоматизированная система с участием человека.
ИИ предлагает ответ, но окончательное решение принимает человек. Во 2 стратегии мы рассматриваем ИИ как ассистента. Он находит информацию, формирует готовый ответ. Человек может принять ответ, изменить или отклонить. Все действия логируются и накапливаются данные: вопросы, ИИ-ответы, поддержки, рейтинг удовлетворенности пользователя. На основании данных дообучаем систему: переписываем промпты, файнтюним модели, меняем архитектуру и тд.

Со временем человек всё реже редактирует ответы. Когда процент автоматических решений стабильно высокий и не уступает качеству работы оператора — только тогда возможен переход к первой стратегии и полной автоматизации.

Коллеги из Сбера пошли по второй стратегии: внедрили ассистента поддержки, который сократил среднее время ответа на 20% , а не пытались заменить операторов полностью.

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

#александр_опрышко

Почему корпорации не любят n8n?

n8n — ноукод-инструмент для сборки LLM-агентов и интеграционных сценариев без программирования.

Но с точки зрения корпоративного внедрения у него есть серьёзные ограничения:

— Нет версионирования. В open source-версии нельзя отслеживать изменения и безопасно откатываться к предыдущим версиям.

— Нет поддержки уровня энтерпрайз. Компании хотят сопровождение, но вендоров, которые умеют эксплуатировать n8n, почти нет.

— Вендор-лок.Если он не подойдёт, перенести сценарии на что-то другое не получится, нужно будет переделывать.

— Сложное логирование. Агентная архитектура требует прослеживать шаги выполнения. Из коробки n8n этого не умеет. В коде трейсинг и логирование сделать проще.

— Ограниченные возможности для кастомных сценариев. Разработчику зачастую проще и быстрее реализовать логику на LangChain, чем собирать её в интерфейсе n8n.

Тем не менее, для Agent Platform мы сознательно выбрали n8n как один из «агентских фреймворков».

Несмотря на ограничения, такие инструменты нужны для массового использования в продуктовых командах. Продуктам, аналитикам, маркетологам важен простой способ быстро проверить гипотезу: можно ли переложить текущий процесс на LLM. Если можно — появляется рабочий прототип, с которым уже есть смысл идти к инженерам. Они смогут превратить его в продакшен-решение с метриками.

Пример: генерация рекламных изображений.
LLM умеют генерировать картинки, но дизайнеру важно ещё адаптировать их под разные площадки и бренд-гайдлайны. Вместо долгого цикла с ресерчем и итерациями от разработчиков, он может сам собрать прототип в n8n, потестировать гипотезу — и только потом подключить инженеров. Тогда они уже перенесут это решение в продакшен, готовый к масштабированию.

Наша практика внедрения агентов показывает, что придумывать промты должен product owner. А задача инженера — сделать так, чтобы результат, который получил product owner в режиме прототипа, стал стабильным.

Поэтому мы даем n8n в руки product owner”ов, помогая им разобраться в инструменте, а потом переносим результат прототипа на n8n в промышленное решение руками инженеров, которые доводят качество и воспроизводимость до нужного уровня.

n8n даёт быстрый результат — и этого достаточно, чтобы начать. Это гибкий agile-подход. Он помогает командам запускать инициативы с ИИ быстрее и внедрять LLM в реальную работу.

#александр_опрышко #n8n

LLM-независимый подход: как снизить риски и расходы на внедрение ИИ

На рынке уже доступны state-of-the-art модели от OpenAI, Anthropic, Google и других разработчиков. Они отличаются по качеству, размеру и стоимости эксплуатации. Но в российских реалиях решения малодоступны из-за ограничений по безопасности и требованиям к инфраструктуре. Нужно использовать облачные решения вроде Яндекса и Сбера или разворачивать open source модели в своем контуре.

Часто на старте внедрения ИИ Агентов у команды есть только набор гипотез, но нет понимания, реально ли воплотить идею на доступных в России моделях, и насколько трудоемко реализовать инициативу.

Есть два базовых варианта, что можно делать на старте внедрения:

1. Сразу начинать с дешёвой, локальной open source модели.
Риск — потратить много времени, чтобы заставить систему работать. Если задача сложная, система может не справиться.

2. Сначала использовать лучшую доступную модель.
Протестировать гипотезу на публичных данных, быстро понять, достижим ли нужный результат. Если не получается на лучших моделях за короткое время — не стоит тратить ресурсы дальше и инвестировать в переезд на доступные модели. Рассмотрите другие инициативы, которые дадут быструю победу. Если результат вас устраивает — можно пробовать решить задачу компании open-source моделями или моделями, которые доступны в российских облаках.

Для этого нужно итерироваться по доступным моделям, опираясь на данные и метрики:

— Выбираем топовую модель для тестирования гипотезы. На публичных данных строим прототип и определяем метрики качества (про метрики качества ответов расскажем в следующем посте).

— Добиваемся стабильных метрик. Ответы прототипа доводим до стабильных метрик и проверяем репрезентативность: если ответ плохой — метрики плохие, хороший — хорошие.

— Итерируемся вниз по моделям. Постепенно заменяем модель на более дешёвую/маленькую. Оцениваем, как это влияет на метрики. Если результат сохраняется — продолжаем и брем модель еще дешевле. Если качество падает — адаптируем систему.

— Находим оптимальный баланс. Останавливаемся там, где сходится экономика процесса: оптимальный трейд-офф между количеством усилий для достижения результата и ценой инференса (генерации токена).

Для пошаговой итерации нужен гибкий инструмент, чтобы переключаться между моделями без изменений в логике приложения.

Один из таких инструментов — LiteLLM, который предоставляет унифицированный API и поддерживает разные LLM-провайдеры.
А для автоматизированной оптимизации агентов советуем DSPy.

Внутри Agent Platform мы добавили LiteLLM, который подключен к российским, американским и китайским провайдерам, чтобы можно было гибко менять модели подходы к оценке качества.

#александр_опрышко #llm

Как оценивать качество ответов LLM: подходы и практики

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

Существует несколько подходов к оценке качества ответов модели:

1. Ручная экспертная оценка.
Ответы проверяют эксперты (либо доменные специалисты, либо команда QA) на тестовом датасете запросов. Высокая человеческая точность, можно учитывать контекст задачи. Но дорого, медленно и плохо масштабируется.

2. LLM-as-a-Judge
Оценку ответа делает та же или другая LLM. Быстрый и масштабируемый подход. Но возможны систематические смещения (bias), нужно выборочно валидировать результаты вручную. Примеры фреймворков: RAGAS, Deepeval.

3. Автоматические метрики
Метод сравнения ответа модели с эталонным («ground truth») с помощью алгоритмов. Быстро, объективно, но не отражает «человеческое» восприятие, нужны размеченные датасеты. Примеры метрик: BLEU, ROUGE.

4. Оценка в боевых условиях
Сбор метрик после запуска в продукт. Реальные данные, отражает влияние на бизнес. Но сложно изолировать влияние LLM от других факторов. Метрики: доля исправленных или повторных запросов, CTR и конверсия (если LLM влияет на UX), пользовательские рейтинги (лайк/дизлайк).

Мы рекомендуем комбинировать оценки и использовать следующий пайплайн:

1) Получить обратную связь пользователей в продакшне
Собираем репрезентативный набор запросов: частые кейсы, критические кейсы, граничные условия.

2) Отправить выборку на LLM-as-a-Judge.
Прогоняем тестовый набор и сохраняем все ответы с метаданными. Используем готовые метрики DeepEval и кастомные для оценки каждого ответа. Храним результаты запусков в Langfuse.

3) Отдать на оценку экспертам подозрительные кейсы.
Они подтвердят или скорректируют оценку, найдут случаи, где модель системно ошибается.

4) Проанализировать ошибки и итеративно улучшать модель
Выделяем группы возможных проблем. С начала исправляем критические и массовые ошибки. Затем повторяем запуск на том же датасете для сравнения с прошлой версией.

#александр_опрышко #llm

Вебинар-интервью: Этап Discovery — с чего начать внедрение генеративного ИИ

17 сентября в 11:00 в гости к Внутри AI придет Дмитрий Твердохлебов, экс-директор по ИИ в МТС и VK, эксперт с 15-летним опытом внедрения цифровых продуктов.

Интервью проведет Александр Опрышко, сооснователь и управляющий партнер KTS.

В формате диалога обсудим, как подойти к внедрению генеративного ИИ и какие результаты можно ожидать.

На вебинаре вы узнаете:

- где ИИ принесет пользу бизнесу, а где его внедрение не оправдано;
- какие артефакты необходимы для старта;
- каким должен быть definition of ready пилотного проекта;
- что делать в компании без собственного AI-подразделения;
- как будет развиваться рынок и на что стоит обратить внимание.

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

Ссылка для подключения появится в канале перед началом вебинара.

Задавайте вопросы под этим постом — спикеры обязательно на них ответят.

В ожидании вебинара познакомьтесь с кейсами внедрения ИИ — они помогут лучше разобраться в теме.

Вот некоторые ресурсы, где можно посмотреть примеры:

Evidently AI — агрегатор с 650+ кейсами и удобной системой ссылок.

GenAI & LLM System Design — расширенная библиотека технических кейсов на GitHub, созданная на базе Evidently AI.

Generation AI — (российские кейсы) небольшая, но полезная библиотека кейсов от JustAI.

Если какие-то из кейсов покажутся особенно интересными или у вас возникнут вопросы, оставляйте их в комментариях, обсудим вместе на вебинаре.

Что такое Langfuse?

При разработке сервисов на базе LLM или multi-agent систем наблюдаемость — ключ к контролю. Без мониторинга система остаётся “чёрным ящиком”. Невозможно понять, какие запросы поступают, как отвечает модель, сколько стоит каждый вызов и где происходят ошибки.

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

Существуют разные решения мониторинга:

• Langfuse — open-source платформа для трейсинга, мониторинга и оценки качества LLM-запросов. Активно развивается, есть поддержка SSO в open-source версии.
• LangSmith — продукт от авторов LangChain, закрытый, с глубокой интеграцией в их экосистему. Функционально близок к Langfuse.
• Phoenix by Arize — open-source, менее популярен, сопоставим с Langfuse.
• MLflow — реализовали поддержку работы с LLM инструментами, функционал беднее по сравнению с langfuse, но стоит рассмотреть, если в компании уже эксплуатируется MLflow.

Для Agent Platform мы выбрали Langfuse как наиболее подходящий инструмент для построения пайплайна разработки ИИ-агентов. Платформа поддерживает логирование каждого шага — от входного промпта до ответа модели, включая использование инструментов.

В продакшене Langfuse помогает выявлять нестабильные промпты, сравнивать версии агентов и анализировать метрики качества. В ресёрче — тестировать гипотезы и сравнивать подходы на датасетах.

В следующих постах расскажем про ключевые компоненты Langfuse.

#александр_опрышко

Из чего состоит Langfuse?

Langfuse — платформа для отслеживания и оценки работы LLM-агентов. В основе — пять компонентов:

Traces & Observations
Трейс — лог одного запроса. Внутри: шаги агента, вызовы инструментов, ответы модели. Помогает понять, как агент «думает» и где ломается цепочка.

Sessions
Объединяют трейсы в одно взаимодействие — например, целый диалог. Удобно смотреть не отдельные шаги, а поведение агента в целом.

Scores
Оценки — это различные метрики: точность ответа, успешность, тип ошибки. На них строятся сравнение версий и автооценка.

Datasets & Dataset Runs
Датасеты — входы с эталонными ответами. Dataset Run — их запуск через агента с сохранением логов. Помогает тестировать изменения и сравнивать качество.

Prompts
Централизованное хранилище промптов: версии, параметры, история. Можно тестировать варианты, быстро откатываться и отслеживать изменения.

Как выглядит цикл разработки агента с Langfuse

1. Собираем датасет из типовых запросов и эталонов.
2. Запускаем Dataset Run, фиксируем трейсы.
3. Анализируем шаги агента (Traces & Observations).
4. Ставим оценки — автоматически (LLM) и вручную.
5. Меняем промпт или логику, запускаем снова.

Такой подход заменяет хаотичное «подкручивание промптов» системной работой с метриками, тестами и контролем качества.

#александр_опрышко

Уже скоро — вебинар «Этап Discovery: с чего начать внедрение генеративного ИИ».

17 сентября, 11:00 в прямом эфире встретятся Дмитрий Твердохлебов, экс-директор по ИИ в МТС и VK, и Александр Опрышко, сооснователь и управляющий партнер KTS.

Вместе обсудим ключевые вопросы старта:
– в каких задачах ИИ дает ощутимую пользу, а где не нужен;
– какие артефакты готовить к пилоту;
– что делать, если в компании нет AI-команды;
– как выглядит готовность к запуску (definition of ready);
– как меняется рынок и на что важно смотреть уже сейчас.

Формат — интервью и ответы на ваши вопросы.

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

Добавляйте напоминание в календарь и до встречи на вебинаре. Ссылка появится в канале перед началом.

Опыт Uber: как автоматизировать обработку счетов с помощью GenAI

Uber ежедневно обрабатывает тысячи счетов от поставщиков. Несмотря на RPA и платформу самообслуживания, большая часть документов требовала ручной обработки. Проблемы: высокая нагрузка, ошибки, ограниченная масштабируемость.

Для решения этих задач внедрили систему на базе GenAI, объединяющую OCR, LLM и постобработку. В основе — внутренняя платформа TextSense.

Как происходит обработка:
1. Поставщик отправляет счёт (PDF) через email или платформу.
2. Счёт попадает в TextSense, где проходит:
— извлечение данных (OCR + LLM),
— валидацию (правила + проверка человеком),
— интеграцию с ERP для оплаты.

Система поддерживает разные шаблоны, языки, сканы и многостраничные документы.
Тестировали seq2seq, Flan T5, Llama 2 и GPT-4. Выбор пал на GPT-4 — она стабильно извлекала нужные данные из документа, не полагаясь на заранее заданные шаблоны.

В результате Uber сэкономил до 30% затрат на процессе обработки счетов: на 50% меньше ручного труда, при этом точность не пострадала.

Завтра, 17 сентября в 11:00 — вебинар «Этап Discovery: с чего начать внедрение генеративного ИИ».

Дмитрий Твердохлебов и Александр Опрышко обсудят, где ИИ приносит реальную пользу, что нужно для пилота и как понять готовность к запуску.

Ссылка для подключения.

До встречи!

Стартуем вебинар «Этап Discovery: с чего начать внедрение генеративного ИИ».

В эфире — Дмитрий Твердохлебов, экс-директор по ИИ в МТС и VK, и Александр Опрышко, сооснователь и управляющий партнер KTS.

Подключайтесь по ссылке.

Делимся записью вебинара «Этап Discovery: с чего начать внедрение генеративного ИИ».

На встрече Дмитрий Твердохлебов и Александр Опрышко обсудили, где ИИ действительно приносит пользу бизнесу, какие артефакты нужны для старта, что делать компаниям без AI-команды и как оценить готовность к запуску пилота.

Смотрите запись на наших площадках:

YouTube
VK
Rutube

LLM-as-a-Judge для RAG: практический разбор

В прошлых постах мы уже рассказывали о том, как оценивать качество ответов LLM. Теперь подробнее разберём подход LLM-as-a-Judge (LAJ) — когда модель используется как «оценщик» ответов другой (или той же) модели по заданному рубрикатору критериев (relevance, faithfulness и др.). Этот подход закрывает разрыв между автоматическими метриками и ручной разметкой, что особенно важно для открытых задач — чатов, суммаризации и RAG.

Какие есть фреймворки?

DeepEval
Open-source фреймворк «как PyTest для LLM» с 40+ готовыми LAJ-метриками. Поддерживает метрики для RAG, диалогов, агентов, безопасности, а также универсальные кастомные G-Eval/DAG-метрики.

Исходный код всех метрик можно посмотреть здесь, они просто устроены и можно быстро разобрать логику их работы. Про то, как и когда применять метрики можно почитать в документации.

Если стандартные метрики не подходят, то стоит рассмотреть G-Eval и DAG Metric.

Есть альтернатива — Ragas — специализированная библиотека для оценки RAG с отдельным фокусом на ретривер и генератор.

В нашей практике мы используем DeepEval как более полноценную и готовую библиотеку для оценки работы LLM. По ссылке авторы DeepEval объясняют различие с Ragas.

Ниже пример одного из наших сценариев разработки RAG

Шаг 1. Автогенерация датасета (QAG). Документ разбиваем на чанки. Для каждого куска LLM генерирует вопрос и эталонный ответ (Q→A), полученный из контекста. Кортеж вопрос–ответ–контекст отправляем в Langfuse

Шаг 2. Ручная проверка в Langfuse. Отправленные в Langfuse кортежи валидируем с помощью ручной разметки. Отбираем несколько сотен корректных примеров.

Шаг 3. Запуск оценок. На основе сформированного golden set запускаем оценку разработанного RAG по метрикам:
Retriever: DeepEval — Contextual Precision / Recall / Relevancy.
Generator: DeepEval — Answer Relevancy, Faithfulness.

Шаг 4. Контур улучшений
Сохраняем скоры в Langfuse (Scores / Dataset Runs), сравниваем промпты и модели, внедряем улучшения в RAG.

#александр_опрышко

Официальный MCP Registry?

В начале сентября команда, занимающаяся разработкой Model Context Protocol анонсировала запуск собственного реджистри. Разбираемся, чем он отличается от уже существующих.

Если понаблюдать, то с момента анонса MCP в ноябре прошлого года запустилось много реестров MCP-серверов:

— smithery.io
— mcp.so
— MCP Market
— Docker MCP Catalog
— Cursor MCP Registry
— GitHub MCP Registry
— даже реестр реестров

Так чем же примечателен запуск нового реестра от команды MCP? На мой взгляд 3-мя вещами:
1) Это официальный реестр в виде API от команды-разработчика протокола.
2) Новый проект унифицирует доступ к существующим реестрам под открытым API.
3) Цель реестра — стать динамическим каталогом для MCP-клиентов.

Первые два пункта понятны. Разберёмся с третьим.

Из описания места реестра в экосистеме понятно, что его основная цель — анонсировать, что где-то доступен MCP-сервер: в PyPI, NPM, DockerHub или просто развернутый по HTTP Streaming, который можно запускать определённым образом.

Ключевым является то, что MCP-клиенты, такие как Cursor, Claude Code, ChatGPT и другие, при должной поддержке могут автоматически найти подходящий под запрос пользователя MCP-сервер, самостоятельно его установить, настроить и осуществить через него запрос.

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

Кроме того, этот проект — опенсорсный и компании могут совершенно спокойно запускать собственные внутренние MCP-реестры, дав сотрудникам прямой и единообразный доступ к MCP-серверам компании.

В общем, конечно, пока, никакой революции не случилось, но в любом случае — очень интересно наблюдать и пробовать уже сегодня.

#игорь_латкин #mcp

Что такое DSPy?

Классический промпт-инжиниринг порождает неустойчивые пайплайны. Поведение системы зашито в строки, а интерфейс задачи смешан с формулировкой промпта. Поэтому любое изменение — модели, метрики или последовательности шагов — требует ручного редактирования. В итоге снижается переносимость, тестируемость и воспроизводимость.

DSPy решает эту проблему. Он строится на обратном принципе: итерации по структурированному коду, а не по строкам. Система чётко разделяет интерфейс («что должен делать LM») и реализацию («как ему это сказать»). Код “компилируется” в эффективные промпты и веса.

В DSPy есть три компонента:

• Signatures — декларативно описывают входы и выходы задачи («что нужно получить»).
• Modules / Programs — из отдельных блоков собирается весь пайплайн.
• Optimizers — алгоритмы, которые под задачу и метрику подбирают оптимальные инструкции, примеры и веса.

Как DSPy «автоулучшает» промпты?

Упрощая, вы задаёте датасет примеров и функцию-метрику. Оптимизатор генерирует варианты промптов, оценивает их по выбранной метрике и итеративно выбирает лучший. В итоге текст промптов превращается в воспроизводимую процедуру оптимизации.

Например, как на DSPy определить сентимент текста (положительный или отрицательный отзыв)

1. Описание задачи (Signature)

sentence -> sentiment: bool
где True — положительный отзыв, False — отрицательный.

2. Метрика
Для простой классификации используется Exact Match — функция, которая сравнивает предсказания модели с эталоном и возвращает числовую оценку (чем выше, тем лучше).

3. Оптимизация
Оптимизатор получает классификатор (text -> sentiment), метрику (Exact Match) и небольшой train/dev-сет.
DSPy автоматически тюнит промпты, чтобы максимизировать метрику.

Разработчику не нужно писать, как агент должен определить тональность текста.
Достаточно задать датасет, метрику и направление поиска решения — оптимизатор сам подберёт конфигурацию.

С более сложными задачами принцип тот же.
В качестве метрики можно использовать LLM-as-a-Judge и собирать многоэтапных агентов.

#александр_опрышко

Представляем TokenGate: Единый API к популярным LLM

Мы видим, как бизнес строит AI-продукты, и знаем, какие вызовы встают перед IT-командами и CPO. За последние годы мы все столкнулись с одной и той же сложностью: SOTA-модели разбросаны по десяткам провайдеров, каждый со своим API-форматом, SDK и не всегда удобной и доступной оплатой из РФ.

В рамках Agent Platform мы выпустили TokenGate: Единый API к популярным LLM — Единое API для моделей от Anthropic, OpenAI, Google, Yandex и Cloud с оплатой из России.

▫️Единый API-формат. Получите доступ ко всем ведущим моделям (OpenAI, Anthropic, Google, Meta и 50+ других провайдеров) через единственный API Endpoint в привычном OpenAI-формате.

▫️Гибкость и скорость. Переключайтесь между 265+ моделями (включая Claude 3.5, Gemini 2.5, GPT-5 и Llama 3.1) за секунды, не меняя логику своего приложения. Это чистая power-play для ваших экспериментов и продакшн-задач.

▫️Мониторинг. Полный контроль и прозрачность расходов токенов в едином интерфейсе. Оплачивайте только фактически использованные токены.

▫️Простой доступ. Мы закрываем вопрос с оплатой из России. Расчеты с российским юрлицом, оплата по счету или картой. Ваш AI-бюджет становится прозрачным и безопасным.

Регистрируйтесь, создайте свой API Endpoint и протестируйте самые актуальные LLM на своих задачах. 👉 Получить доступ к TokenGate