Как оценивать качество ответов 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
Когда мы запускаем модель в прод, важно понимать, насколько хорошо она отвечает, где ошибается и как улучшить её работу.
Существует несколько подходов к оценке качества ответов модели:
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
🔥10👍6❤2
Вебинар-интервью: Этап Discovery — с чего начать внедрение генеративного ИИ
17 сентября в 11:00 в гости к Внутри AI придет Дмитрий Твердохлебов, экс-директор по ИИ в МТС и VK, эксперт с 15-летним опытом внедрения цифровых продуктов.
Интервью проведет Александр Опрышко, сооснователь и управляющий партнер KTS.
В формате диалога обсудим, как подойти к внедрению генеративного ИИ и какие результаты можно ожидать.
На вебинаре вы узнаете:
- где ИИ принесет пользу бизнесу, а где его внедрение не оправдано;
- какие артефакты необходимы для старта;
- каким должен быть definition of ready пилотного проекта;
- что делать в компании без собственного AI-подразделения;
- как будет развиваться рынок и на что стоит обратить внимание.
Будет полезно всем менеджерам и руководителям проектов, которые планируют внедрять ИИ.
Ссылка для подключения появится в канале перед началом вебинара.
Задавайте вопросы под этим постом — спикеры обязательно на них ответят.
17 сентября в 11:00 в гости к Внутри AI придет Дмитрий Твердохлебов, экс-директор по ИИ в МТС и VK, эксперт с 15-летним опытом внедрения цифровых продуктов.
Интервью проведет Александр Опрышко, сооснователь и управляющий партнер KTS.
В формате диалога обсудим, как подойти к внедрению генеративного ИИ и какие результаты можно ожидать.
На вебинаре вы узнаете:
- где ИИ принесет пользу бизнесу, а где его внедрение не оправдано;
- какие артефакты необходимы для старта;
- каким должен быть definition of ready пилотного проекта;
- что делать в компании без собственного AI-подразделения;
- как будет развиваться рынок и на что стоит обратить внимание.
Будет полезно всем менеджерам и руководителям проектов, которые планируют внедрять ИИ.
Ссылка для подключения появится в канале перед началом вебинара.
Задавайте вопросы под этим постом — спикеры обязательно на них ответят.
🔥8👍7❤3
В ожидании вебинара познакомьтесь с кейсами внедрения ИИ — они помогут лучше разобраться в теме.
Вот некоторые ресурсы, где можно посмотреть примеры:
Evidently AI — агрегатор с 650+ кейсами и удобной системой ссылок.
GenAI & LLM System Design — расширенная библиотека технических кейсов на GitHub, созданная на базе Evidently AI.
Generation AI — (российские кейсы) небольшая, но полезная библиотека кейсов от JustAI.
Если какие-то из кейсов покажутся особенно интересными или у вас возникнут вопросы, оставляйте их в комментариях, обсудим вместе на вебинаре.
Вот некоторые ресурсы, где можно посмотреть примеры:
Evidently AI — агрегатор с 650+ кейсами и удобной системой ссылок.
GenAI & LLM System Design — расширенная библиотека технических кейсов на GitHub, созданная на базе Evidently AI.
Generation AI — (российские кейсы) небольшая, но полезная библиотека кейсов от JustAI.
Если какие-то из кейсов покажутся особенно интересными или у вас возникнут вопросы, оставляйте их в комментариях, обсудим вместе на вебинаре.
🔥7❤4👏3
Что такое 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.
#александр_опрышко
При разработке сервисов на базе 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.
#александр_опрышко
🔥16❤3👏3
Из чего состоит Langfuse?
Langfuse — платформа для отслеживания и оценки работы LLM-агентов. В основе — пять компонентов:
Traces & Observations
Трейс — лог одного запроса. Внутри: шаги агента, вызовы инструментов, ответы модели. Помогает понять, как агент «думает» и где ломается цепочка.
Sessions
Объединяют трейсы в одно взаимодействие — например, целый диалог. Удобно смотреть не отдельные шаги, а поведение агента в целом.
Scores
Оценки — это различные метрики: точность ответа, успешность, тип ошибки. На них строятся сравнение версий и автооценка.
Datasets & Dataset Runs
Датасеты — входы с эталонными ответами. Dataset Run — их запуск через агента с сохранением логов. Помогает тестировать изменения и сравнивать качество.
Prompts
Централизованное хранилище промптов: версии, параметры, история. Можно тестировать варианты, быстро откатываться и отслеживать изменения.
Как выглядит цикл разработки агента с Langfuse
1. Собираем датасет из типовых запросов и эталонов.
2. Запускаем Dataset Run, фиксируем трейсы.
3. Анализируем шаги агента (Traces & Observations).
4. Ставим оценки — автоматически (LLM) и вручную.
5. Меняем промпт или логику, запускаем снова.
Такой подход заменяет хаотичное «подкручивание промптов» системной работой с метриками, тестами и контролем качества.
#александр_опрышко
Langfuse — платформа для отслеживания и оценки работы LLM-агентов. В основе — пять компонентов:
Traces & Observations
Трейс — лог одного запроса. Внутри: шаги агента, вызовы инструментов, ответы модели. Помогает понять, как агент «думает» и где ломается цепочка.
Sessions
Объединяют трейсы в одно взаимодействие — например, целый диалог. Удобно смотреть не отдельные шаги, а поведение агента в целом.
Scores
Оценки — это различные метрики: точность ответа, успешность, тип ошибки. На них строятся сравнение версий и автооценка.
Datasets & Dataset Runs
Датасеты — входы с эталонными ответами. Dataset Run — их запуск через агента с сохранением логов. Помогает тестировать изменения и сравнивать качество.
Prompts
Централизованное хранилище промптов: версии, параметры, история. Можно тестировать варианты, быстро откатываться и отслеживать изменения.
Как выглядит цикл разработки агента с Langfuse
1. Собираем датасет из типовых запросов и эталонов.
2. Запускаем Dataset Run, фиксируем трейсы.
3. Анализируем шаги агента (Traces & Observations).
4. Ставим оценки — автоматически (LLM) и вручную.
5. Меняем промпт или логику, запускаем снова.
Такой подход заменяет хаотичное «подкручивание промптов» системной работой с метриками, тестами и контролем качества.
#александр_опрышко
👍17❤6🔥6👏1
Вебинар_«Внедрение_генеративного_ИИ».ics
540 B
Уже скоро — вебинар «Этап Discovery: с чего начать внедрение генеративного ИИ».
17 сентября, 11:00 в прямом эфире встретятся Дмитрий Твердохлебов, экс-директор по ИИ в МТС и VK, и Александр Опрышко, сооснователь и управляющий партнер KTS.
Вместе обсудим ключевые вопросы старта:
– в каких задачах ИИ дает ощутимую пользу, а где не нужен;
– какие артефакты готовить к пилоту;
– что делать, если в компании нет AI-команды;
– как выглядит готовность к запуску (definition of ready);
– как меняется рынок и на что важно смотреть уже сейчас.
Формат — интервью и ответы на ваши вопросы.
Будет полезно всем менеджерам и руководителям проектов, которые планируют внедрять ИИ.
Добавляйте напоминание в календарь и до встречи на вебинаре. Ссылка появится в канале перед началом.
17 сентября, 11:00 в прямом эфире встретятся Дмитрий Твердохлебов, экс-директор по ИИ в МТС и VK, и Александр Опрышко, сооснователь и управляющий партнер KTS.
Вместе обсудим ключевые вопросы старта:
– в каких задачах ИИ дает ощутимую пользу, а где не нужен;
– какие артефакты готовить к пилоту;
– что делать, если в компании нет AI-команды;
– как выглядит готовность к запуску (definition of ready);
– как меняется рынок и на что важно смотреть уже сейчас.
Формат — интервью и ответы на ваши вопросы.
Будет полезно всем менеджерам и руководителям проектов, которые планируют внедрять ИИ.
Добавляйте напоминание в календарь и до встречи на вебинаре. Ссылка появится в канале перед началом.
🔥5❤4👍2
Опыт 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% меньше ручного труда, при этом точность не пострадала.
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% меньше ручного труда, при этом точность не пострадала.
❤6👍4🔥1
Завтра, 17 сентября в 11:00 — вебинар «Этап Discovery: с чего начать внедрение генеративного ИИ».
Дмитрий Твердохлебов и Александр Опрышко обсудят, где ИИ приносит реальную пользу, что нужно для пилота и как понять готовность к запуску.
Ссылка для подключения.
До встречи!
Дмитрий Твердохлебов и Александр Опрышко обсудят, где ИИ приносит реальную пользу, что нужно для пилота и как понять готовность к запуску.
Ссылка для подключения.
До встречи!
🔥9❤4👌2
Стартуем вебинар «Этап Discovery: с чего начать внедрение генеративного ИИ».
В эфире — Дмитрий Твердохлебов, экс-директор по ИИ в МТС и VK, и Александр Опрышко, сооснователь и управляющий партнер KTS.
Подключайтесь по ссылке.
В эфире — Дмитрий Твердохлебов, экс-директор по ИИ в МТС и VK, и Александр Опрышко, сооснователь и управляющий партнер KTS.
Подключайтесь по ссылке.
Zoom
Join our Cloud HD Video Meeting
Zoom is the leader in modern enterprise cloud communications.
👍8👌1
Делимся записью вебинара «Этап Discovery: с чего начать внедрение генеративного ИИ».
На встрече Дмитрий Твердохлебов и Александр Опрышко обсудили, где ИИ действительно приносит пользу бизнесу, какие артефакты нужны для старта, что делать компаниям без AI-команды и как оценить готовность к запуску пилота.
Смотрите запись на наших площадках:
YouTube
VK
Rutube
На встрече Дмитрий Твердохлебов и Александр Опрышко обсудили, где ИИ действительно приносит пользу бизнесу, какие артефакты нужны для старта, что делать компаниям без AI-команды и как оценить готовность к запуску пилота.
Смотрите запись на наших площадках:
YouTube
VK
Rutube
🔥7
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.
#александр_опрышко
В прошлых постах мы уже рассказывали о том, как оценивать качество ответов 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.
#александр_опрышко
👍8🔥2
Официальный 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
В начале сентября команда, занимающаяся разработкой 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
👍6
Что такое 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 и собирать многоэтапных агентов.
#александр_опрышко
Классический промпт-инжиниринг порождает неустойчивые пайплайны. Поведение системы зашито в строки, а интерфейс задачи смешан с формулировкой промпта. Поэтому любое изменение — модели, метрики или последовательности шагов — требует ручного редактирования. В итоге снижается переносимость, тестируемость и воспроизводимость.
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 и собирать многоэтапных агентов.
#александр_опрышко
🔥4❤1
Представляем 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
Мы видим, как бизнес строит 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
🔥9
Мы растим AI-команду и ищем лидера, который возьмёт под своё крыло всё направление.
С первого дня ты будешь работать с реальными задачами для крупных заказчиков. Тебе предстоит: создание метрик, проверка гипотез, fine-tuning существующих LLM, разработка сервисов для решения бизнес-задач, а также найм и развитие своей команды.
Откликайся, если узнал себя:
— 5+ лет коммерческого опыта в NLP;
— создавал проекты на основе LLM и RAG, работал с агентными системами;
— умеешь решать ML-задачи полного цикла;
— нанимал и развивал DS/ML-специалистов, руководил командой от 2 человек;
— видишь ценность ИИ в решении реальных бизнес-задач;
— умеешь выстраивать коммуникацию с заказчиком.
Если хочешь создавать собственных RAG- и AI-агентов, развиваться в NLP и при этом держать фокус на пользе технологий для бизнеса — откликайся и добро пожаловать в KTS!
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7❤1
Быстрое решение с LLM: доступ к аналитике Redash через чат-бота
Сделали инструмент, который упрощает работу менеджеров с данными.
Redash — система аналитики, которая строит графики и отвечает на запросы к базам данных. Вместо SQL-запросов к системе можно задать вопрос через бота: «сколько пользователей зарегистрировалось?» или «какие продуктовые метрики можно собрать по базе».
Бот сам обращается к API, строит корректные SQL-запросы и возвращает результат. Для тех, кто не уверен, какие именно данные нужны, бот сканирует структуру базы и предлагает релевантные метрики.
Такой подход снижает барьер входа в аналитику: менеджеры получают доступ к ключевым показателям без участия аналитиков или разработчиков.
Сделали инструмент, который упрощает работу менеджеров с данными.
Redash — система аналитики, которая строит графики и отвечает на запросы к базам данных. Вместо SQL-запросов к системе можно задать вопрос через бота: «сколько пользователей зарегистрировалось?» или «какие продуктовые метрики можно собрать по базе».
Бот сам обращается к API, строит корректные SQL-запросы и возвращает результат. Для тех, кто не уверен, какие именно данные нужны, бот сканирует структуру базы и предлагает релевантные метрики.
Такой подход снижает барьер входа в аналитику: менеджеры получают доступ к ключевым показателям без участия аналитиков или разработчиков.
🔥11
Новинка от OpenAI
Лучше поздно, чем никогда. Рассказываем:
OpenAI представила Prompt Packs — свыше 300 шаблонов промптов для конкретных ролей (разработчики, HR, маркетологи, продавцы и др.) Рабочие промпты под повседневные задачи: письма, анализ, планирование, код, скрипты переговоров.
Зачем это сегодня:
- Быстрый старт без изучение особенностей «промпт-инженерии»: выбираете роль, берете шаблон, добавляете свой контекст и получаете пригодный к делу результат.
- Стандарты для команды: одна библиотека промптов снижает разброс качества и ускоряет онбординг.
Забирайте и адаптируйте под свой стек задач: клик
Лучше поздно, чем никогда. Рассказываем:
OpenAI представила Prompt Packs — свыше 300 шаблонов промптов для конкретных ролей (разработчики, HR, маркетологи, продавцы и др.) Рабочие промпты под повседневные задачи: письма, анализ, планирование, код, скрипты переговоров.
Зачем это сегодня:
- Быстрый старт без изучение особенностей «промпт-инженерии»: выбираете роль, берете шаблон, добавляете свой контекст и получаете пригодный к делу результат.
- Стандарты для команды: одна библиотека промптов снижает разброс качества и ускоряет онбординг.
Забирайте и адаптируйте под свой стек задач: клик
❤4👍1
Подборка полезных 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, рекомендуем почитать, как спец выиграл челлендж. Подробный разбор рабочего пайплайна с кодом: парсинг, ретривал, роутинг, реранкинг, промпты. Можно адаптировать под свои данные.
Впереди длинные выходные, делимся, что можно почитать/посмотреть по теме AI, чтобы провести их с пользой.
▫️Agentic AI от Andrew Ng (очень известный автор блестящих курсов по ML). Курс с четырьмя ключевыми паттернами: рефлексия, использование инструментов, планирование, мультиагентность. Код — на чистом Python, с акцентом на эвалах и анализе ошибок. На выходе — полнофункциональный research-agent.
▫️Stanford CME295 (Transformers & LLMs). Лаконичный курс, который охватывает фундамент трансформеров и прикладные темы: RAG, LLM-as-a-judge, квантизация, Mixture-of-Experts. Подойдёт, если хотите быстро систематизировать знания и обновить стек.
▫️Хабр: «Как я победил в RAG Challenge». Если разрабатывайте свой RAG, рекомендуем почитать, как спец выиграл челлендж. Подробный разбор рабочего пайплайна с кодом: парсинг, ретривал, роутинг, реранкинг, промпты. Можно адаптировать под свои данные.
👍7❤1
Вас уже больше тысячи! 🔥
Кажется, пора познакомиться и рассказать, кто стоит за продуктом и идеями, которые здесь появляются.
Один из авторов канала — Александр Опрышко, сооснователь и управляющий партнёр IT-компании KTS. Саша в этой сфере с подросткового возраста: в 14 лет поступил в МГТУ им. Баумана, в 18 уже работал в Mail.ru, а в 2015 году вместе с одногруппниками основал KTS. Сегодня компания создаёт цифровые сервисы для бизнеса в разных направлениях, в числе которых AI.
Александр отвечает за технологическое развитие и новые направления. Под его руководством KTS запускает продукты и внедряет подходы, которые помогают бизнесу работать быстрее и надёжнее. Среди ключевых инициатив:
• запуск направления MLOps, которое ускорило развертывание ML-моделей с месяцев до дней;
• внедрение ИИ-агентов в платформу Smartbot, что позволило клиентам платформы автоматизировать коммуникацию с их клиентами и техническую поддержку;
• развитие No-code-облака в Smartbot — теперь пользователи могут разворачивать инструменты и собирать свои бизнес-процессы без администрирования;
• запуск платформы — Agent Platform.
В следующих постах расскажем про второго автора канала, Игоря Латкина.
Спасибо, что вы с нами!
#александр_опрышко
Кажется, пора познакомиться и рассказать, кто стоит за продуктом и идеями, которые здесь появляются.
Один из авторов канала — Александр Опрышко, сооснователь и управляющий партнёр IT-компании KTS. Саша в этой сфере с подросткового возраста: в 14 лет поступил в МГТУ им. Баумана, в 18 уже работал в Mail.ru, а в 2015 году вместе с одногруппниками основал KTS. Сегодня компания создаёт цифровые сервисы для бизнеса в разных направлениях, в числе которых AI.
Александр отвечает за технологическое развитие и новые направления. Под его руководством KTS запускает продукты и внедряет подходы, которые помогают бизнесу работать быстрее и надёжнее. Среди ключевых инициатив:
• запуск направления MLOps, которое ускорило развертывание ML-моделей с месяцев до дней;
• внедрение ИИ-агентов в платформу Smartbot, что позволило клиентам платформы автоматизировать коммуникацию с их клиентами и техническую поддержку;
• развитие No-code-облака в Smartbot — теперь пользователи могут разворачивать инструменты и собирать свои бизнес-процессы без администрирования;
• запуск платформы — Agent Platform.
В следующих постах расскажем про второго автора канала, Игоря Латкина.
Спасибо, что вы с нами!
#александр_опрышко
❤14🔥7👏6
Как оценить агентскую систему?
Агентскую систему удобнее рассматривать как 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 с понятными точками улучшения.
В следующем посте разберу, как автоматически генерировать датасеты для каждого этапа и сократить объём ручной разметки.
#александр_опрышко
Агентскую систему удобнее рассматривать как 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 с понятными точками улучшения.
В следующем посте разберу, как автоматически генерировать датасеты для каждого этапа и сократить объём ручной разметки.
#александр_опрышко
🔥7❤4👍3