Предотвратяване на отравянето на RAG данни: произход на източниците, карантина и тестове за повторно индексиране

Уебсайт чатбот може да предостави любезен, езиково убедителен и технически правилно генериран отговор – и въпреки това да работи върху отровена база от знания. При отравянето на RAG данни (data poisoning) основно не се манипулира формулировката на отделно запитване. Вместо това грешно, изкривено или недостатъчно проверено съдържание навлиза в постоянната верига от данни: източник, парсер, chunk, метаданни, embedding и накрая продуктивният retrieval индекс. По този начин грешката се запазва в продължение на много сесии и може да засегне дори стандартни въпроси.

Поради това ефективната защита започва дълго преди промпта. За всеки елемент от знания екипите трябва да могат да отговорят: Откъде произлиза, кой носи отговорност, коя версия е обработена, какви трансформации са извършени и чрез каква проверка е одобрен за търсене? Произходът на източника (source provenance) предоставя тази следа. Технически изолираната карантина може да предотврати незабавното извличане на непроверени промени. Целевите тестове за повторно индексиране след това проверяват дали изчистеното съдържание действително е заменило старите chunks.

Какво представлява отравянето на RAG данни – и какво не е

Класификацията на OWASP LLM04:2025 за Data and Model Poisoning описва манипулациите върху данни за предварително обучение, fine-tuning или embeddings като риск за интегритета. За уебсайт чатбот именно последният вариант е изключително осезаем: Даден документ се приема и се разделя на сегменти; тези chunks се вграждат (embedded) и се съхраняват като вектори в retrieval индекса. Ако този документ бъде умишлено или случайно изкривен, той може да се появи при подходящи въпроси като уж релевантна основа.

Рисковете трябва да се разграничават, макар че могат да се припокриват: Prompt Injection се опитва по време на изпълнение да вкара инструкции или данни така, че системата да промени предвиденото си поведение; индиректният Prompt Injection може при това да попадне в контекста и чрез извлечени документи. Тровенето на данни обаче променя по-дълготрайната база от знания или нейните производни. Правата за достъп също решават различен проблем: Те определят кой човек има право да вижда даден документ. Произходът и одобрението определят дали този документ трябва да влезе в индекса като надежден източник на знания. В една устойчива архитектура и трите риска се нуждаят от собствени контроли и съгласувани преходи.

Повърхността за атака обхваща цялата верига от данни

RAG индексът рядко възниква от една-единствена, ръчно проверена колекция. Уеб краулери четат страници, конектори синхронизират папки в облака, потребители качват файлове, а интерфейси импортират продуктови данни. Към това се добавят парсери, OCR, почистване на текста, chunking и обогатяване с метаданни. Всеки етап може да поеме грешно съдържание или да извади първоначално вярно твърдение от неговия контекст.

Типични причини са компрометирана система-източник, ново пренасочен огледален документ (mirror document), случайно публикувана чернова, грешно присвоен тенант или актуализация на парсера, която присвоява таблични стойности на грешните заглавия. Сравняването на криптографски hash на съдържанието с доверена референтна стойност може да открие отклонения; съвпадащият hash обаче не удостоверява нито истинността, нито актуалността или одобрението на съдържанието.

Произходът като проверим набор от данни

За всеки документ и всеки получен от него chunk трябва да съществува запис за произхода (provenance record). Практически полезни са най-малко: стабилен ID на източника, каноничен URL адрес за произход, отговорен собственик (owner), време на извличане, версия на документа, hash на съдържанието, статус на одобрение, клас на доверие, версия на парсера, версия на chunking, модел на embedding и поколение на индекса. При ръчно качване се добавят ролята на качващия човек и провереният лиценз. При синхронизирани системи е важно също през кой автентифициран конектор е пристигнал файлът.

Документът NIST AI 600-1 Generative AI Profile разглежда Content Provenance, проследимата документация, както и тестовете и оценките като важни градивни елементи за управление на риска при генеративен изкуствен интелект. Пренесено към RAG системи, това означава: Не само текущият индекс е от значение. Проследимата връзка между ревизията на източника, изпълнението на обработката и публикуваното поколение на индекса също е част от оперативната документация.

Карантината разделя приема от публикуването

Централен архитектурен елемент е последователното разделение: Новото или променено съдържание не става веднага достъпно за търсене. То попада първоначално в зона за прием. Там пайплайнът валидира произхода, типа на файла, размера, подписа или очаквания hash, разрешения тенант, пълнотата на метаданните и обема на промените. Едва след това текстът и chunks се генерират в непродуктивно поколение на индекса.

Правилата трябва да са базирани на риска. Промяна в автентифицирана, вътрешно управлявана страница с ЧЗВ може да бъде одобрена след автоматични тестове. Нов домейн, необичайно голяма текстова промяна, неизвестен собственик на файла или източник без отговорно лице обаче задействат карантина и човешка проверка. Ако липсва задължителна информация, важи принципът „fail closed“: Старото, потвърдено поколение остава активно; новото състояние не се публикува тихомълком.

Одобрението като неизменяемо поколение на индекса

След проверката продуктивният индекс не се преписва стъпка по стъпка. По-добре е да се създаде ново, версионирано поколение с манифест: очаквани документи, очаквани chunks, hashes на източниците, версии на трансформациите и времеви печати. Едва когато тестовете са успешни (зелени), даден алиас или конфигурация за рутиране се превключва атомарно към това поколение. Предишното поколение остава на разположение за връщане назад (rollback) за ограничен, дефиниран период от време.

Процедурата прилича на контролирана миграция. Нашата статия за смяна на RAG embedding модел показва защо паралелните поколения на индекса и сравнителните тестове са полезни и при технически промени. При съмнение за тровене се добавя и въпросът за сигурността: Коя ревизия на източника и кои получени chunks трябва да бъдат блокирани?

Фиктивен примерен сценарий: Грешен срок за връщане достига до поддръжката

Да предположим, че търговец управлява чатбот за въпроси относно продукти и услуги. Базата от знания синхронизира всяка нощ официалния център за помощ и няколко одобрени портала на производители. След промяна на линк обаче конекторът последва пренасочване към неодобрена огледална страница. Там в визуално правдоподобен PDF файл е посочен срок за връщане от 90 вместо 30 дни. Файлът се разделя на chunks; няколко раздела попадат в индекса с висока семантична приличност.

На следващата сутрин ботът обещава грешния срок при въпроси за връщане на стоки. Езиковият модел не е препрограмиран и потребителите не са въвели вредна инструкция. Извличането просто предоставя погрешна основа. Мониторингът подава сигнал за тревога, защото нов домейн се появява за първи път като източник на отговор, а тестът с Golden Set за срока за връщане се отклонява от очакваното доказателство.

Контролираната карантина и повторно пускане

1. Екипът спира само засегнатия източник на прием и замразява текущото поколение на индекса за допълнителни промени.
2. Заподозреният ID на документа, всички получени от него IDs на chunks и техните съвпадения в отговорите се записват в лога на инцидента.
3. Огледалният домейн се блокира, а неговите chunks се преместват в карантина. За въпроси относно срока за връщане ботът временно предоставя сигурно указание към човешка поддръжка или към потвърдената страница с правила.
4. Алиасът се връща към последното доказано чисто поколение на индекса. При това други незасегнати области от знания остават достъпни.
5. Конекторът се ограничава само до каноничния източник. След това пайплайнът изгражда ново поколение от потвърдения манифест.
6. Едва след тестовете за повторно индексиране и експертно одобрение това поколение преминава в продуктивна среда.

Това последователно действие ограничава щетите, без преждевременно да се изключва целият чатбот. Решаваща е връзката между данните за произхода и техните производни: Без съпоставяне на документа с неговите chunks би било непонятно кои вектори трябва да бъдат премахнати.

Тестовете за повторно индексиране трябва да показват повече от успешен пайплайн

Зеленият статус на задачата доказва само, че процесът е приключил технически. Той не доказва нито че старите chunks са изчезнали, нито че правилните източници печелят при реалистични въпроси. Затова устойчивият пакет от тестове проверява наличността, извличането (retrieval) и поведението на отговорите.

1. Проверка на манифеста и изтриванията

Сравнете новото поколение с одобрения манифест. Всяка очаквана версия на документа трябва да присъства; блокираните IDs на документи и chunks не трябва да се появяват. Особено важни са маркерите за изтриване („tombstones“) за премахнато или заменено съдържание. Простото добавяне на нови embeddings инак оставя старите, отровени съвпадения да продължат да съществуват в индекса.

2. Retrieval тестове с очаквани източници

За критични въпроси очакваният текст на отговора не е достатъчен. Дефинирайте допълнително разрешени и забранени IDs на източници, минимален брой съвпадения и условия за изключване. Срокът за връщане трябва например да произлиза от каноничната политика; поставеният под карантина огледален домейн не трябва да се появява нито в топ съвпаденията, нито в контекста на модела. Как се структурират такива тестови комплекти, е обяснено в статията за качество на отговорите с Golden Set и RAG тестове.

3. Негативни тестове и тестове за манипулация

В изолирана тестова среда екипите могат да подадат ясно маркиран, неодобрен тестов източник. Пайплайнът трябва да го задържи в карантина; търсенето, симулиращо продуктивната среда, не трябва да го извлича. Допълнително се тестват необичайни смени на домейни, липсващи собственици, екстремни разлики в съдържанието и противоречиви дати. Докладът NIST AI 100-2 за Adversarial Machine Learning класифицира Poisoning като категория атака в своята таксономия и подчертава, че противодействията и техните ограничения трябва да се разглеждат систематично.

4. Сравнение преди и след смяната

Задайте същите въпроси към последното чисто и към новото поколение. Сравнете източниците на съвпадения, подредбата, доказателствата в отговорите, процента липса на отговор (No-Answer-Rate) и експертната оценка. Малък canary дял може да предостави допълнителни продуктивни сигнали, стига потребителите да нямат достъп до непроверени източници. Продуктивната смяна се извършва едва след като са спазени установените граници за сигурност и качество.

Мониторинг: Ранно откриване на аномалии

Не следете само оценките на отговорите. Информативни са новите или редки домейни на източници, делът на непроверените източници в потока на прием, необичайните размери на документите, силните разлики в hashes или текста, множеството нови chunks от един собственик, промените в топ източниците в Golden Set и отговорите без потвърдено доказателство. Метриките трябва да препращат към IDs на произхода, а не към излишно съхранявани пълни потребителски въпроси.

Актуалността също остава от значение. Стара, отдавна заменена политика не е умишлено отровена, но може да има същия ефект. Статията за актуалност на бази от знания и Crawl QA допълва контролите за сигурност с честота на обновяване, отговорност и пътища за изтриване.

Чеклист за сигурен RAG прием

• Има ли всеки източник стабилен ID, каноничен произход, отговорно лице и клас на доверие?
• Записват ли се заедно hash, версия на документа, парсер, chunking и embedding модел?
• Остават ли новите или силно променените източници извън продуктивното търсене до извършване на проверка?
• Водят ли нови домейни, липсващи подписи или неправдоподобни промени в съдържанието до карантина?
• Публикуват ли се одобрените индекси като версионирани поколения с алиас за възможност за връщане назад?
• Премахва ли повторното индексиране доказуемо заменените chunks, вместо само да добавя нови данни?
• Проверява ли Golden Set както отговорите, така и очакваните и забранените източници?
• Съществува ли сигурен fallback за теми, чиито източници са блокирани по време на инцидент?
• Разделени ли са ясно ролите за прием, експертно одобрение, Incident Response и повторно публикуване?
• Документира ли се след всеки инцидент коя контрола се е провалила и кой регресионен тест е бил добавен?

Заключение

Отравянето на RAG данни не може да се отстрани с едно правило в промпта. Защитата произтича от проверима верига за доставка на знания: документиране на произхода, проверка на промените в карантина, версиониране на индексите, безопасно премахване на стари производни и тестване на retrieval с очаквани източници. Започнете с най-рисковите класове документи и малък Golden Set. Дори тази комбинация прави видимо кой източник носи даден отговор – и позволява целеви път за връщане назад, преди погрешното състояние на знанията да се превърне в трайно нормално състояние.

Източници

• OWASP GenAI Security Project: LLM04:2025 Data and Model Poisoning
• NIST AI 600-1: Artificial Intelligence Risk Management Framework – Generative Artificial Intelligence Profile
• NIST AI 100-2: Adversarial Machine Learning – Taxonomy and Terminology of Attacks and Mitigations