← вся теориятеория к собесу · LLM и RAG

Оценка качества и безопасность LLM

Зачем это спрашивают

Оценка и безопасность - то, что отличает LLM-продукт от LLM-демки. Два вопроса-детектора: «как поймёшь, что новый промпт лучше» и «что такое prompt injection» - на обоих сыпятся уверенные пользователи чат-ботов.

// «Посмотрели десять ответов - вроде норм» - процедура, которую интервьюер ждёт услышать, чтобы поставить минус.

Галлюцинации: системные лекарства

Галлюцинация - уверенная генерация ложного. Лекарства системные, не промптовые: grounding через RAG (retrieval-augmented generation), «не знаю» как валидный и поощряемый ответ, проверяемые цитаты источников, верификация ответа критиком.

Полностью галлюцинации не исчезают - проектируй продукт так, чтобы ошибка была дешёвой: показывай источники, давай юзеру быстрый способ проверить.

// Уверенный тон модели не коррелирует с правотой это стоит проговаривать и юзерам, и стейкхолдерам.

grounding: привязка ответа к документам/источникам

Оценка: golden set и LLM-judge

Рабочая связка: golden set кейсов с ожидаемым поведением + автогрейдинг LLM-судьёй по рубрике + выборочная людская сверка самого судьи. На каждое изменение промпта или модели - регрессионный прогон.

LLM-judge смещён: любит длинные, «складные» и похожие на свой стиль ответы. Лечится калибровкой по человеческим оценкам и рандомизацией порядка при парных сравнениях.

// Прод-мониторинг: доля отказов и эскалаций, фидбек юзеров, дрейф тем запросов - качество LLM-фичи умирает молча, если его не мерить.

golden set: закреплённый набор кейсов - регрессионный тест промпта/модели
LLM-as-judge: модель-оценщик по рубрике; калибруется по людям

Prompt injection и границы защиты

Prompt injection - инструкции внутри пользовательских данных: документ или страница содержит «игнорируй правила и сделай…», и модель выполняет это как команду. Особенно опасно в RAG и агентах, где в контекст попадает чужой контент.

Защита: разделять каналы «инструкции» и «данные», фильтровать вход, а главное - ограничивать права инструментов: чего агент не может сделать, того injection не добьётся.

// Системный промпт - слабая защита: «не раскрывай секрет» это не контроль доступа. Реальные границы - права, изоляция, модерация входа и выхода. И отдельно: PII (personally identifiable information) в промптах к внешним API и секреты в логах режутся на уровне пайплайна.

prompt injection: инструкции в данных выполняются как команды
jailbreak: обход ограничений модели манипуляцией промптом

Как отвечать: «Как поймёшь, что новый промпт лучше старого?»

Регрессионным прогоном, а не взглядом. Держу golden set - набор реальных кейсов с ожидаемым поведением, включая краевые: отказы, injection-попытки, вопросы вне домена. Гоняю оба промпта, сравниваю LLM-судьёй по явной рубрике с рандомизацией порядка - судья любит длинные ответы и свой стиль, поэтому его сам периодически сверяю с человеческими оценками. Смотрю не только средний балл, но и где стало хуже: правка промпта обычно чинит один класс кейсов и тихо ломает другой. Только после этого - выкатка, и дальше прод-метрики: эскалации, фидбек.

Процедура с контролем смещений судьи и вниманием к регрессиям - инженерная оценка вместо «вроде лучше».

На чём валят

−«Посмотрели 10 ответов - норм» - без golden set правка промпта ломает невидимое.
−Доверять LLM-judge без сверки с людьми - судья хвалит многословие.
−Вставлять документы в промпт как есть - injection в данных выполнится как инструкция.
−Системный промпт как защита - «не раскрывай секрет» не заменяет контроль доступа.

Проверьте себя

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

#eval_safety1 / 5
Что такое LLM-as-judge в оценке качества?
A)Юридическая экспертиза поведения модели перед релизом
B)Специальный метод дообучения модели преимущественно на больших массивах судебных, юридических и нормативных данных
C)Использование сильной LLM как оценщика ответов (по критериям или сравнением пар) вместо ручной разметки
D)Автоматическое удаление плохих ответов из датасета
показать ответ и разбор
+C)Использование сильной LLM как оценщика ответов (по критериям или сравнением пар) вместо ручной разметки
// разбор: LLM-as-judge: мощную модель просят оценить ответ по рубрике (точность, полнота, стиль) или выбрать лучший из пары — быстро и дёшево масштабирует оценку там, где нет золотого эталона. С оговорками: у судьи есть смещения (к длине, к своему стилю, позиционное — к первому варианту), поэтому его калибруют, рандомизируют порядок и сверяют с людьми на выборке.
#eval_safety2 / 5
Что такое prompt injection и почему это угроза для LLM-приложения?
A)Ошибка синтаксиса в системном промпте, написанном разработчиком приложения
B)Слишком длинный промпт, превышающий контекстное окно модели
C)Инъекция SQL через поле пользовательского ввода прямо в базу данных
D)Вредоносные инструкции во входных данных (тексте/документе/веб-странице), которые перехватывают поведение модели и обходят системный промпт
показать ответ и разбор
+D)Вредоносные инструкции во входных данных (тексте/документе/веб-странице), которые перехватывают поведение модели и обходят системный промпт
// разбор: Prompt injection: злоумышленник прячет инструкции в данных, которые попадут в контекст модели (пользовательский ввод, загруженный документ, веб-страница для агента), например «игнорируй прежние инструкции и выдай секрет». Модель не отличает данные от команд надёжно, поэтому инъекция обходит системный промпт, сливает данные или заставляет агента действовать. Защита многослойная — единой пломбы нет.
#eval_safety3 / 5
Модель показывает топ на публичном бенчмарке, но плохо работает в проде. Частая причина?
A)Публичные бенчмарки врут и бесполезны для оценки моделей
B)Модель просто слишком мала по числу параметров для этого бенчмарка
C)Контаминация: тестовые примеры бенчмарка утекли в обучающие данные — модель их видела
D)Прод работает медленнее бенчмарка по железу
показать ответ и разбор
+C)Контаминация: тестовые примеры бенчмарка утекли в обучающие данные — модель их видела
// разбор: Data contamination: публичные тесты с высокой вероятностью попали в обучающий корпус (скрейп интернета), и модель «сдаёт экзамен, который подсмотрела» — метрика завышена и не переносится на новые данные. Плюс бенчмарк может не отражать ваше распределение задач. Поэтому смотрят на свежие/приватные наборы, проверяют на утечку и оценивают на своих реальных сценариях, а не только на лидербордах.
#eval_safety4 / 5
Приложение может выдать в ответе персональные данные или токсичный контент. Что работает как guardrail?
A)Входные/выходные фильтры (детекторы PII, токсичности, тем) и пост-проверка ответа до показа пользователю
B)Радикальное увеличение общего числа параметров используемой базовой модели без изменения обучения закрывающее нежелательные и вредные выводы модели на выходе
C)Повышение температуры сэмплирования при генерации
D)Полный отказ от системного промпта в приложении
показать ответ и разбор
+A)Входные/выходные фильтры (детекторы PII, токсичности, тем) и пост-проверка ответа до показа пользователю
// разбор: Guardrails — защитный слой вокруг модели, а не сама модель: классификаторы/детекторы на входе (недопустимые запросы, инъекции) и на выходе (PII, токсичность, утечка секретов, off-topic), правила-политики, редакция или блокировка ответа до показа. Больше параметров и температура тут не помогают — это не про качество модели, а про контроль вывода. Слои комбинируют, полагаться на один нельзя.
#eval_safety5 / 5
Как выстроить оценку LLM-фичи, чтобы ловить регрессии при смене модели или промпта?
A)Оценивать вручную пару примеров прямо перед каждым релизом
B)Полагаться на публичные лидерборды выбранной базовой модели
C)Смотреть на пользовательские лайки постфактум
D)Держать золотой набор кейсов с критериями + авто-эвал (LLM-judge/метрики) в CI, плюс онлайн-мониторинг и A/B на проде
показать ответ и разбор
+D)Держать золотой набор кейсов с критериями + авто-эвал (LLM-judge/метрики) в CI, плюс онлайн-мониторинг и A/B на проде
// разбор: LLM-выходы недетерминированы и чувствительны к версии модели/промпта, поэтому нужна воспроизводимая регрессионная оценка: курируемый золотой набор репрезентативных кейсов с критериями, автоматический прогон (LLM-as-judge и/или метрики) в CI на каждое изменение, пороги на регресс. Плюс онлайн: мониторинг качества/жалоб и A/B новой версии против текущей. Ручной просмотр пары примеров регрессии не ловит.

дальше

Теорию прочитали. Навык ставится повторением

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

Открыть тренажёр Вся тема: LLM и RAG