Ваша підсистема 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-адреса з перенаправленням, сторінка у два стовпці, таблиця з примітками та дві версії одного й того ж документа. Перевірте отриманий результат перед оцінкою релевантності у пошуку.
Ширший процес оцінки має дозволяти розрізняти відсутність доказів, погану класифікацію та генерацію без підтримки. Інакше проблема з пошуком може змусити вас повернутися до початкового запиту, тоді як справжня проблема залишиться у вихідних даних.
Перший корисний етап є простим: кожен запис має пояснювати, що є у наявності та звідки воно походить. Як тільки це буде досягнуто, подальші покращення стануть легшими для інтерпретації.