Hybrid Search a Reranking pre AI chatbotov: lepšie výsledky v RAG

Webové chatboty zriedkavo zlyhávajú na tom, že by báza znalostí neobsahovala vôbec žiadne informácie. Častejšie krok vyhľadávania (Retrieval) nenájde pasáž, ktorá sa hodí k otázke a konkrétnemu kontextu. Návštevníci používajú názvy produktov, chybové hlásenia a čísla artiklov, ale formulujú aj voľne: „Prečo chatbot zobrazuje nesprávny tarif?“ alebo „Môžem ešte zmeniť už odoslanú objednávku?“ Pre túto zmes nestačí samotné vyhľadávanie podľa kľúčových slov ani čisté vektorové vyhľadávanie ako paušálna odpoveď. Hybrid Search spája oba signály, aby RAG chatbot získal do kontextu odpovede spoľahlivejšie zdroje.

Vyhľadávanie podľa kľúčových slov a vektorové vyhľadávanie plnia rôzne úlohy

Vyhľadávanie podľa kľúčových slov je silné vtedy, keď sa slová musia vyskytovať presne. To platí pre čísla objednávok, označenia produktov, konkrétne chybové hlásenia, názvy zmlúv alebo verzie ako „2.4“. Dokáže zrozumiteľne ukázať, prečo dokument zodpovedá: hľadané slovo sa nachádza v názve, v nadpise alebo v pasáži. Jeho slabosť sa prejavuje pri bežnom jazyku, synonymách a neúplných formuláciách. Otázka návštevníka na „kópiu faktúry“ potom nemusí nutne nájsť stránku, ktorá hovorí len o „stiahnutí dokladu“.

Vektorové vyhľadávanie túto medzeru dopĺňa. Reprezentuje otázku a obsah ako sémantickú blízkosť, a preto dokáže nájsť podobné požiadavky, aj keď chýbajú rovnaké pojmy. To pomáha pri prirodzene formulovaných otázkach podpory, viacjazyčných variantoch a rôznych označeniach pre rovnaký proces. Sémantická blízkosť však sama o sebe nie je voľnou vstupenkou: pasáž môže byť téme podobná, ale týkať sa inej verzie produktu, iného trhu alebo expirovaného pravidla. Presne preto kontrola kontextu patrí do Retrieval pipeline a nie až do jazykového modelu.

Prečo je Hybrid Search zmysluplným východiskovým bodom

Microsoft popisuje Hybrid Search ako spoločný dopyt s celotextovou a vektorovou časťou. Oba dopyty prebiehajú paralelne a ich zoznamy výsledkov sa následne spojia. Pre firemné webstránky je to atraktívne, pretože presné pojmy zostávajú zachované a zároveň sa sprístupní príbuzný, dobre formulovaný obsah. Chatbot nemusí nechať návštevníkov vyberať medzi „technickým“ a „sémantickým“ vyhľadávaním. Výber vzniká na pozadí a môže sa skontrolovať pre všetky otázky rovnakým procesom kvality.

Hybrid Search zlepšuje množinu kandidátov; nevytvára však pravdu. Chatbot smie použiť iba obsah, ktorý je schválený pre konkrétnu situáciu. Verejné webstránky, interné koncepty a chránené údaje zákazníkov nepatria do spoločného nekontrolovaného kontextu. Rovnako dôležité je jasné správanie, ak nie je k dispozícii žiadny vhodný zdroj: doplňujúca otázka, odkaz na kontaktnú stránku alebo Human Handoff sú bezpečnejšie ako plynule formulovaný dohad.

Srozumiteľné RRF: spájanie rebríčkov

Skóre z celotextového a vektorového vyhľadávania majú rôzny význam a mierky. Ich priame sčítanie alebo vymýšľanie pevnej prahovej hodnoty často vedie k nestabilným výsledkom. Reciprocal Rank Fusion, skrátene RRF, preto pracuje s pozíciou dokumentu v každom rebríčku. Dokument, ktorý sa v oboch zoznamoch objavuje vysoko, získa silný kombinovaný signál. Dokument, ktorý je viditeľný len v jednom zozname, sa tiež môže vziať do úvahy, ale neistí automaticky vytlačiť všetko ostatné.

RRF nie je magická štandardná hodnota ani náhradný vzorec pre odborné testy. Koľko kandidátov z každého vyhľadávania sa dostane do fúzie, ktoré filtre zasiahnu vopred a kedy sa výsledok vôbec považuje za použiteľný, závisí od obsahu a rizika. Pre časté otázky o produktoch môže mať zmysel malé, fokusované okno. Pre komplexné návody alebo diagnostiku chýb je možno potrebných viac kandidátov. Rozhodujúce je porovnať zmenu s reálnymi otázkami voči testovacej sade, namiesto preberania univerzálneho parametra z príkladu.

Sémantický Reranking ako druhý, obmedzený stupeň

Po dobrom predvýbere môže Reranker ešte raz vyhodnotiť užšiu množinu kandidátov voči celej otázke. Microsoft zaraďuje sémantické rankovanie ako sekundárne rankovanie nad už predbežne zoradeným zoznamom výsledkov. Amazon Bedrock popisuje Reranking zodpovedajúco ako hodnotenie textových dokumentov z hľadiska ich relevancie k dopytu. Tento druhý stupeň sa hodí pre otázky s viacerými podmienkami: napríklad či je možná zmena tarifu po tom, čo už bola objednávka odoslaná a ide o určitý typ zmluvy.

Reranking by mal byť vedome obmedzený. Stojí dodatočnú latenciu a v závislosti od služby môže byť spoplatnený. Neodosielajte preto celú bázu znalostí Rerankeru, ale iba už vyfiltrovanú a spojenú top množinu. Definujte si časový rozpočet a fallback. Ak sa rozpočet prekročí, chatbot môže napríklad zobraziť najspoľahlivejší zoznam zdrojov, požiadať o spresnenie alebo odovzdať konverzáciu tímu podpory. Reranker neopraví zastarané, chýbajúce alebo neschválené obsahy.

Filtre metadát chránia kontext

Metadáta často rozhodujú o kvalite odpovede výraznejšie než ďalšia možnosť modelu. Spravujte pri každom zdroji minimálne jazyk, produkt alebo službu, verziu, trh, cieľovú skupinu a platnosť, pokiaľ sú tieto údaje relevantné pre použitie. Filter na správneho klienta alebo oblasť oprávnení musí zasiahnuť pred výstupom. Pri verejnej webstránke môže chatbot načítavať iba verejný obsah; pre prihlásenú zónu platia dodatočne overiteľné oprávnenia.

Aj čas je otázkou metadát. Cenníky, dodacie podmienky a návody by mali niesť jasný dátum aktualizácie alebo kontrolovaný stav platnosti. Ak zdroj už nie je dôveryhodný, patrí preč z indexu alebo do samostatného overovacieho procesu. Filtre musia zobrazovať požiadavky zrozumiteľné pre návštevníkov, nie tajne manipulovať poradie. Dokumentujte preto, ktoré filtre platia pre ktorú triedu otázok a ako tím overuje zmeny.

Konkrétna pipeline od query až po kontext

1. Normalizovať otázku: Rozpoznajte jazyk a zrejmý kontext bez zbytočného ukladania alebo meny osobných údajov.
2. Skontrolovať prístup a metadáta: Pred vyhľadávaním určite, ktoré zdroje sú povolené pre produkt, trh, rolu a časové obdobie platnosti.
3. Paralelne načítať: Vykonajte celotextové a vektorové vyhľadávanie voči rovnakej povolenej množine zdrojov.
4. Spojiť rebríčky: Skombinujte zoznamy pomocou RRF a uchovajte pre každého kandidáta signály pôvodu pre debugging.
5. Obmedzene rerankovať: Hodnotenie relevancie vykonajte len na malej top množine a merajte latenciu.
6. Zaistiť kontext: Skontrolujte duplicitu, stav zdrojov a primeranú dĺžku predtým, než pasáže prejdú do modelu odpovede.
7. Odpoveď s hranicami: Doložte zdroje, označte neistotu a v prípade potreby použite bezpečné odovzdanie.

Praktický príklad: stav zásielky a zmena tarifu

Predpokladajme, že sa návštevník pýta: „Môžem ešte zmeniť svoj tarif, aj keď je balík už na ceste?“ Vyhľadávanie podľa kľúčových slov môže nájsť stránku o „zmene tarifu“ a článok podpory s „balík na ceste“. Vektorové vyhľadávanie nájde návod, ktorý opisuje proces ako zmenu po odoslaní. RRF posunie hore dokumenty, ktoré spájajú oba aspekty. Reranker potom môže skontrolovať, či relevantná pasáž skutočne obsahuje kombináciu tarifu a dopravy.

Pred odpoveďou vyfiltrujete dotknutý trh, produktovú líniu a aktuálny stav platnosti. Ak sú zdroje rozporuplné alebo chýbajú potrebné detaily, chatbot by nemal usudzovať z podobných prípadov. Môže transparentne povedať, ktorá podmienka je otvorená, a nasmerovať návštevníka na vhodnú, overenú možnosť kontaktu. Tak zostane konverzácia užitočná bez toho, aby si vymyslela nekrytý prísľub.

No-result prípady a debugging skóre

No-result je často signálom medzery v znalostiach, nie nefunkčného vyhľadávania. Rozlišujte preto minimálne štyri prípady: neexistuje žiadny povolený zdroj, existujú zdroje, ale žiadny dostatočne vhodný výsledok, otázka je mnohoznačná alebo technická chyba bráni vyhľadávaniu. Každý prípad potrebuje vlastnú, zrozumiteľnú reakciu. „K tomu v schválených informáciách nenachádzam žiadnu spoľahlivú odpoveď“ je čestnejšie ako generická veta bez ďalšieho kroku.

Pre debugging samotné konečné skóre nestačia. Pri každej testovacej otázke by tímy mali vidieť, ktoré filtre zasiahli, ktoré dokumenty prišli z kľúčových slov a vektorového vyhľadávania, ako boli spojené a či Reranking zmenil poradie. Ukladajte pritom iba dáta potrebné pre kvalitu, spracované s ohľadom na dátovú úspornosť. Hľadajte vzorce: chýbajú určité synonymá? Prekrýva starý zdroj nový obsah? Vybočuje nejaká lokalizácia z logiky metadát? Až konkrétna príčina rozhodne, či sa musí zmeniť Chunking, metadáta, údržba zdrojov alebo rankovanie.

Testovacia sada, metriky a rozpočet nákladov

Malá Golden Set s 30 až 50 realistickými otázkami je dobrým začiatkom. Pri každej otázke uveďte očakávané zdroje, nepovolené zdroje a požadovanú reakciu pri chýbajúcich znalostiach. Merajte oddelene, či sa správny zdroj nachádza medzi kandidátmi, či je dostatočne vysoko a či finálna odpoveď používa iba doložené informácie. Zámerne doplňte preklepy, presné pojmy, prirodzené formulácie, viacjazyčnosť a kritické negatívne prípady.

Pri každom testovacom behu zmeňte iba jednu premennú: filter, počet kandidátov, hĺbku Rerankingu alebo štruktúru chunkov. Poznamenajte si tiež čas odpovede a počet externých volaní modelu. Vyššia hodnota relevancie môže byť nepoužiteľná, ak odpoveď príde príliš neskoro alebo náklady na časté štandardné otázky vzrastú. Definujte si preto rozpočet latencie a nákladov pre každú triedu otázok. Rýchle, dobre doložené štandardné odpovede a konzervatívne odovzdania sú pre mnohé webstránky hodnotnejšie ako maximálne komplexné rankovanie.

Typické chyby pri zavádzaní

• Priame porovnávanie surových skóre z kľúčových slov a vektorov, hoci ich mierky nie sú rovnaké.
• Indexovanie konceptov, starých cenníkov alebo chránených obsahov bez filtrov stavu a oprávnení.
• Aplikovanie Rerankingu na príliš veľa kandidátov, čím sa nekontroluje latencia a náklady.
• Považovanie dema s niekoľkými dobrými otázkami za dostatočný dôkaz kvality.
• Generovanie plynulej odpovede pri chýbajúcom zdroji namiesto neistoty, doplňujúcej otázky alebo Handoffu.
• Neverziovanie zmien na zdrojoch, chunkingu a rankovaní a neschopnosť ich neskôr vysvetliť.

Kontrolný zoznam pre zavedenie

• Stanoviť povolené zdroje a hranice oprávnení pred indexovaním.
• Spravovať metadáta pre jazyk, produkt, verziu, trh a platnosť.
• Celotextové a vektorové vyhľadávanie načítavať paralelne, následne spojiť pomocou RRF.
• Reranking používať iba pre malú, povolenú množinu kandidátov.
• Hodnotiť odkazy na zdroje, no-result odpovede a Human Handoff v testovacej sade.
• Merať latenciu, náklady a kritické chybné odpovede pri každej zmene.

Záver

Hybrid Search je robustný východiskový bod pre webových chatbotov s rôznymi formami otázok. Vyhľadávanie podľa kľúčových slov zachováva presné signály, vektorové vyhľadávanie sprístupňuje podobné požiadavky, RRF spája ich rebríčky a obmedzený Reranker môže zlepšiť užší výber. Trvalo udržateľný nárast kvality však vzniká vďaka udržiavaným zdrojom, vhodným metadátam, zrozumiteľným testom a logike odpovedí, ktorá otvorene priznáva svoje hranice. Tak sa Retrieval stáva overiteľným namiesto toho, aby bol len technicky pôsobivý.

Zdroje a ďalšie odkazy

• Microsoft Learn: Hybrid Search
• Microsoft Learn: Relevancia a RRF pri Hybrid Search
• Microsoft Learn: Semantic Ranking
• Amazon Bedrock: Reranking
• ChatReact: RAG-Chunking pre AI chatbotov
• ChatReact: Testovanie kvality odpovedí pomocou Golden Set
• ChatReact: Udržiavanie aktuálnej bázy znalostí