Максим Максимов // IT, AI


Гео и язык канала: Россия, Русский
Категория: Технологии


Активно познаю новое и стараюсь делиться со всеми!
Пишу посты на Хабр: https://habr.com/ru/users/maksimov_m
Персональный сайт: https://maksimovms.ru/
Мой профиль:
@maks_maks1

Связанные каналы

Гео и язык канала
Россия, Русский
Категория
Технологии
Статистика
Фильтр публикаций


Как я разработал легковесный Guardrails для русского языка

Написал статью на Хабр, в которой поделился процессом разработки своей версии легковесного Guardrails.

Рассказал что такое Guardrails, основные компоненты lite-guardrails, его архитектура, этапы разработки, настройкой observability, а также создание документации по проекту.

Ссылка на GitHub - здесь
Ссылка на статью - здесь

Максим Максимов // IT, AI


Репост из: _rnd
⚡️ Открываем бенчмарк для детекции PII в русском тексте

Мы тут много рассказывали про работу guardrails. А теперь выкатываем в открытый доступ бенчмарк для детекции персональных данных на русском языке. На нём можно сравнивать NER-модели, PII-детекторы и системы анонимизации.

Внутри датасета 21 тип персональных данных:
• ФИО: имя, фамилия, отчество;
• адресная иерархия: страна, регион, город, район, улица, дом;
• контакты: email, телефон, URL, IP;
• документы: паспорт, СНИЛС, ИНН, ОМС, банковская карта, водительское удостоверение, военный билет, свидетельство о рождении.

Датасет состоит из синтетических данных, а также реальных примеров из продакшен-логов, где персональные данные заменены на синтетику. Внутри сгенерированные данные в формате документов + сложные пограничные кейсы и опечатки.

Все данные представлены в формате BIO. Разметка и валидация выполнялись частично вручную, частично с помощью LLM. В карточке датасета описали таксономию сущностей и протокол оценки, а ещё добавили результаты популярных открытых моделей для удобного сравнения. 😊

Прогоняйте свои анонимайзеры, PII-детекторы и NER-модели, ломайте бенчмарк и делитесь результатами в комментариях.

↗️ Hugging Face

Автор этого поста, как и многих других про NER и PII, Женя Андриевская — NLP-инженер в R&D red_mad_robot


#Безопасность


Как дообучить LLM. Рассказываю шаг за шагом

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

В качестве примера обучил Qwen2.5-0.5B извлечению информации из текста по заданной схеме в формате JSON.

🔥 Welcome!

606 0 25 1 16

🤷 Когда использовать BERT, а когда LLM?

Во время решения различных NLP задач ловлю себя на мысли, что часто можно применить LLM.

Задача классификации? - Берём LLM + Structured Output.

Задача NER? - Тоже можно взять LLM, написать пару промптов и алгоритмов и вуаля - будем находить персональные данные в тексте.

Но, к сожалению, не так все просто.

1️⃣ Первое, во что упираемся - это инфраструктура и требования к системе. LLM бывает дорогим удовольствием, если нет доступа к хорошему железу. Здесь, конечно, можно использовать облачные решения, например с OpenRouter. Но если работа происходит с чувствительными данными, то использование облачных LLM становится затруднительным.

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

Соответственно, вот и одно из преимуществ BERT моделей - они не требуют мощного железа и работают достаточно быстро. То есть, их использовать гораздо дешевле.

2️⃣ Далее, конечно же, следует вопрос качества. И вот тут ответ на вопрос не такой однозначный. Я изучил несколько интересных работ, в которых сравнивали BERT модели с классическими LLM.

В некоторых работах ([1], [2], [3]) оценку проводили на задаче классификации, и здесь BERT модели показали результат лучше, чем у LLM. Для задачи NER в одной из работ [4] картина та же.

Но в той же работе [2], авторы показывают, что для обнаружения галлюцинаций - LLM показывает результаты лучше, чем BERT, та же картина в работе [5] со сравнением GPT-4o и BERT на задаче классификации отзывов с туристического сервиса. Также в этой [6] работе GPT показала лучшие результаты на задаче NER для нахождения в тексте имен людей.

Таким образом, однозначно сказать, кто лучше, тяжело. Нужны эксперименты и research.
Мне понравилась идея авторов работы [2], в которой они советуют подход к выбору архитектуры так:
- Для задач, где ответ лежит на "поверхности" в тексте, хорошо себя показывает BERT (например, при классификации тональности чаще всего легко понять, отзыв положителен или отрицателен).
- Для задач, где требуются внешние знания или же глубокое рассуждение - хорошо показывают себя LLM.
Они приводят этот фреймворк для задачи классификации, который можно взять на вооружение.

3️⃣ Последний аспект, который я хотел упомянуть - это выбор архитектуры в зависимости от наличия и изменяемости данных.

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

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

#️⃣ Подводя итог, можно сказать - перед выбором между BERT моделями и классическими LLM отталкиваемся от инфраструктуры и требований к системе. Также анализируем решаемую задачу и те данные, с которыми модель должна работать. Ответив на эти вопросы, можно принять первое решение и в дальнейшем отталкиваться от него.

Максим Максимов // IT, AI


🤑 Как платить меньше за инференс LLM

Занимался изучением вопроса удешевления стоимости токенов во время работы с облачными LLM.

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

🔺Кэширование промптов (Prompt Caching)

Это метод, в котором часто используемые промпты сохраняются в памяти провайдера LLM. Он основан на сохранении KV-cache.

Этот подход следует использовать в тех случаях, когда в ваших обращениях к LLM присутствуют большие инструкции, которые повторяются в каждом запросе. Например:
У вас огромный системный промпт, в котором описаны правила решения задачи пользователя. Каждый раз, когда пользователь дает новую задачу - вы отправляете LLM текст в формате "system prompt" + "user query". "system prompt" - всегда одинаковый. А соответственно, его можно закэшировать, и обрабатывать только часть "user query".

У OpenAI кэширование происходит автоматически, у Anthropic при вызове LLM нужно передавать параметр cache_control. У других провайдеров схожая схема.

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

Разобраться в работе этого механизма мне помогло следующее видео. Советую к просмотру.

🔺Пакетная обработка (Batсh API)

Следующий метод экономии, который дают провайдеры - это Batсh API. Этот подход немного отличается от типичного представления пакетной обработки запросов.

В объяснении этот подход чуть проще:
Исходно да, вы берете большое количество запросов к модели (например 10.000), и отправляете в LLM. Но обработка запросов происходит не мгновенно - а в течении 24 часов. Да да, вы не ослышались.

Использование Batсh API позволяет сэкономить до 50% стоимости токенов. Следует его применять, если вам необходимо обработать тысячи запросов и нет необходимости получать ответ в реальном времени. Популярные провайдеры как OpenAI, Anthropic, Google предоставляют такой функционал.

Реализация этого не сложная. У OpenAI нужно собрать список запросов в JSONL, а после отправить его в нужном формате. У Anthropic - собрать список запросов в массив и отправить их на обработку. И в течении 24 часов можно получить ответ, зато дешевле на 50% чем при обычном использовании.

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

В комментариях прикрепил наглядное видео из NotebookLM 🙂

Максим Максимов // IT, AI


Репост из: _rnd
⚡️ Открываем NSFW-бенчмарк для систем модерации

В прошлых постах мы много говорили о фильтрации NSFW. А теперь выкатываем в открытый доступ наш двуязычный бенчмарк для систем модерации контента.

Что внутри датасета:
• контрастные пары — о которых мы уже писали,
• сложные пограничные примеры — hard negatives.

Все данные собирались, отсеивались и валидировались полностью вручную.

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

Тестируйте свои фильтры на прочность и делитесь мыслями в комментариях. 😍

↗️ Hugging Face

Автор этого поста, как и большинства предыдущих про безопасность, Андрей Иванов — NLP-инженер в R&D red_mad_robot.


#Безопасность


Как решать задачу NER на практике

Опубликовал статью на Хабр, в которой разобрал задачу NER на реальном примере — извлечение сущностей из резюме.

Прошёлся по основным этапам: от поиска данных и разметки в Label Studio до обучения BERT моделей и написания сервиса на FastAPI. Старался давать меньше теории и больше практики с кодом на Python.

Ссылка на статью

527 0 10 4 11

Репост из: _rnd
Тестирование AI-агентов ✅

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

Что такое «хорошо» для вашего агента

Для начала нужно определить, какую задачу агент выполняет в системе. На этом этапе выделяются сценарии работы и end-to-end метрики: выполняется ли задача, какова точность результата, сколько времени и ресурсов требуется.

Оценка только по итоговому результату показывает картину лишь сверху. Чтобы понять, где возникает сбой, агента нужно разобрать на компоненты: LLM, tools, memory и другие. Тут у каждого свои критерии качества — какие входы поступают, какие выходы получаются и что считать ошибкой.

Переходим к данным

Нужно подготовить тестовый датасет с реальными запросами и ответами для каждого компонента. Данные нужны разнообразные: простые и сложные сценарии, edge cases, разные формулировки одних и тех же запросов.

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

Прогоняем агента и фиксируем метрики

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

Анализируем результаты

Где агент проваливается, какие компоненты работают некорректно? Обращаем внимание на полные логи действий агента, чтобы понять причину ошибок.

После происходит доработка компонентов, следующий прогон, следующее снятие метрик... Этот процесс идёт итеративно до момента достижения нужного качества.

Так и появляется надёжный агент. 😍

#Тестирование_агентов


Как работает платформа для курса

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

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

Вдохновился я подходом платформы deeplearning.ai, в которой как раз имеется удобный формат обучения, когда все в одном. Видео, текст, а также Jupyter с ноутбуками, в котором сразу можно выполнять задачи. На основе нее я решил попробовать сделать такую платформу для своего курса.

Каждая сессия Jupyter запускается в виде pod в Kubernetes с использованием JupyterLab. Данный подход позволил сделать изолированной каждую сессию пользователя. Каждая сессия имеет ограничения по CPU и памяти. В случае превышения лимитов — pod отключается, не затрагивая работу платформы.

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

В качестве LLM взял GigaChat API. Для работы с OpenAI API используется прокси gpt2giga, который переводит запросы в формат GigaChat. При желании его можно заменить. Например на OpenRouter.

Начало работы с платформой начинается с Telegram бота на aiogram. В нем пользователь регистрируется и получает логин, пароль и URL с API KEY для доступа к LLM.

В качестве фронтенда используется React, основной бекенд - FastAPI, база данных - PostgreSQL. Все это работает в Docker. В качестве единой точки входа используется Nginx.

Также для себя добавил простенький мониторинг (на рисунок не попал) - FastAPI + Jinja-шаблоны, в котором видно количество пользователей, количество использованных токенов и запросов к LLM, количество запущенных сессий Jupyter по времени.

Сейчас платформа развернута на небольшом сервере: 2 vCPU, 8 ГБ RAM и 80 ГБ диск. На данный момент этого достаточно, чтобы выдерживать одновременно ~15 работающих сессий Jupyter (проводил стресс тест).

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

Максим Максимов // IT, AI


Решаем проблемы настройки зависимостей и работы с LLM

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

Основная проблема - отсутствие доступа к LLM. Либо нет возможности поставить ее к себе локально из-за слабого железа, либо же не очень понятно, где получить доступ к API.

Также проблемы, связанные с настройкой Jupyter или установкой зависимостей.

Когда-то сам с таким сталкивался.

Решил собрать платформу, которая решает эти проблемы. В ней пользователь сможет получить доступ к Jupyter Notebook c уже установленными зависимостями, а также доступ к LLM, которую он сможет использовать внутри платформы. Естественно, Claude в разработке платформы очень помог.

Всего в пару кликов, после просмотра урока на курсе, человек сможет зайти на платформу и сразу начать практиковаться.

Сейчас проблема с которой я столкнулся - это ограниченность ресурсов сервера и LLM (взял подписку GigaChat и подключил прокси внутри сервера).

Для решения проблемы с ресурсами я сделал следующее: ограничил время и память 1 сессии с Jupyter для 1 пользователя. Также ограничил количество запросов к предоставленной LLM для пользователя в минуту.

Сейчас сервер способен выдержать одновременно ~15 запущенных сессий с Jupyter. Работает по принципу "кто успел, тот и съел" =)

Настроил себе мониторинг, посмотрю что из этого выйдет. Если будет интерес, буду думать над масштабированием, чтобы повысить количество одновременно работающих пользователей.

Возможно в канале есть те, кто начал проходить мой курс. Чтобы получить доступ к платформе - нужно зайти в бота @course_platform_bot, после команды /start он предоставит все необходимые доступы и ссылки. Напомню - LLM можно использовать только внутри платформы.

Максим Максимов // IT, AI


Курс: "Введение в разработку ИИ-агентов"

В прошлом месяце пришла идея сделать свой небольшой курс по введению в ИИ-агентов. Идея воплотилась в реальность.

Утра и вечера в Miro за отрисовкой схем, съемкой и монтажом прошли не зря. Получился вводный курс, который состоит из двух основных модулей:

- Введение в работу с LLM. Взаимодействие с LLM на Python, написание промптов, Structured Output и подход к выбору LLM для различных задач.

- Введение в ИИ-агентов. Основные компоненты ИИ-агента, Function Calling, шаблоны проектирования агентов.

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

Мой первый опыт создания курсов - посмотрим что из этого выйдет.

Ссылка на курс

697 0 27 6 27

🔥 Доделываю последние штрихи

Судя по статистике, больше чем половине людей, которые ответили на опрос, будет интересно то, что я скину сегодня!
Так что не пропустите =)


Какой у вас опыт с AI-агентами?
Опрос
  •   Слышал про агентов, но глубоко не погружался
  •   Пробовал собирать агентов — на LangGraph, LlamaIndex или похожих инструментах
  •   Разрабатываю агентов в продакшене / на коммерческих проектах
79 голосов


В ближайшие дни поделюсь проектом, над которым работал в этом месяце — он связан с AI-агентами. Расскажу подробности чуть позже =)
А пока интересно — какой у вас опыт работы с агентами?


Быстрый доступ к фейковым данным

На днях понадобилось сгенерировать набор фиктивных персональных данных - ФИО, адреса, номера и т.д.

Конечно, первым делом пришла идея использовать LLM для этого дела. Но решил немного погуглить про этот процесс. В итоге наткнулся на такую библиотеку как Faker ("фейкер", не "факер").

Это инструмент с открытым исходным кодом, который буквально в пару строчек позволяет генерировать фиктивные данные.
Пример:
from faker import Faker

fake = Faker(['ru_RU', 'en_US'])

print(fake.name()) # Jessica Martinez
print(fake.name()) # Панфилов Аркадий Львович
print(fake.email()) # david.johnson@example.com
print(fake.email()) # panfilova@example.ru
Каждый вызов генерирует новую комбинацию.

"Можно реализовать самому с помощью LLM" подумают многие.

Да, согласен. Меня зацепило то, что весь процесс генерации уже реализован под капотом, и его можно встраивать в свои сценарии.
Например, это может быть pipeline генерации синтетических данных для задачи классификации или NER, либо же заполнение БД для тестов.

Faker способен генерировать данные на различных языках и позволяет добавлять собственные кастомные генераторы. Также имеются реализации на PHP, Perl и Ruby. Подробнее можно посмотреть в документации.

Ссылка на GitHub здесь
Ссылка на документацию здесь

Максим Максимов // IT, AI


Репост из: _rnd
↗️ Мы захватили этот канал

Раньше канал назывался red_mad_dev.

Теперь это _rnd — публичный блог практики R&D red_mad_robot.

Это рабочая площадка для инженеров и ресёрчеров. Здесь будут наши мысли, эксперименты, короткие и длинные технические разборы, ссылки на научные статьи и git-репозитории.

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

Если вам интересны reasoning-архитектуры, RAG-системы, агентные пайплайны, LLM-инфраструктура и реальный продакшн AI — вы в правильном месте.

Поехали ⚡️


umami - open-source платформа для сбора и анализа данных сайта

На днях занимался поиском инструмента для получения аналитики по веб-сайту.
Побрейнштормив с LLM, наткнулся на такой инструмент как umami.

Это аналитическая open-source платформа, которая позиционирует себя как альтернатива Google Analytics.

Umami предоставляет большое количество функций, которые позволяют анализировать трафик сайта:
- Анализ посетителей (продолжительность визита, геолокация, используемое устройство)
- Анализ событий (открытые страницы, последовательность действий на сайте, нажатие на кнопки, заполнение форм)
все функции можно посмотреть здесь

Настраивается эта платформа достаточно просто. Для этого можно использовать Docker.

- Первым шагом необходимо добавить сервис с umami в docker-compose.yml, указав в переменных окружения путь к БД и APP_SECRET.

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

Подробнее можно посмотреть в документации в разделе Quickstart.

В комментариях закину пару скриншотов примера аналитики с umami.

Ссылка на Github здесь

Максим Максимов // IT, AI

607 0 20 5 19

Как небольшие правки в Docker уменьшат количество ваших проблем

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

Начал искать проблему в подключении к базе данных: в коде, в .env, в Docker. Но проблема оставалась.

Через некоторое время я вспомнил рассказ своего коллеги про похожий случай, в котором его проект тоже в какой-то момент упал из-за брутфорс-атаки. Далее он рассказал про злоумышленников, которые сканируют IP в сети и ищут открытые порты на сервере. После используя brute-force, пытаются подобрать креды для получения доступа к сервису.

Сделав предположение, что проблема в этом, я заглянул в свой docker-compose и увидел следующее:
...
postgres:
image: postgres:15
container_name: product_cards_postgres
ports:
- "5432:5432"
environment:
POSTGRES_USER: postgres
POSTGRES_PASSWORD: postgres123
POSTGRES_DB: product_cards
volumes:
- postgres_data:/var/lib/postgresql/data
...

Здесь мы видим сразу несколько ошибок, которые я допустил:
1. Секция ports: "5432:5432".
Приложение было открыто для подключений с любого устройства в интернете. Поэтому тот самый подбор в целом мог сделать любой бот-сканнер.

2. Секция environment: POSTGRES_USER, POSTGRES_PASSWORD.
Здесь я думаю даже комментировать не нужно. Сразу после локального тестирования пытаться такое заливать на сервер - большая ошибка. Тот самый подбор тут срабатывал отлично. Стоило произвести всего лишь базовый перебор наиболее популярных паролей.

После этого я исправил эти грубые ошибки безопасности.
Для этого я закрыл доступ извне, убрав секцию ports (сервисы, которые запущены в одном compose вместе с этой БД - находятся в одной сети).
Еще это можно сделать, разрешив подключения к базе только внутри самого сервера:
...
ports:
- "127.0.0.1:5432:5432"
...

Также я поменял логин и пароль на более сложные.

И естественно после этого ошибки с
FATAL: password authentication failed for user "postgres" перестали появляться =)

Из этого случая вынес урок: после локальной разработки, при развертывании, не стоит оставлять "двери" (порты) открытыми, а пароль и логин - простыми. Возможно, эти вещи кажутся банальными, но зато я сам убедился, к чему приводит их игнорирование.

Максим Максимов // IT, AI


Best practices для LLM-as-a-Judge

В своей крайней статье я рассказывал о метриках BLEU, ROUGE, METEOR. Это простые и быстрые в подсчете метрики. У них есть существенный недостаток: при оценке схожести двух текстов они опираются на точное совпадение слов или их частей. Если тексты написаны правильно, но другими словами, оценка будет низкой. Хотелось бы такого избежать.

На помощь приходит LLM-as-a-Judge, при котором сама языковая модель (LLM) выступает в роли оценщика. Такой подход делает оценку более близкой к человеческой, а также позволяет производить оценку в более широком классе задач (например, сравнивать ответы на разных языках).

Давайте рассмотрим некоторые практики, которые позволят сделать применение LLM-as-a-Judge более эффективным.

1. Четкие и атомарные критерии оценки
Во время написания системного промпта нужно стараться более четко описывать критерии, по которым вы хотите оценить свои примеры. Эти критерии стоит декомпозировать на более атомарные, чтобы LLM было проще в них разобраться и выдать оценку.

Например:
"Оцени качество текста баллами от 1 до 3" - плохая инструкция.

"Оцени текст по 3х бальной шкале:
1 балл - текст содержит более 5 орфографических ошибок.
2 балла - текст содержит не более 5 орфографических ошибок.
3 балла - ошибки в тексте отсутствуют." - хорошая инструкция.


2. Structured Output и Schema-Guided Reasoning
Эти "заклинания" позволят ограничить LLM в выдаче результата и получать более предсказуемый формат выходных данных. Задайте строгую схему, по которой модель должна сгенерировать ответ. Помимо ожидаемого результата это позволит проще реализовать алгоритм оценки в коде.
Также стоит добавить в системный промпт описания ожидаемой выходной структуры.

Часто пользуюсь такой практикой: ограничиваю результат баллами (например от 1 до 5) или категориями ("хорошо", "нормально", "плохо"). Это задается в схеме выходных данных (например, через pydantic). Также на этапе описания критериев необходимо описывать, за что давать тот или иной балл или присваивать категорию (как в примере выше).

3. Просить LLM аргументировать оценку
Во-первых, не всегда с первого раза получается задать качественный системный промпт и формат оценки. На ранних этапах такие пояснения помогают провести отладку и понять, почему в том или ином примере LLM дала неправильную оценку и в каких местах у нее есть предрассудки. Во-вторых, заставляя модель объяснять свое решение (и тем самым глубже вникать в задачу), мы получаем более правильную оценку.

Особенно хорошо это работает вместе с Chain-of-Thought (просить модель рассуждать "шаг за шагом"), который заставит модель шаг за шагом разбирать пример, вникать в детали, а после выдавать оценку.

Этот подход хорошо комбинировать со вторым: заставлять LLM через SGR сначала в схеме выдавать аргументацию, а потом оценку.

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

Если, например, вы оцениваете данные по 3х бальной шкале, можно привести пример оценки на каждый балл, чтобы LLM лучше уловила суть.

Максим Максимов // IT, AI


Метрики для задач NLP. Часть 2. Генерация текста: BLEU, ROUGE, METEOR, BERTScore

Опубликовал статью на Хабр, в которой рассказал о популярных метриках оценки для задач генерации текста: BLEU, ROUGE, METEOR, BERTScore.

Рассказ сопровождается визуализацией, примерами и кодом на Python.

Показано 20 последних публикаций.