«Пилот прошёл хорошо» — фраза, которая ничего не говорит ни инженеру, ни юристу, ни финансовому директору. Хорошо — это как? Ответы были точными? Все 50 контрольных вопросов или только 30? Систему проверяли на вопросах, которые реально задают пользователи, или на тех, что удобно показать на демонстрации?
Разница между «понравилось» и «прошло приёмку» — это матрица метрик, а не субъективное впечатление от нескольких красивых ответов. Нужно отдельно проверить: найден ли правильный документ, верна ли цитата, отвечает ли текст на вопрос целиком, не добавляет ли модель ничего от себя, и укладывается ли ответ в приемлемое время.
Обзоры по оценке RAG — Yu и соавторы (2024), Gao и соавторы (2023) — разводят эти уровни явно: качество retrieval (найден ли нужный фрагмент), качество генерации, то есть faithfulness (насколько ответ верен найденному контексту), и итоговую полезность для пользователя, которая не сводится к первым двум и требует отдельной проверки.
Latency стоит в этом списке отдельно, потому что это не техническая деталь, а условие использования: точный ответ, приходящий через 30 секунд, может просто не вписаться в рабочий процесс диспетчера или инженера на площадке — и тогда систему перестанут открывать, независимо от того, насколько она точна.
Прежде чем запускать пилот, стоит зафиксировать три вещи на бумаге, а не держать в голове: список из 30-50 контрольных вопросов с заранее известным правильным источником; порог допустимой latency для конкретного сценария использования; и явное правило, что считается корректным ответом «недостаточно данных» — вместо того чтобы разбирать это постфактум, когда система уже что-то придумала.
Разница между обычной демонстрацией и Knovium-пилотом в том, что здесь заранее видно, где система не справилась: журнал отказов и частичных ответов ведётся наравне с успешными, и три состояния ответа — найден, найден частично, недостаточно данных — фиксируются по каждому из контрольных вопросов, а не только по тем, что получились хорошо.