RAG филтри за метаданни за ИИ чатботове: Разделяне на език, версия и достъп

Един ИИ чатбот може да открие семантично много близки фрагменти от текст и въпреки това да подготви грешен отговор: английското ръководство вместо българското, документацията на предишната версия вместо настоящата или вътрешни указания за гост без съответните права. В такъв случай класирането (ranking) не е задължително лошо. Пространството за търсене е било погрешно.

RAG филтрите за метаданни решават точно този проблем. Те ограничават преди или по време на търсенето кои документи и чанкове (chunks) въобще са допустими като контекст. След това релевантността отговаря на въпроса „Кое съвпада най-добре по съдържание?“. Филтърът обаче първо отговаря на: „Какво е позволено и трябва да се вземе предвид в тази ситуация?“.

Защо сходството само по себе си не е надежден обхват

Векторното и хибридното търсене подреждат съдържанието по езикова или семантична близост. Наръчник за версия 4 на даден продукт може да бъде изключително близък до въпрос за версия 5. Ценова листа за друг пазар може да съдържа същите имена на продукти. А вътрешен документ за поддръжка може да предостави по-прецизен отговор от обществено достъпния раздел с ЧЗВ (FAQ), въпреки че никога не би трябвало да се появява в публичен чат.

Затова Retriever трябва да прави разлика между два вида условия:

• Твърди ограничения като клиент (tenant), роля, статус на публикуване или позволен обхват от данни. При неизвестна стойност търсенето трябва да остане затворено.
• Специализирани критерии за подбор като език, продуктова фамилия, версия, регион или период на валидност. Те увеличават прецизността и предотвратяват противоречив контекст.

Текущият преглед на OWASP за LLM приложения изрично причислява рисковете при векторите и ембедингите към границата на доверие на едно ИИ приложение. Това е важна гледна точка: Проверката за автентификация преди чата не е достатъчна, ако последващото търсене по сходство все пак работи върху твърде широк индекс.

Схема за метаданни, която издържа в ежедневната практика

Добрите филтри не започват с дълга заявка, а с няколко канонични полета. За много уебсайт чатботове са достатъчни шест групи:

• Език и пазар: например locale и market, със строго дефинирани стойности вместо свободен текст.
• Продукт и версия: стабилен ID на продукта, диапазон от версии и по избор платформа или тарифен план.
• Валидност: статус на одобрение, валиден от, валиден до и уникална версия на източника.
• Целева група: публична, клиент, партньор или вътрешен екип – отделно от същинската проверка на ролите.
• Обхват на достъп: клиент (tenant), група или Principal, единствено от верифициран сървърен контекст.
• Произход: ID на източника, URL, тип документ и отговорно направление за съдържание с цел проследимост.

Метаданните принадлежат на нивото, на което се извършва търсенето. Ако даден документ се разделя на чанкове (chunks), решаващите scope-полета трябва надеждно да присъстват във всеки чанк. В противен случай документът може да е класифициран правилно, докато отделни резултати от търсенето да загубят тази класификация. Документацията на OpenAI относно File Search показва например как файловите атрибути се използват за филтриране по метаданни. Справката за Amazon Bedrock документира оператори за сравнение, списъци и диапазони за същата основна идея.

Никога не оставяйте езиковия модел да оторизира филтрите

Моделът може да извлече указания от въпроса, като например език или връзка с продукт. Той обаче не трябва да решава към кой клиент (tenant) принадлежи дадено лице или каква роля има то. Тези стойности трябва да идват от сесията, системата за идентичност и сървърните бизнес правила. Нито един филтриращ низ, генериран от модела, не трябва да се предава непроверен към услугата за търсене.

Надеждният процес изглежда така:

1. Сървърът автентифицира заявката и определя разрешения обхват от данни.
2. Детерминистични правила задават твърди полета като клиент (tenant), роля и статус на публикуване.
3. Разпознатите характеристики като език или продукт се валидират спрямо позволените стойности.
4. Retriever изпълнява само типизирана, параметризирана филтрираща структура.
5. Приложението проверява върнатите източници още веднъж за очаквания обхват.
6. При липсващ или противоречив контекст чатботът задава уточняващ въпрос или извежда безопасен fallback.

Документацията на Microsoft за Security Filters прави полезно разграничение: Principal във филтъра първоначално е просто стойност. Автентификацията и оторизацията трябва да се извършват надеждно извън израза за търсене. За клиентски портали нашата статия за разделителната линия между публичен и автентифициран ИИ чатбот разглежда подробно тази граница.

Pre-Filter или Post-Filter?

Позицията на филтъра влияе върху качеството и времето за изпълнение. Pre-Filter ограничава кандидатите още по време на векторното търсене. Post-Filter първо търси по-широко и след това премахва недопустимите резултати. Според документацията на Azure за векторни филтри, Post-Filtering може да пропусне подходящи резултати при селективни филтри и малко k; Pre-Filtering дава предимство на пълнотата (recall) в позволения поднабор, но при много тесни филтри може да изисква повече изчислителни ресурси.

За твърди ограничения на достъпа подходът „първо търси широко, после скривай“ не е подходящ основен модел. Оторизираният обхват трябва да бъде наложен вътре в заявката за търсене. За чисто функционални филтри екипът може да измери Pre- и Post-вариантите. При това значение има не само средното време за отговор, но и колко често даден съществуващ, позволен резултат липсва заради избраната последователност.

Филтрите не заместват класирането (ranking). Вътре в разрешения корпус Hybrid Search и Reranking продължават да приоритезират най-добрите източници. Следователно последователността е: дефиниране на обхват, извличане на кандидати, оценка на релевантността, проверка на източниците, генериране на отговор.

Четири типични случая на филтриране

Език с умишлен fallback

За въпрос на български език първото извличане трябва да избере български, одобрени съдържания. Ако няма съвпадение, приложението не трябва мълчаливо да смесва няколко езика. Явен втори път може да се върне към одобрен основен език и да отбележи това обстоятелство в отговора. Тест от типа Locale-QA за езикови бази от знания допълнително проверява дали езиковите варианти са наистина равностойни по съдържание.

Продуктова версия и времева валидност

Даден източник не трябва да изглежда актуален само защото е бил обходен (crawled) наскоро. Решаващи са продуктовата версия и одобрението. Маркирайте съдържанията със стабилен ID на продукта, диапазон от версии, valid_from, valid_until и статус. При припокриващи се одобрения пайплайнът трябва да съобщи за конфликт, вместо да поставя и двата текста в един и същ промпт. Как си взаимодействат честотата на обходените данни и поддръжката на източниците е описано в ръководството за актуалност на базата от знания на ИИ чатбот.

Клиент (Tenant) и роля

При споделен индекс всяко извличане трябва да съдържа клиента и валидните Principals, определени от сървъра. Липсващи ACL метаданни означават „недостъпен“, а не „публичен“. След промяна на роля или отнемане на право за достъп тестът трябва да покаже, че старите сесии вече не получават чанкове, които преди са били позволени.

Публична поддръжка и вътрешна работна инструкция

Вътрешна инструкция за ескалация може да съвпада перфектно по съдържание с клиентски въпрос. Това обаче не я прави позволен източник. Разделяйте обхвата на публикуване от типа документ; маркирайте неодобрените съдържания по подразбиране като изключени. Публичният бот при съмнение трябва да прехвърли към контакт или пренасочване към оператор (handoff), вместо да гадае вътрешни детайли.

Най-честите грешки при внедряването

• Таксономия със свободен текст: Стойности като de, DE и de-DE непреднамерено образуват три различни групи.
• Default-open: Чанкове без роля, статус или клиент (tenant) попадат във всяко пространство за търсене.
• Грешна булева логика: Оператор OR между клиент и език на практика премахва твърдата граница.
• Дрифт между документ и чанк: При повторно индексиране новите метаданни не се прехвърлят към всички чанкове.
• Само позитивни тестове: Екипът проверява дали се появява позволен документ, но не и дали подобен на него, но забранен документ сигурно липсва.
• Празни резултати като проблем на модела: Тесен филтър не връща нищо и приложението оставя модела да продължи да отговаря без източници.

Filter-QA: Тествайте не само съвпаденията, а и границите

Практичният набор от тестове съдържа за всеки очакван отговор поне един близък противоположен кандидат: грешен език, стара версия, изтекъл срок на валидност, друг клиент (tenant) или вътрешна целева група. Така тестът показва дали филтърът наистина разделя, а не просто случайно поставя правилния резултат най-отгоре.

Важни показатели са процентът на нарушения на обхвата (Scope Violation Rate), пълнотата (recall) в разрешения поднабор, делът на празните извличания, броят на неизвестните стойности на метаданните, латентността на филтъра на 95-ия перцентил, както и делът на случаите с fallback и уточняващи въпроси. За ограничено съдържание допустимият процент на нарушения трябва да бъде нула. Рамката NIST AI RMF Core препоръчва ИИ системите да се тестват преди внедряване и редовно в процес на работа, както и да се документират границите на сигурност, надеждност и контекст.

За тази цел не логвайте излишно съдържание или пълни потребителски въпроси. В повечето случаи са достатъчни версията на филтъра, абстрактният обхват, броят на кандидатите, избраните ID на източниците, причината за отхвърляне и резултатът от последващата проверка (post-check). Така откриването на грешки остава възможно, без да се създава ново изтичане на данни в системата за наблюдение (observability).

Практически чеклист преди внедряване

1. Документирайте каноничните полета за метаданни, типовете данни, позволените стойности и отговорниците.
2. Разделете твърдите ограничения за достъп от функционалните полета за подбор.
3. Третирайте липсващите критични за сигурността стойности последователно като недопустими.
4. Изграждайте филтрите от верифициран сървърен контекст и параметризирайте входните данни.
5. Проверявайте с извадки метаданните след зареждане (ingestion) и разделяне на чанкове (chunking).
6. Тествайте положителни, отрицателни, гранични и отменени случаи спрямо реалния индекс.
7. Измерете поведението на Pre-/Post-филтрите с реалистично k и селективни обхвати.
8. Пренасочвайте празните резултати към уточняващ въпрос, безопасен fallback или оператор (Human Handoff).
9. Версионирайте промените във филтрите и ги внедрявайте заедно с регресионни тестове за извличане.

По този начин RAG филтрите за метаданни са нещо повече от функция за удобство при търсенето. Те са връзката между модела на съдържанието, идентичността, актуалността и качеството на извличане. Всеки, който първо детерминистично дефинира обхвата, дава на класирането и на езиковия модел по-малка, по-чиста и проверима работна основа.

Следваща стъпка: Изберете реален въпрос за поддръжка и създайте към него пет почти съвпадащи противоположни източника от грешен език, версия и права за достъп. Едва когато нито един от тях не надхвърли разрешения обхват за извличане, филтърът трябва да премине към реалния чат поток.

Източници

• OpenAI: File Search и Филтриране на метаданни
• Microsoft: Филтри във векторни заявки
• Microsoft: Модел за сигурност с филтри (Security Filter Pattern)
• Amazon Bedrock: RetrievalFilter API
• NIST: AI Risk Management Framework Core
• OWASP: GenAI LLM Top 10 2026