Ссылка в ответе ещё не делает ответ проверяемым

RAG-система может красиво поставить маркер «[1]» после абзаца и при этом сослаться на документ, который подтверждает только соседнюю мысль. Иногда модель придумывает название файла, путает редакции договора или ставит одну ссылку после нескольких разных утверждений. Для пользователя такой ответ выглядит надёжнее, чем является на самом деле.

Исследование ALCE предложило оценивать ответы с цитатами не только по связности, но и по качеству ссылок. В одном из исследованных наборов даже лучшие протестированные системы не давали полной цитатной поддержки примерно в половине случаев. Более поздняя работа Correctness is not Faithfulness in RAG Attributions разделяет два вопроса: поддерживает ли источник утверждение и действительно ли ответ был построен на этом источнике, а не получил подходящую ссылку постфактум.

Для бизнеса вывод простой: маркеры цитат нельзя полностью доверять генеративной модели. Надёжный контур должен хранить происхождение фрагмента, разрешать модели ссылаться только на выданные идентификаторы, проверять соответствие утверждения доказательству и строить кликабельную ссылку на сервере.

Какой результат нужен пользователю

Проверяемая ссылка должна отвечать на четыре вопроса без нового поиска:

  • какой именно документ использован;
  • какая редакция документа была актуальна во время ответа;
  • на какой странице или в каком разделе находится основание;
  • какой фрагмент поддерживает конкретное утверждение.

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

Практичный интерфейс показывает короткий ответ, маркер доказательства после каждого проверяемого утверждения и боковую карточку с названием, версией, страницей, датой действия и небольшим фрагментом. По клику открывается исходник на нужном месте. Если точного положения нет, система честно указывает уровень привязки: документ, раздел, страница или диапазон символов.

Происхождение начинается при загрузке документа

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

Для каждого документа полезно хранить:

  • внутренний document_id, не зависящий от имени файла;
  • хеш исходных байтов и номер редакции;
  • владельца, дату действия и статус публикации;
  • связь с предыдущей и следующей редакциями;
  • источник и правила доступа.

Для каждого чанка нужны chunk_id, document_id, version_id, текст, заголовочный путь, номера страниц, символьный диапазон и при возможности координаты на странице. Формат DoclingDocument, например, содержит provenance с page_no, bounding box и charspan. Это позволяет открыть PDF на нужной странице и подсветить область, не спрашивая модель, где она её увидела.

Идентификатор чанка должен воспроизводиться при повторной обработке той же редакции. Подойдёт хеш от version_id, структурного пути и нормализованного текста.

Архитектура ответа с доказательствами

Рабочий запрос проходит шесть контролируемых этапов.

1. Поисковый слой получает вопрос и права пользователя, затем возвращает разрешённые чанки с устойчивыми идентификаторами и метаданными происхождения.
2. Реранкер сокращает набор, не удаляя связь с исходниками. Каждому фрагменту назначается короткий временный evidence_id, например E1 или E2.
3. Модель получает только текст доказательств и эти временные идентификаторы. В структурированном ответе каждое фактическое утверждение содержит список evidence_ids. Модель не пишет URL, путь к файлу или номер страницы сама.
4. Валидатор проверяет схему: все идентификаторы существуют, доступны пользователю и относятся к активной редакции. Неизвестный маркер отклоняется.
5. Проверяющий модуль сопоставляет утверждение и фрагмент. На первом этапе можно использовать правила и отдельную модель-классификатор, но для критичных процессов спорные случаи отправляются человеку или превращаются в отказ.
6. Сервер заменяет E1 на безопасную ссылку из реестра документов, добавляет название, версию и страницу. Именно приложение, а не LLM, определяет конечный адрес.

Такая схема отделяет генерацию текста от маршрутизации данных. Даже если модель попытается выдумать E99, валидатор не найдёт его в наборе поиска. Если документ отозван, сервер может скрыть ссылку и потребовать новый ответ по актуальной версии.

Точная цитата и смысловая поддержка — разные проверки

Для дословного утверждения полезна детерминированная проверка: цитируемая строка после нормализации пробелов должна находиться в сохранённом чанке и попадать в известный диапазон исходника. Это дешёвый и хорошо объяснимый контроль.

Но большинство деловых ответов перефразирует источник. Тогда точного совпадения нет. Проверка должна определить, следует ли утверждение из фрагмента, не добавляет ли новые числа, условия или причинность. Автоматический классификатор полезен для массового контроля, но его результат тоже не является доказательством истины. Для сумм договоров, нормативных сроков, платёжных реквизитов и решений с юридическим эффектом нужен детерминированный источник либо подтверждение человека.

Отдельно измеряйте полноту: все ли существенные утверждения получили основание. Один правильный маркер после длинного абзаца может давать хорошую «точность ссылок», но скрывать неподтверждённые выводы. ALCE как раз разделяет качество ответа и качество цитирования; этот принцип удобно перенести в приёмочные тесты.

Версии, отзыв и права доступа

Ссылка должна указывать на ту редакцию, которая участвовала в ответе. Если политика запрещает показывать старую версию, система не должна тихо перенаправлять пользователя на новую: содержание могло измениться. Лучше пометить ответ устаревшим и предложить пересчитать его.

Реестр источников хранит состояние версии: active, superseded, revoked или deleted. При изменении документа событие инвалидирует связанные кэши. В интерфейсе видно, когда был построен ответ и актуальны ли его доказательства сейчас.

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

Модельная экономика пилота

Предположим, база знаний содержит 20 тысяч документов, а сотрудники задают 1000 вопросов в день. Добавление provenance почти не меняет стоимость генерации: это несколько полей на чанк и реестр версий. Основные расходы появляются на проверке утверждений и хранении воспроизводимого журнала.

Не обязательно проверять отдельной моделью каждый служебный ответ. Можно выбрать уровни риска:

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

Это модельные допущения, а не тариф. Для сравнения вариантов считайте стоимость одного принятого ответа: генерацию, проверку, долю отказов и минуты эксперта. Дешёвая система, которая регулярно ведёт сотрудника к неверной редакции, создаёт скрытые расходы намного выше цены токенов.

Метрики, которые можно проверить

Для пилота достаточно 100–200 реальных вопросов и двух оценщиков предметной области. Размечайте не «понравился ли ответ», а отдельные свойства.

  • Citation validity: каждый маркер существует и открывает доступный источник.
  • Citation correctness: источник действительно поддерживает утверждение.
  • Citation completeness: все существенные утверждения имеют поддержку.
  • Anchor accuracy: ссылка ведёт на правильную страницу или диапазон.
  • Version correctness: использована действующая редакция либо явно показана старая.
  • Abstention quality: система отказывается, когда доказательств недостаточно.

Ragas определяет faithfulness как долю утверждений ответа, поддержанных полученным контекстом. Эта метрика полезна для автоматического регрессионного теста, но не заменяет ручную выборку. NIST в профиле управления рисками генеративного ИИ также рекомендует проверять источники и цитаты до запуска и в ходе мониторинга.

Задайте пороги по риску процесса. Для справочного FAQ допустима мягкая деградация, а для ответа о договорном сроке неподтверждённое число должно приводить к отказу, а не к уверенной фразе без ссылки.

Двухнедельный следующий шаг

В первую неделю выберите один набор регламентов, сохраните версии и provenance при индексации, а затем заставьте модель возвращать JSON с утверждениями и evidence_ids. Сервер должен отклонять неизвестные идентификаторы и строить ссылки только по своему реестру.

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

Успех пилота — не сто процентов ответов. Хороший результат означает, что система либо показывает проверяемое основание, либо ясно отказывается; старая редакция не маскируется под новую; чужой источник не открывается; ошибочный маркер не проходит валидатор.

Практический вывод

Проверяемый RAG строится вокруг реестра происхождения, а не вокруг красивого формата ответа. Сохраняйте версию, страницу и координаты при загрузке, выдавайте модели только временные идентификаторы доказательств, проверяйте их на сервере и формируйте конечные ссылки вне LLM. Измеряйте правильность и полноту цитирования отдельно.

Первый управленческий тест занимает час: попросите систему ответить по отменённой редакции, привести неподтверждённое число и сослаться на несуществующий E99. Если интерфейс не отличает эти случаи от нормального ответа, цитаты пока декоративны, а не проверяемы.