RAG улучшил работу только тогда, когда человек лучше выполняет определённую задачу в согласованных ограничениях. Более точный поиск, больше цитат и рост числа запросов могут поддерживать результат, но сами по себе его не доказывают. Измерение должно связать найденные источники, принятый ответ, завершённый процесс и наблюдаемый итог работы.
Сначала выберите одну задачу: подготовку справки о клиенте, ответ по внутреннему правилу, разбор обращения в поддержку, проверку договорного пункта или поиск последней процедуры. Назовите пользователя, начальное событие, принятую форму результата, границу допустимого риска и систему, куда должен попасть итог.
Свяжите поиск с результатом работы
На первом уровне проверьте, находит ли система авторитетные источники, нужные для задачи. Используйте версионный набор вопросов с ожидаемыми документами или фрагментами. Оценивайте соответствие запросу, полноту охвата, порядок выдачи, лишние повторы, соблюдение прав, свежесть и правильный отказ при отсутствии подтверждений.
На уровне ответа оценивайте правильность, опору на источники, полноту, полезность цитат, соблюдение инструкции, честное обозначение неопределённости, безопасность и соответствие исходному материалу. Различайте ошибку поиска и ошибку формирования ответа. Сильная модель не ответит по данным, которых не получила, а хороший поиск не гарантирует честного вывода.
Контроль утверждений дополняют правила против выдуманных фактов. Они помогают заранее определить, когда ответ обязан сослаться на источник, назвать неопределённость или отказаться от вывода.
На уровне работы наблюдайте завершение задачи, общее время и активное время сотрудника, число исправлений, передач между участниками, повторной работы и обращений к специалисту, а также тяжесть ошибки и доставку результата в целевую систему. Частота использования полезна, но сама по себе не равна ценности.
Проверяйте качество и после передачи результата. Сотрудник мог принять ответ, а затем вручную перепроверить каждый факт, переписать итог или исправить запись в рабочей системе. Поэтому фиксируйте не только нажатие кнопки и статус завершения, но и время скрытой проверки, возвраты от следующего участника, повторное открытие задачи и поздно найденные дефекты. Для чувствительных случаев отдельно считайте правильные остановки и передачу решения человеку. Такой отказ может выглядеть как незавершённая автоматизация, хотя он предотвращает серьёзную ошибку.
Сравнивайте с честным исходным уровнем
Измерьте текущий процесс до запуска новой версии. Исходным уровнем может быть ручной поиск, внутренняя справочная система, поиск по ключевым словам или прежняя настройка RAG. Используйте одинаковые примеры, критерии приёмки, группы пользователей и правила наблюдения. Записывайте изменения источников, обучения, состава команды и других инструментов.
Разделяйте результаты по сложности, виду источника, языку, возрасту сведений, чувствительности, опыту пользователя и последствиям ошибки. Хорошее среднее может скрыть редкий критичный провал. Добавьте отрицательные случаи, где правильный ответ сообщает об отсутствии утверждённых подтверждений.
При субъективной оценке опорой остаётся проверка специалиста. Модель для предварительной оценки настраивайте по решениям профильных экспертов, а расхождения разбирайте. По возможности проверяющий не должен знать, какую версию системы он оценивает. Сохраняйте вопрос, найденные подтверждения, ответ, оценку, объяснение и итоговое решение о приёмке.
Перед пилотом полезно пройти тесты готовности команды. Без владельца процесса, главного источника и места назначения даже высокая оценка RAG не превращается в улучшение работы.
Превратите измерения в решение
До пилота задайте критерии успеха и остановки. Выпуск может требовать отсутствия ухудшений в рискованных группах, снижения числа исправлений, роста доли принятых результатов и устойчивого соблюдения прав. Определите причины для отката, сбора дополнительных подтверждений, очистки источников, изменения поиска или обучения пользователей.
Проведите ограниченный пилот с журналированием, соответствующим правилам работы с данными. Сравните ожидаемые и наблюдаемые результаты, затем сгруппируйте причины сбоев. Нехватка подтверждений требует исправления работы с источниками. Плохой порядок выдачи требует настройки поиска. Подтверждённый, но бесполезный ответ может означать, что нужно изменить форму задачи.
Повторяйте оценку после изменения источника, модели, инструкции, прав доступа или рабочего процесса. Журнал решений должен содержать версию, владельца, результат, ограничение, принятое действие и дату следующей проверки. Нельзя превращать процент улучшения из малого внутреннего испытания в универсальное обещание продукта.
Коммерческую проверку дополняют вопросы перед покупкой ИИ: какой процесс меняется, как измеряется результат и кто отвечает за решение.
MYOD.IT публикует практические разборы интеграции ИИ и проверки качества, что даёт основу для этой цепочки измерений. Здесь нет подтверждения достигнутой точности, сокращения времени, экономии или результата клиентского внедрения.
Частые вопросы
Одна метрика ничего не доказывает. Нужна цепочка от качества поиска и ответа до принятого завершения задачи, исправлений, времени, риска и результата в целевой системе.
Релевантный текст может привести к неверному, неполному, неразрешённому или бесполезному ответу, который не сокращает работу.
Текущий способ выполнения той же задачи с теми же примерами, критериями и правилами наблюдения, с учётом изменений в составе людей, источников и инструментов.
Настроить его по решениям профильных экспертов, разбирать расхождения, сохранять объяснения и оставлять человеческое решение опорой для субъективных и рискованных случаев.
Если нужна оценка RAG, связанная с рабочим процессом и принятым результатом, рассмотрите услуги MYOD по внедрению ИИ. Пилот должен завершаться исходными измерениями, набором испытаний, разбором видов ошибок, проверкой прав, рабочими показателями и решением продолжать, изменить или остановить проект.
