Как проверить RAG-шаблон LlamaIndex RichPromptTemplate до вызова модели

1. Определите входы context_str и query_str и отдельно зафиксируйте разрешённый источник контекста.
2. Запишите шаблон с явным правилом отвечать лишь по предоставленному тексту и сообщать об отсутствии факта.
3. Выполните format на одном положительном тесте, затем на пустом контексте; посмотрите полученные строки.
4. Для chat API проверьте format_messages и структуру ролей перед сетевым вызовом.
5. В отдельно размеченном тесте LLM проверьте ответы на факт, отсутствующий факт и вредоносную инструкцию внутри источника.

Готовый шаблон Python

from llama_index.core.prompts import RichPromptTemplate

template = RichPromptTemplate("""Контекст документа:
{{ context_str }}
Вопрос пользователя: {{ query_str }}
Отвечай только по контексту; если факта нет, напиши «Нет данных».
Ответ с проверяемым фрагментом: """)
prompt = template.format(
    context_str="Политика R7: срок возврата 14 дней.",
    query_str="Каков срок возврата?",
)
print(prompt)
print(template.format_messages(context_str="", query_str="Адрес офиса?"))

Код ниже в статье предназначен для тестовых источников без персональных сведений. Вызовы SDK не выполнялись в данном окружении с реальной моделью; синтаксис Python проверен отдельно. Не переносите вывод демонстрационного эксперимента на любой корпус и любого провайдера без повторной проверки.

Пример входа и ожидаемого результата

Вход: контекст «срок возврата 14 дней» и вопрос о сроке. Ожидаемая сформированная строка содержит вопрос, факт и инструкцию о запрете догадок. Во втором примере пустой контекст и вопрос об адресе: рендеринг допустим, но ожидаемый ответ «Нет данных» сможет подтвердить только последующий тест модели.

Сохраните входные файлы, идентификаторы документов и ожидаемое утверждение в отдельном проверочном наборе. При неуспехе выделяйте слой ошибки: чтение источника, преобразование в nodes, получение embedding, поиск, синтез ответа или UI. Правильная форма ответа ещё не гарантирует правильного происхождения сведений.

Диагностика и границы решения

У шаблона две разные проверки. Первая — детерминированный рендеринг: подставились ли переменные, сохранилась ли кириллица, не исчезло ли отрицание. Вторая — поведение генератора: следует ли он ограничению «только по контексту». Успех первой не гарантирует второй. Если пользователь может управлять context_str, он может поместить туда инструкцию «игнорируй правила»; обрабатывайте источник как недоверенные данные и отдельно проверяйте изоляцию ролей. Шаблон не узнаёт самостоятельно, какой из двух противоречащих документов действует сейчас; актуальность и полномочия решаются до подачи контекста. Не подменяйте query_str содержимым другого пользователя при кешировании. При длинном context_str измеряйте фактическое число токенов модели, иначе нужный факт может быть обрезан. Из примера нельзя выводить названия настроек графического интерфейса: здесь только Python API.

Дополнительный проверочный сценарий

Сделайте набор из четырёх кейсов: найденный срок 14 дней, отсутствующий адрес, текст с двумя редакциями сроков и контекст с инструкцией-вредителем. На этапе format проверяйте точное включение только разрешённых данных; на этапе LLM сравнивайте фактические ответы с ручной разметкой. Для конфликтных редакций промпт должен получать от приложения только актуальный источник либо явно помеченные версии, иначе модель выберет случайное правило. Если вам требуется структурированный вывод, не считайте добавление слова «JSON» в текст гарантией валидной схемы: нужна отдельная проверка результата. При редактуре шаблона сохраняйте тестовые снимки строк, чтобы видеть, не поменялся ли порядок и роль контекста. Для воспроизводимости фиксируйте версию LlamaIndex и настройки используемой модели.

Критерии проверки