Ваша пайплайн RAG запускается до первого встраивания.

Система поиска может вернуть связный ответ из документа, который вообще не должен был попасть в её базу данных. Заголовок может принадлежать одной странице, в то время как URL указывает на другую. Сохранённая страница может содержать лишь предварительный просмотр. Таблица при извлечении может остаться в виде списка чисел без соответствующих меток.

Включение таких данных в базу делает их доступными для поиска, но это не делает их надёжными.

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

Разделение процесса поиска источников от самих источников

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

Явно указывайте наличие текста. К полезным состояниям относятся только метаданные, текст, извлечённый с неизвестной степенью полноты, проверенный полный текст и ситуации конфликта идентичности. Избегайте использования единственного флага indexed: true, который скрывает все четыре ситуации.

Минимальная запись может выглядеть следующим образом:

{
  "source_id": "article-42",
  "canonical_url": "https://example.com/article-42",
  "content_status": "extracted_text",
  "completeness": "unverified",
  "content_hash": "sha256-of-extracted-text",
  "retrieved_at": "2026-09-17T12:00:00Z"
}

Хеш идентифицирует версию текста. Он не является мерой его достоверности. Аналогично, длинный фрагмент извлечённого текста свидетельствует о наличии текста, но не доказывает, что барьер оплаты, сбой парсера или ограничения навигации не изменили его.

Сохраняйте отношения, имеющие смысл

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

Рассмотрим руководство по техническому обслуживанию, в котором перечислены компоненты, интервалы их проверки и условия, при которых эти интервалы меняются. Сохранение только интервалов даёт убедительный, но неполный ответ. Прежде чем рассматривать векторное сходство, необходимо сохранить метки и исключения вместе.

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

Сделайте сбои видимыми, не удаляя информацию о запасах

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

Такое различие позволяет использовать два разных подхода к работе. Поиск для технического обслуживания направлен на выявление того, что требует ремонта. Поиск ответов направлен на определение того, какие источники могут подтвердить ту или иную гипотезу. Они не должны без объяснений возвращать один и тот же набор записей.

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

Проверяйте качество источников в рамках разработки продукта

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

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

Первая полезная веха довольно проста: каждая запись должна объяснять, что имеется в наличии и откуда оно взято. Как только это будет соблюдаться, последующие улучшения станут легче интерпретировать.