RAG Query Rewriting: Правилно разрешаване на последващи въпроси при ИИ чатботове

Един изолиран въпрос като „А колко време важи това?“ често е напълно ясен за хората. Те си спомнят предварително обсъдения продукт, местоположението и съответния срок. Търсачката в базата от знания обаче първоначално вижда само няколко думи. Без подходящ контекст от разговора тя може да не открие нищо или да търси по грешна тема. RAG Query Rewriting решава този проблем, като трансформира контекстно зависимия последващ въпрос в самостоятелна заявка за търсене, преди да стартира самият процес.

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

Защо последващите въпроси затрудняват търсенето в базата от знания

Първият въпрос на потребителя обикновено е конкретен: „Каква е гаранцията за Модел А?“. Следват кратки фрази като „А за по-големия вариант?“, „Това важи ли и за България?“ или „Какво ми е нужно за това?“. Местоименията, пропуснатите подлози и препратките към предишни отговори са естествени в разговора. Като изолирана заявка за търсене обаче те са изключително слаби.

Класическият пайплайн за Keyword, Vector или Hybrid Search може да оцени само това, което получава като вход. Ранжирането (Reranking) подобрява подредбата на намерените резултати, но не замества липсващото значение на „това“ или „за това“. Затова Query Rewriting стои пред него: то оформя търсима, самостоятелна заявка от текущия въпрос и съответния диалогов контекст.

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

Успешно преформулираната заявка е достатъчно пълна за извличането на информация (Retrieval), но остава плътно до намерението на потребителя. Изразът „А за България?“ може например да стане „Какви са гаранционните условия за Модел А в България?“, ако Модел А и гаранцията са били ясно установени в непосредствено предходния диалог. Преформулирането все още не отговаря на въпроса. То служи единствено за откриване на подходящи източници.

Текущите указания за архитектура на Azure относно Conversational RAG препоръчват включване на съответната история на разговора и формулиране на текущия въпрос преди извличането като самостоятелна заявка с изяснени препратки. Важно тук е и ясно изразеното разделение: за последващия отговор се запазва оригиналният въпрос на потребителя. Така системата може да провери дали намерените доказателства наистина съответстват на поставения въпрос.

Допълване, но без измисляне

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

Правата за достъп остават извън текстовия модел

Организацията (Tenant), влезлият в системата потребител, разрешените секции с документи и роли се определят от страната на сървъра. Те не трябва да присъстват като свободно формулирано твърдение в преформулираната заявка. Бeкендът задава съответните метафилтри отделно и непроменяемо. Нито предишна реплика в чата, нито моделно преформулиране не бива да отключват по-голямо пространство за търсене.

Контекстът се нуждае от внимателно планиран бюджет

Изпращането на цялата история на чата без филтриране към модула за преформулиране рядко е добро решение. Стари теми могат да закрият текущия въпрос, лични данни могат да се предават ненужно, а дългите истории увеличават латентността и разходите. Като практическа насока указанията на Microsoft споменават от две до пет скорошни реплики от разговора и резюме на по-старото съдържание. Това не е универсален лимит, а начална точка за собствени тестове.

Един компактен контекстен пакет може да се състои от следните елементи:

• непроменения текущ въпрос на потребителя,
• няколко непосредствено съответстващи съобщения от потребителя и асистента,
• вече потвърдени обекти (Entities) като продукт, процес или събитие,
• Locale и часова зона като технически полета,
• краткотрайно, проверено резюме на по-стари части от диалога и
• версията на правилата за преформулиране, индекса на знания и конфигурацията на извличане (Retrieval).

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

Надежден процес в шест стъпки

1. Проверка за самостоятелност: Ясен нов въпрос като „Как да променя паролата си?“ може да отиде директно към търсенето. Не всяко съобщение изисква моделно преформулиране.
2. Разпознаване на препратки: Система маркира местоимения, елипси, думи за сравнение и препратки като „там“, „и двете“ или „втората опция“.
3. Избор на съответен контекст: Вземат се само тези съобщения, които логично разрешават тези препратки. Осъзнатата промяна на темата прекратява стария контекст.
4. Решение за преформулиране или уточняващ въпрос: Ако има точно едно надеждно значение, се създава самостоятелна заявка за търсене. При наличие на няколко възможни значения чатботът задава кратък уточняващ въпрос.
5. Търсене и евентуално декомпозиране: Заявката минава през Keyword, Vector или Hybrid Search. Въпросите от няколко части могат да бъдат разделени на ясно наименувани подвъпроси.
6. Отговор спрямо оригиналния въпрос: Отговорът се генерира от намерените източници, реферира към първоначалната формулировка и открито посочва несигурност или липса на доказателства.

Прегледът на Microsoft за Agentic Retrieval описва подобен процес: заявката и историята на разговора се включват в планирането, фокусирани подзаявки се изпълняват паралелно, а намерените резултати след това се обединяват. Документацията на Amazon Bedrock също описва планиране, итеративни подзаявки и проверка дали намереното съдържание е достатъчно за отговор. Такива продуктови функции могат да поемат части от пайплайна, но механизмите за качество и сигурност на вашето собствено приложение остават задължителни.

Preformulirane, уточняващ въпрос или Query Decomposition?

n

Входни данни	Подходяща реакция	Обосновка
„А това важи ли за България?“ след недвусмислен въпрос за гаранция	Формулиране на самостоятелна заявка	Предметът и референцията са напълно ясни.
„Ами с другия какво става?“ след три споменати варианта	Задаване на кратък уточняващ въпрос	Възможни са няколко тълкувания.
„Сравни цената, срока за доставка и връщането за двата модела“	Разделяне на фокусирани подзаявки	Няколко независими аспекта изискват надеждни резултати.
„Нова тема: Как да се свържа с поддръжката?“	Търсене без стария контекст за продукта	Потребителят сигнализира смяна на темата.

Query Decomposition не е същото като Query Rewriting. Rewriting прави зависимия въпрос самостоятелен; Decomposition разделя сложния въпрос на няколко задачи за търсене. Документацията на Bedrock за Query Decomposition показва, че множество подзаявки могат да подобрят покритието. Всяка допълнителна заявка обаче се нуждае от лимит, общ модел на права за достъп и прозрачно обединяване на резултатите.

Третирайте изходните данни от Rewriter-а като код

Дори и резултатът да е само текст, той трябва да има строг формат. Подходящ е структуриран обект с полета като standaloneQuery, decision, resolvedReferences и reason. Допустимите решения могат да бъдат например SEARCH_AS_IS, REWRITE, CLARIFY и DECOMPOSE. Бекендът валидира дължината, езика и позволените полета, преди да стартира търсенето.

Модулът за преформулиране не получава инструменти и не отговаря директно на потребителя. Системните инструкции от историята на чата, поставените текстове от документи или подкани като „Игнорирай правилата“ остават само данни, а не управляващи команди. За високорискови пространства за търсене детерминирано правило може допълнително да гарантира, че филтрите за продукт, Locale или Tenant никога не се определят от свободен текст.

Тестване със собствен набор от последващи въпроси

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

• Местоимения и пропуснати подлози в кратки последващи въпроси
• Корекции като „Не, имах предвид Модел B“
• Смяна на темата и връщане към предишна тема
• Многозначни варианти, които задължително изискват уточняващ въпрос
• Промяна на Locale, датата и часовата зона
• Недопустими опити за промяна на пространството за търсене или организацията (Tenant)
• Дълги разговори с ирелевантни по-стари детайли
• Въпроси от няколко части, които се разделят и след това обединяват отново

Измервайте отделно: Съответства ли преформулирането на намерението на потребителя? Намира ли Retrieval очакваните източници? Попитано ли е при реална двусмисленост? Останаха ли непроменени филтрите за права? Колко допълнителна латентност води тази стъпка? Стандартът NIST AI RMF Core поставя повторното тестване, измерване и документиране в целия жизнен цикъл на ИИ. За екипите, поддържащи уебсайтове, това означава: променяйте правилата за преформулиране, модела или избора на контекст само с регресионни тестове и наблюдавано внедряване.

Кратък контролен списък за екипи

• Остава ли първоначалният въпрос на потребителя непроменен до генерирането на отговора?
• Включват ли се само съответстващи и сведени до минимум части от историята?
• Може ли Rewriter-ът ясно да избира между преформулиране, уточняващ въпрос и декомпозиране?
• Добавя ли той единствено потвърдени обекти и никакви предположения?
• Задава ли бекендът Locale, Tenant и правата за достъп независимо от преформулирането?
• Има ли всяка подзаявка фиксирани лимити за брой, време и разходи?
• Оценяват ли се намерените резултати спрямо първоначалния въпрос?
• Покрива ли тестът за многостепенен диалог референции, корекции и смени на темата?

Заключение: Първо изяснете заявката за търсене, след това отговаряйте

RAG Query Rewriting превръща естествената кратка реч в стабилна заявка за търсене. Най-голямата полза не идва от максимално креативни формулировки, а от ясни граници: поемане на потвърден контекст, разрешаване на несигурността с уточняващ въпрос, запазване на правата за достъп от страната на сървъра и продължаваща проверка на отговора спрямо оригиналния въпрос. Започнете с двадесет типични последващи въпроса от вашата поддръжка, маркирайте очакваното решение и тествайте всяка промяна спрямо тези случаи. Така многостепенният чат става по-разбираем, без търсенето мълчаливо да отговаря на съвсем друг въпрос.

Източници

• Microsoft Azure Architecture Center: Prompt Engineering за RAG
• Microsoft Learn: Agentic Retrieval в Azure AI Search
• Amazon Bedrock: Конфигуриране на заявки и генериране на отговори
• Amazon Bedrock: Agentic Retrieval за бази от знания
• NIST AI Risk Management Framework Core