Итоговый проект: ассистент с проверяемыми источниками

Автор: Казачкин Даниил Михайлович · Обновлено 19 августа 2026 г.

В итоговом проекте вы спроектируете ассистента, который отвечает только по выбранному корпусу, показывает доказательства, признаёт отсутствие данных и измеряется до релиза. Цель — применить генерацию, retrieval, безопасность и evals как единую систему, а не собрать эффектную демонстрацию без контроля.

Шаг 1. Спецификация и границы

Выберите небольшой корпус: например, 20 публичных учебных правил с ясными версиями и лицензиями. Опишите пользователя и три задачи: найти правило, сравнить два пункта, объяснить простыми словами. Запретите принятие юридических или административных решений.

Задайте критерии:

• ответ содержит только поддержанные утверждения;
• каждая фактическая часть имеет идентификатор источника;
• при отсутствии доказательства система отказывается;
• документы с истёкшей версией не используются;
• ни один пользователь не видит недоступный источник;
• p95 latency и стоимость укладываются в установленный бюджет.

Шаг 2. Подготовка корпуса

Для каждого документа сохраните URL, название, дату действия, лицензию или основание использования, версию и владельца. Создайте datasheet: что включено, что исключено, как обновляется и какие языки поддерживаются.

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

Шаг 3. Retrieval и генерация

Реализуйте baseline полнотекстового поиска, затем dense или hybrid retrieval. Измерьте recall на наборе вопросов до подключения генерации. Если нужный chunk не входит в top-k, prompt не исправит проблему.

Передайте модели фрагменты с устойчивыми ids. Инструкция должна требовать: использовать только контекст, ссылаться на ids, разделять цитату и вывод, говорить «в предоставленных документах нет ответа» при недостатке доказательств. Валидатор отклоняет неизвестные ids.

Шаг 4. Защита и отказоустойчивость

Аутентификация и ACL выполняются до поиска. Недоверенный текст документа не может вызвать инструмент или изменить системную policy. Ограничьте длину, число retrieval candidates, время и повторы.

Сценарии fallback:

• retrieval недоступен — показать обычный каталог или временную ошибку;
• модель недоступна — вернуть найденные выдержки без синтеза;
• ответ не прошёл схему — одна контролируемая повторная попытка, затем отказ;
• пользователь просит действие вне scope — объяснить границу и безопасный следующий шаг.

Шаг 5. Eval-набор

Создайте минимум 40 примеров:

• прямые факты;
• объединение двух chunks;
• похожие формулировки;
• устаревшие версии;
• вопрос без ответа;
• ложная предпосылка;
• prompt injection внутри документа;
• запрос к запрещённому источнику.

Отдельно измерьте retrieval recall@k, correctness, groundedness, source precision, корректный отказ, latency и стоимость. Не сводите всё к среднему: нарушение ACL является блокирующей ошибкой независимо от общего балла.

Шаг 6. Model card и запуск

Оформите model/system card: назначение, компоненты, версии, данные eval, ограничения, известные провалы, контакты владельца и дата пересмотра. Это снимок измеренного состояния, а не рекламное обещание.

Проведите canary на ограниченной аудитории. Собирайте feedback с категорией ошибки, а не только «палец вниз». Новые реальные провалы после безопасной редакции добавляйте в regression suite. Подготовьте rollback индекса, prompt и модели как согласованной версии.

Упражнение: защита проекта

Продемонстрируйте три запроса: корректный ответ с источником, честный отказ и попытку injection. Покажите trace retrieval и объясните, какой слой остановил опасное поведение.

Затем представьте таблицу eval до и после улучшения. Если метрика выросла, но latency или отказы ухудшились, обсудите компромисс. Хорошая защита показывает не только успех, но и известную границу.

Что важно запомнить

• Итоговый ассистент строится вокруг проверяемого корпуса и явных критериев.
• Retrieval оценивают отдельно до генератора, а citations валидируют кодом.
• ACL, отказ, fallback и prompt-injection тесты входят в основной функционал.
• Model card, canary, мониторинг и rollback превращают прототип в управляемый продукт.

Частые вопросы

Обязательно обучать собственную модель?

Нет. Цель проекта — надёжная система. Готовая модель с качественным retrieval, policy и evals часто является правильным инженерным baseline.

Сколько документов нужно для настоящего RAG?

Даже небольшой корпус позволяет проверить весь цикл. Важнее версии, metadata, сложные вопросы и измерение retrieval, чем искусственно большой объём.

Когда проект можно считать завершённым?

Когда критерии приняты на зафиксированном eval, блокирующие safety-тесты пройдены, известные ограничения документированы, а мониторинг и rollback готовы. «Ответ выглядит хорошо» недостаточно.