Делимся записью вебинара «Этап 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

Быстрое решение с LLM: доступ к аналитике Redash через чат-бота

Сделали инструмент, который упрощает работу менеджеров с данными.

Redash — система аналитики, которая строит графики и отвечает на запросы к базам данных. Вместо SQL-запросов к системе можно задать вопрос через бота: «сколько пользователей зарегистрировалось?» или «какие продуктовые метрики можно собрать по базе».

Бот сам обращается к API, строит корректные SQL-запросы и возвращает результат. Для тех, кто не уверен, какие именно данные нужны, бот сканирует структуру базы и предлагает релевантные метрики.

Такой подход снижает барьер входа в аналитику: менеджеры получают доступ к ключевым показателям без участия аналитиков или разработчиков.

Новинка от OpenAI

Лучше поздно, чем никогда. Рассказываем:
OpenAI представила Prompt Packs — свыше 300 шаблонов промптов для конкретных ролей (разработчики, HR, маркетологи, продавцы и др.) Рабочие промпты под повседневные задачи: письма, анализ, планирование, код, скрипты переговоров.

Зачем это сегодня:

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

- Стандарты для команды: одна библиотека промптов снижает разброс качества и ускоряет онбординг.

Забирайте и адаптируйте под свой стек задач: клик

Подборка полезных AI ресурсов, которые дадут и базу и практику.

Впереди длинные выходные, делимся, что можно почитать/посмотреть по теме AI, чтобы провести их с пользой.

▫️Agentic AI от Andrew Ng (очень известный автор блестящих курсов по ML). Курс с четырьмя ключевыми паттернами: рефлексия, использование инструментов, планирование, мультиагентность. Код — на чистом Python, с акцентом на эвалах и анализе ошибок. На выходе — полнофункциональный research-agent.

▫️Stanford CME295 (Transformers & LLMs). Лаконичный курс, который охватывает фундамент трансформеров и прикладные темы: RAG, LLM-as-a-judge, квантизация, Mixture-of-Experts. Подойдёт, если хотите быстро систематизировать знания и обновить стек.

▫️Хабр: «Как я победил в RAG Challenge». Если разрабатывайте свой RAG, рекомендуем почитать, как спец выиграл челлендж. Подробный разбор рабочего пайплайна с кодом: парсинг, ретривал, роутинг, реранкинг, промпты. Можно адаптировать под свои данные.

Вас уже больше тысячи! 🔥

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

Один из авторов канала — Александр Опрышко, сооснователь и управляющий партнёр IT-компании KTS. Саша в этой сфере с подросткового возраста: в 14 лет поступил в МГТУ им. Баумана, в 18 уже работал в Mail.ru, а в 2015 году вместе с одногруппниками основал KTS. Сегодня компания создаёт цифровые сервисы для бизнеса в разных направлениях, в числе которых AI.

Александр отвечает за технологическое развитие и новые направления. Под его руководством KTS запускает продукты и внедряет подходы, которые помогают бизнесу работать быстрее и надёжнее. Среди ключевых инициатив:

• запуск направления MLOps, которое ускорило развертывание ML-моделей с месяцев до дней;
• внедрение ИИ-агентов в платформу Smartbot, что позволило клиентам платформы автоматизировать коммуникацию с их клиентами и техническую поддержку;
• развитие No-code-облака в Smartbot — теперь пользователи могут разворачивать инструменты и собирать свои бизнес-процессы без администрирования;
• запуск платформы — Agent Platform.

В следующих постах расскажем про второго автора канала, Игоря Латкина.

Спасибо, что вы с нами!

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

Как оценить агентскую систему?

Агентскую систему удобнее рассматривать как pipeline из шагов. Поэтому одной метрики success rate недостаточно: нужны два уровня оценки: качество каждого шага и итоговое поведение end-to-end.

1. Оценка каждого шага. Для каждого этапа определяем, что значит «хорошо», и задаём метрики.
Оценка шага даёт прозрачную зону ответственности и упрощает дебаг.

2. End-to-end оценка. End-to-end показывает, насколько система полезна бизнесу.
Например, лайк/дизлайк пользователя или ручная разметка.

Пример: упрощённая агентская система, RAG как двухшаговый агент

Шаг 1: retriever. Tool call к векторному индексу или поиску для получения контекста.
Шаг 2: LLM. Генерация ответа на основе retrieved context.

Даже в таком pipeline нельзя ограничиться одной метрикой.

1. Оценка retriever’а. Оцениваем только первый шаг:

▫️recall@k — нашёл ли нужные документы
▫️precision@k — доля релевантных среди top_k

Retriever прогоняем отдельно от LLM. Если он работает плохо, смотреть на ответы модели бессмысленно — она просто не видит нужный контекст.

2. Оценка LLM (step-level). Фиксируем retriever или используем заранее собранные контексты:

▫️faithfulness / groundedness — опирается ли ответ на context,
▫️factuality — совпадают ли факты с документами,
▫️hallucination rate — доля ответов, где модель что-то придумала,
▫️format compliance — соблюдение требуемого формата (буллеты, markdown и т.д.).

3. End-to-end RAG evaluation. Смотрим на полную цепочку: query -> retriever -> LLM -> answer.
Для стартовой оценки хватает 50–100 вручную размеченных примеров.

Если виден только «плохой ответ», нельзя сказать, виноват retriever или модель. Пошаговая оценка превращает RAG из случайного поведения в инженерный pipeline с понятными точками улучшения.

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

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