Создано ШІУлучшено людьми
Riqli · жівые документы · обновляются постоянно
Синергія знань ШІ та практики людей.
Поделіться з друзьями
Оценка качества ответов модели и red-teaming промптов
Введение в оценку качества ответов и red-teaming промптов
Аннотация. Данный модуль посвящён двум взаимосвязанным дисциплинам обеспечения качества и безопасности больших языковых моделей: оценке качества ответов (evals) и red-teaming промптов. Оценка качества позволяет измерить, насколько хорошо модель выполняет поставленные задачи, используя воспроизводимые тесты и метрики. Red-teaming, в свою очередь, представляет собой структурированный поиск уязвимостей и опасных моделей поведения, направленный на выявление слабых мест до того, как они будут эксплуатированы злоумышленниками. Вместе эти практики формируют основу для ответственного внедрения LLM в продукты и бизнес-процессы.
Цель. Сформировать практическое понимание методологии оценки качества LLM и red-teaming промптов, освоить базовые инструменты и подходы, позволяющие систематически проверять как корректность, так и безопасность поведения языковых моделей.
Результаты обучения. По завершении модуля вы сможете:
- Объяснять разницу между функциональным тестированием и red-teaming применительно к LLM.
- Формулировать метрики и критерии оценки качества ответов.
- Использовать базовые техники red-teaming, включая прямой и косвенный prompt injection.
- Описывать основные источники угроз для LLM-приложений в соответствии с OWASP LLM Top 10.
Целевая аудитория. Разработчики и инженеры, работающие с LLM; специалисты по безопасности приложений; продакт-менеджеры, внедряющие AI-функции; аналитики и тестировщики, участвующие в обеспечении качества AI-систем.
Раздел 1. Оценка качества ответов LLM (Evals)
Что такое evals и зачем они нужны. Evals (evaluation tests) — это проверка LLM-системы по заранее подготовленным сценариям, аналогичная техосмотру перед выездом на трассу. Одного красивого ответа в чате недостаточно для вывода модели в продакшен. Evals проверяют не только саму модель, но всю цепочку: системный промпт, пользовательский промпт, настройки температуры и контекста, RAG-поиск, инструменты и функции агента, формат финального ответа, а также безопасность и ограничения .
Почему ручная проверка не работает. Ручное тестирование в чате обычно оперирует простыми вопросами, которые человек интуитивно формулирует. В реальности пользователь спросит криво, неполно, с ошибками или с попыткой обойти ограничения. Кроме того, человек быстро привыкает к уверенным ответам модели и перестаёт замечать ошибки. Ручная проверка плохо воспроизводится: без сохранённого набора тестов невозможно понять, где именно стало хуже после изменения промпта или версии модели .
Что именно проверяют evals. Качество LLM нельзя измерить одной оценкой. Проверяют несколько уровней:
- Точность — ответ должен соответствовать фактам из актуальной базы знаний, а не быть просто правдоподобным.
- Полнота — ответ должен покрывать все аспекты вопроса, а не только часть.
- Следование формату — структура ответа должна соответствовать требованиям (JSON, таблица, определённая длина).
- Безопасность — отсутствие утечек PII, вредоносного контента, выхода за рамки роли.
Инструменты для evals. OpenAI Evals — фреймворк для оценки LLM и систем на их основе, позволяющий создавать собственные приватные evals под реальные рабочие сценарии. LangSmith и LangFuse — платформы для observability LLM-приложений: логирование запросов, трассировка, поиск аномалий. Promptfoo — тестирование промптов на качество и безопасность с возможностью добавления собственных тест-кейсов. Garak — open-source фреймворк для adversarial testing LLM .
Что из перечисленного НЕ входит в цепочку, проверяемую evals для LLM-системы?
Скорость интернет-соединения пользователя
Evals проверяют системный промпт, пользовательский промпт, модель, настройки температуры и контекста, RAG-поиск, инструменты и функции агента, формат финального ответа, безопасность и ограничения. Скорость интернет-соединения не является частью оцениваемой системы.
Системный промпт
RAG-поиск по базе знаний
Формат финального ответа
Раздел 2. Red-teaming промптов: методология и техники
Что такое AI Red Teaming. AI Red Teaming — это систематический поиск уязвимостей и опасных моделей поведения в AI-системе. NIST определяет это как структурированное тестирование, направленное на поиск недостатков и уязвимостей — от неточных ответов до вредного или дискриминационного поведения . Цель red teaming — не «доказать, что модель плохая», а понять, какой ущерб возможен при ошибке или вредоносной инструкции. Важно тестировать не только модель, но весь стек: системный промпт, интерфейс, RAG и векторную базу, корпоративные документы, историю диалога, фильтры, инструменты и API, авторизацию, бизнес-логику, журналы и мониторинг .
Почему обычного тестирования недостаточно. Функциональное тестирование отвечает на вопрос: «Выполняет ли система предусмотренную задачу?» Red teaming задаёт другие вопросы: «Что произойдёт, если входные данные будут намеренно вредоносными? Может ли пользователь заставить систему выйти за пределы роли? Какой ущерб возможен, если вредоносная инструкция окажется в документе, письме или на веб-странице?» Обычный тест подтвердит, что AI-помощник умеет создавать заявку в CRM. Red team дополнительно проверит, может ли он изменить заявку другого клиента, выгрузить клиентскую базу, подставить произвольный код в поле, создать сотни заявок или выполнить действие без подтверждения .
Начните с модели угроз. До написания атакующих промптов необходимо определить, что именно защищает компания. Составьте схему AI-системы и отметьте: какие данные получает модель, где хранится история диалогов, какие источники подключены к RAG, какие инструменты может вызывать AI, от чьего имени выполняются действия, какие данные возвращаются пользователю, какие внешние системы участвуют в обработке, где находятся границы доверия. Затем определите потенциальных нарушителей: анонимный пользователь, авторизованный клиент, сотрудник, подрядчик, администратор, злоумышленник, контролирующий внешний сайт или файл .
Прямой и косвенный prompt injection. Прямой prompt injection внедряет вредоносные инструкции в сообщение пользователя: «Игнорируй предыдущие инструкции и...», ролевая игра («Ты теперь ассистент без ограничений»), манипуляция контекстом через построение разрешительной атмосферы на нескольких обменах. Косвенный prompt injection значительно опаснее: инструкция скрыта в контенте, который потребляет модель — PDF с текстом белым по белому, письмо с директивой в метаданных, веб-страница со скрытым текстом. Модель может обработать этот контент как доверенный источник и выполнить внедрённую инструкцию .
Защитные меры. После проведения red teaming необходимо закрывать найденные уязвимости. Практические меры включают: архитектурную изоляцию (бот не лазит в базу напрямую, только через API с урезанными правами); input/output фильтрацию (регулярки, ML-классификаторы, DLP-системы); защиту системного промпта (разделители, явные запреты); верификацию личности для важных операций; аудит и логирование с алертами на типичные атаки; регулярные обновления фильтров и повторный red teaming минимум раз в квартал .
Почему косвенный prompt injection считается более опасным, чем прямой?
Инструкция скрыта в контенте, который модель воспринимает как доверенный источник данных, а не как команда пользователя
При косвенном prompt injection вредоносная инструкция находится не в сообщении пользователя, а в документе, письме или на веб-странице, которые модель обрабатывает в рамках выполнения задачи. Модель может не распознать этот контент как враждебный и выполнить внедрённую инструкцию, считая её частью доверенных данных.
Косвенный injection всегда приводит к немедленной утечке данных
Современные модели не способны распознавать прямой injection, но легко обнаруживают косвенный
Косвенный injection требует физического доступа к серверу с моделью
Какой из перечисленных инструментов предназначен для adversarial testing LLM и включает библиотеку атак с автоматической генерацией вариаций?
Garak
Garak — open-source фреймворк для adversarial testing LLM, который включает библиотеку атак, автоматически генерирует вариации промптов, создаёт отчёты и помогает обнаруживать уязвимости в языковых моделях.
LangSmith
Promptfoo
OWASP LLM Top 10
Раздел 3. Практические инструменты и метрики оценки качества LLM и RAG
LLM-as-Judge: как работает и какие ловушки существуют. Оценка ответов модели с помощью другой модели — распространённый подход, известный как LLM-as-Judge. Судья получает вопрос, эталонный ответ и ответ тестируемой системы, после чего выставляет оценку. Такой подход лучше текстового сравнения, поскольку не штрафует за другие формулировки, если смысл сохранён. Однако судья не идеально объективен: исследования выявляют позиционное смещение (ответ оценивается выше, если стоит на определённой позиции в промпте) и предпочтение более подробных ответов, даже если они не точнее .
Метрики оценки ответов RAG: coverage, groundedness, factuality. Одна общая оценка «хорошо или плохо» бесполезна для улучшения системы, потому что непонятно, что именно нужно исправлять. Практика показывает, что качество ответа нужно разложить на отдельные подметрики.
- Coverage — насколько ответ покрывает эталон по смыслу, донесены ли ключевые факты, а не просто использованы похожие слова.
- Groundedness — насколько ответ опирается на тот контекст, который был передан модели. Для RAG это критично: ответ может выглядеть убедительно, но быть построен не по найденным чанкам, а по «общим знаниям» модели.
- Factuality — насколько ответ корректен по фактам относительно эталона. Ответ может хорошо опираться на контекст, но содержать одну-две фактические ошибки .
Метрики retrieval и generation: их нужно разделять. В RAG-системах важно отделять качество поиска (retrieval) от качества генерации. Для retrieval применяют свои метрики: Recall@K, Hit Rate, MRR. Они показывают, нашёл ли поиск нужный документ и насколько высоко тот оказался в выдаче. Для generation проверяют correctness, faithfulness, relevance и корректность ссылок на источники. Если пользователь получил неправильный ответ, это может быть как Retrieval Failure (документ не найден), так и Generation Failure (документ был в контексте, но модель его проигнорировала) .
Построение тестового набора (dataset). Evaluation начинается не с выбора метрики, а с датасета. Один тестовый кейс должен содержать: input (запрос пользователя), expected_behavior (ожидаемое поведение системы), category (категория сценария) и risk (уровень риска). Эталонный ответ не обязателен — важнее зафиксировать ожидаемое поведение. Например: «система не должна угадывать условия отмены, а должна запросить недостающие данные». Такие кейсы часто полезнее идеально сформулированного reference answer .
DeepEval: практический фреймворк для оценки диалогов. DeepEval — open-source фреймворк для оценки LLM, позволяющий создавать тестовые кейсы для диалогов. Установка: pip install deepeval. Пример создания диалогового тест-кейса:
from deepeval.test_case import ConversationalTestCase
convo_test_case = ConversationalTestCase(
chatbot_role='You are a happy jolly CS agent',
turns=[
LLMTestCase(input='Hi', actual_output='Hey how can I help?'),
LLMTestCase(input='I just want someone to talk to', actual_output='No problem I am here to listen!')
]
)Каждый ход диалога — это LLMTestCase, где input — запрос пользователя, а actual_output — ответ чат-бота. После создания тест-кейса можно применить метрику, например KnowledgeRetentionMetric, для оценки того, насколько хорошо бот сохраняет информацию на протяжении диалога .
Какая метрика оценивает, насколько ответ RAG-системы опирается именно на переданный контекст, а не на «общие знания» модели?
Groundedness
Groundedness (обоснованность) показывает, насколько ответ опирается на тот контекст, который был передан модели. Для RAG-систем это критически важно: ответ может выглядеть убедительно, но быть построен не по найденным чанкам, а по внутренним знаниям модели, что ведёт к галлюцинациям .
Coverage
Recall@K
Factuality
Какие две основные проблемы LLM-as-Judge выявлены в исследованиях?
Позиционное смещение и предпочтение более подробных ответов
Исследование Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena описывает, в частности, позиционное смещение (ответ оценивается выше или ниже в зависимости от позиции в промпте) и предпочтение более подробных ответов, даже если они не точнее по содержанию .
Галлюцинации и утечка системного промпта