Lekérdezés-újraírás beszélgetésalapú kereséshez: kontextus, HyDE és szűrők

A keresőmező egy lekérdezést kap. A chat beszélgetést kap. A harmadik körben a vevő azt írja, hogy „és ugyanaz 5 literben", a kereső pedig egy mondatot kap termék, anyag és mértékegység nélkül. Nagyobb kontextusablak ezt nem oldja meg. Egy újraíró lépés igen.

Ez a cikk erről a lépésről szól egy B2B webshop-asszisztensben: korreferencia és ellipszis, HyDE, több lekérdezéses kiterjesztés, szűrőkinyerés, a cikkszám kivétele, a plusz hívás latenciája, és hogyan értékeljük az eredményt munkameneteken, nem az átírt szövegen.

Miért nehezebb a második kérdés, mint az első

Az egylépéses lekérdezésértés parszolás. A többkörös keresés erre még referenciamegoldást rak. A „4711-32" minden keresőnek egyszerű. Az „van ez 5 literben?" egy embernek egyszerű, egy indexnek lehetetlen, mert hiányzik a főnév.

Két út zárja be a rést. A beszélgetésalapú dense retrieval a előzményt és a lekérdezést egy vektorba kódolja, de munkamenet–passzus tanítóadat kell hozzá. A beszélgetésalapú lekérdezés-átírás megtartja a keresőt, és a követő kérdést önálló lekérdezéssé írja át; a ConvSearch-R1 ezt a kettősséget írja le, és amellett érvel, hogy az átírással kész kereső használható. Web shopokban én az átírásra szavazok: a kereső és a szinonimák már megvannak, és az újraírás kisebb változás, mint egy új retrieval stack.

Négy dolog, amit egy beszélgetés a lekérdezéssel tesz

• Korreferencia. Az „az", „az a kettő", „a második" arra a termékre mutat, amit az asszisztens mutatott.
• Ellipszis. Az „és 5 literben?" kihagyja a terméket és a tulajdonságot.
• Megváltozó feltétel. Az „olcsóbb" vagy a „nem a horganyzott" hozzáad vagy elvesz egy feltételt.
• Témaváltás. A „mikor szállítják?" nem örökölheti a termékszűrőt.

Mindegyik másképp hibázik: az elmaradt korreferencia a kategória véletlenszerű termékét hozza, az elmaradt feltétel a jó termékcsaládot rossz specifikációval, az elmaradt témaváltás terméket ad, pedig logisztikáról volt szó. A túlbuzgó átírás is hibázik: feltételeket talál ki, vagy elveszíti a cikkszámot. A cél a legkisebb lekérdezés, amely a jó jelölteket hozza, és megtartja a ténylegesen kimondott feltételeket.

Korreferencia, ellipszis és az önálló lekérdezés

A jó átírás hordozza a termékazonosítót, a szóban forgó tulajdonságot, az örökölt szűrőket és az új feltételt. A táblázat azokat a mintákat mutatja, amelyeket először tesztelek.

A sorszámos eset marad ki gyakran: a „második" feloldásához kell az asszisztens előző válasza, a megjelenített termékek sorrendjével. A Flippi, egy 2025-ös e-kereskedelmi asszisztens, a „second product" kifejezést a legutóbbi botválasz terméknevére képezi le a keresés előtt. Az átíró, amely csak felhasználói üzeneteket lát, ezt nem tudja.

A bemenet tehát nem az átirat, hanem tömör állapot: az utolsó körök, a megjelenített azonosítók és nevek, az aktív szűrők és a fiókkontextus (pénznem, árlista, szállítási ország). A strukturált állapot olcsóbb húsz üzenetnél, és tesztelhetővé teszi az átírást.

HyDE: hasznos, de nem tudja kitalálni a katalógust

A HyDE a Gao és szerzőtársai 2023-as ACL-cikkéből származik: a modell hipotetikus választ ír, ezt ágyazza be a lekérdezés helyett, és a vektorral keres. Az encoder kiszűri a kitalált részleteket; megmarad egy releváns dokumentum alakja. Egy webshopban ez az alak számít: a vevői kérdések rövidek, a katalógusszövegek hosszúak és strukturáltak.

A bizonyíték tanulságosan vegyes. A TREC 2025 RAG tracken a UTokyo–Hitotsubashi csapat körülbelül 150 szavas hipotetikus válaszokat írt GPT-4.1-gyel, és 0,7-es súllyal keverte a lekérdezés vektorát a hipotetikushoz. Az egyik embedding-modellnél az nDCG@10 0,493-ról 0,564-re nőtt, 14,4%-os relatív javulás; a HyDE önmagában 0,444-ről 0,401-re csökkentette a precision@100-at. A felhasználó szavai maradjanak a vektorban.

A nagyobb fenntartás egy 2025-ös ACL findings cikk a knowledge leakage-ről: három tényellenőrző benchmarkon és hét modellen átlagosan csak akkor segített a kiterjesztés, ha a generált dokumentumok a gold evidenciából következő mondatokat tartalmaztak. A HyDE akkor működik, ha a modell már ismeri a választ. Egy rétegkatalógus pont az az eset, amikor nem: magabiztos leírást ír hihető anyaggal és rossz menetmérettel, és olyan termékeket hoz, amelyek jónak látszanak, de nem azok. A szabályom: nincs HyDE azonosítós lekérdezéseknél, nincs ott, ahol egy rossz tulajdonság biztonsági kérdés, és csak homályos használati eseteknél.

Több lekérdezéses kiterjesztés: több recall, több drift

A következő kar több lekérdezés egy helyett. Az Azure AI Search akár tíz változatot generál, és együtt küldi őket az első keresési szakaszba; a Microsoft négy pont nDCG@3 javulást jelentett kifejezésalapú indexeken, és akár 22 pontot az újabb szemantikus rankerrel. A TREC iKAT 2025 a Best-of-N átírást plusz reciprocal rank fusiont találta a legerősebb konfigurációnak, rerankeléssel a tetején.

A több nem automatikusan jobb. Ugyanaz a TREC RAG 2025 rendszer, amely a HyDE-től nyert, azt találta, hogy a parafrazálás következetesen rontotta a pontosságot; a szerzők ezt szemantikus driftnek tulajdonítják. A parafrázis elvisz attól, amit a vevő értett, a szinonima vagy attribútum oldalra mozdít. Tehát más tengelyek mentén bővítsünk. Az alapom három lekérdezés: önálló, azonosítós, egy attribútumos változat. RRF-fel fúzionálok, cikkszám szerint deduplikálok, a jelöltlistát a rerankelés előtt korlátozom.

Szűrőkinyerés: előbb a séma, aztán a modell

A szűrők azok, ahol az asszisztens értéket ad, és ahol a legtöbb kárt okozza. Az „500 alatt" árszűrő, a „raktáron" elérhetőségi szűrő, a „múltkoriak" keresés a rendelési előzményekben. Az Amazon Bedrock Knowledge Bases kínálja a mintát: metaadat-attribútumokat (kulcs, típus, leírás) és egy modellt írunk le, a szolgáltatás pedig a keresés előtt szűrőt generál, string, number, boolean és string list típusokkal.

A döntő a preferenciaszűrők (a felhasználó szavai: anyag, méret, márka, árplafon) és a jogosultsági szűrők (a fiók: kínálat, árlista, raktár, látható termékek) szétválasztása. Az első osztályt javasolhatja a modell, a másodikat soha nem hozhatja létre. Ha az átírás beállíthatja az árlistát, egy értékelésbe ágyazott prompt injection kedvezménnyé válik. A preferenciaosztályon belül: mezők engedélyezése, típusellenőrzés, tartományok korlátozása, ismeretlen mezők elutasítása. A csendben eltűnő szűrő rosszabb a nulla találatos oldalnál, mert a vevő azt hiszi, érvényesült.

Cikkszámok és mértékegységek: az átírás ne nyúljon hozzájuk

Az Azure query rewriting dokumentációjában van a legfontosabb figyelmeztetés: az átírt lekérdezés nem feltétlenül tartalmazza az eredeti összes pontos kifejezését, ami rontja az egyedi azonosítókat és termékkódokat. Egy embeddingnek a 4711-32 és a 4711-33 szomszédok; egy vevőnek két különböző alkatrész.

A megoldás eljárási. Az azonosítójelölteket a modell elé kell kiemelni (elválasztós számok, beszállítói előtagok, EAN-ok, rajzszámok), helyőrzőkre cserélni, a többit átíratni, majd szó szerint visszatenni must-keep listaként és külön lexikális lekérdezésként. A mértékegységeket a szűrőkhöz normalizáljuk (az 5 l, 5L és 5000 ml egy kiszerelés), a beírt formát a lexikális sávnak tartjuk meg. Ehhez regressziós fixture: ötven valódi azonosító, és egy teszt, hogy mindegyik túlél minden prompt- és modellváltozást. A teljesebb architektúra a B2B webshopok szemantikus termékkeresése cikkben van.

Latencia és költség: mit hoz a plusz hívás

Az átírás plusz modellhívás a keresés előtt, a keresés pedig utána akár háromszor fut. A számla három része: átírási tokenek, plusz keresési és rerankelési munka, valamint a leglassabb ág faroklatenciája. A Microsoft tíz átírást említ egy 32 tokenes lekérdezésre 147 ms alatt, és ötven, 2048 tokenes dokumentum szemantikus rerankelését 158 ms alatt egy specializált kis modellnél. Egy általános chatmodell lassabb.

Az Azure agentic retrieval beállításként kínálja ugyanezt: minimal effort mellett nincs LLM-es tervezés, low mellett egy tervezési menet, medium mellett egy követő iteráció, és minden iteráció latenciát és költséget ad. A Bedrock dekompozíciója hasonló szorzót hoz: a rerankelt találatok akár ötszörösére nőhetnek a lekért találatoknak.

Tehát körönként budgetáljunk. Csak akkor írjunk át, ha a kör megkívánja: névmás, ellipszis, megváltozott feltétel, témaváltás. Strukturált feltételállapotot tartsunk az átirat helyett, stabil rendszerpromptot és sémát a prompt cachinghez, kis modellt az átíráshoz, és kemény timeoutot visszaeséssel az eredeti lekérdezésre és az örökölt szűrőkre. Egy késő átírás még adjon helyes választ, csak kevésbé okosat.

Kiértékelés: recall@k munkameneteken, nem az átíráson

A kézenfekvő metrika az emberi átíráshoz való hasonlóság. Rossz cél: a MiniELM szerzői szerint nincs egyértelmű ground truth az ideális átírásra, és nem is kell lennie, mert több átírás ugyanazokat a helyes termékeket hozhatja. A keresést és a választ értékeljük.

Az eval-készletet valódi munkamenetekből építsük. Körönként rögzítsük a felhasználói üzenetet, az átíró által látott állapotot és az elfogadható terméket. Offline játsszuk vissza több ágon: eredeti lekérdezés, egy átírás, átírás plusz HyDE, három fúzionált lekérdezés. A recall@k-t körindex szerint jelentsük, mert az első és az ötödik kör más okból hibázik.

Az utolsó sor Ragas-metrikákat használ. A faithfulness azt fogja meg, amikor a modell emlékezetből tölti ki a réseket; a response relevancy azt, amikor udvariasan más kérdésre válaszol. Egyik sem helyettesíti azt, hogy száz választ ember nézzen át, főleg ahol egy rossz kompatibilitási állítás visszáru.

Naplózzuk az ellentényt: eredeti lekérdezés, átírt lekérdezések, szűrők, jelöltazonosítók, a végső válasz azonosítója. Enélkül nem tudjuk, hogy egy rossz válasz az átírásból, a keresőből vagy a generátorból jött. A metrikatervezés ugyanaz, mint a RAG kiértékelése cikkben; az egység a munkamenet, a fontos szegmensek pedig a körindex, a kérdéstípus és a nyelv.

A pipeline, amit élesítenék

A verzió, amit egy webshop elé tennék, a kérés sorrendjében:

1. Normalizálás és védelem: nyelvfelismerés, azonosítók és mértékegységek kiemelése, a beírt forma megtartása.
2. Döntés: csak hivatkozás, ellipszis, megváltozott feltétel vagy témaváltás esetén írjunk át; különben engedjük tovább.
3. Átírás szigorú JSON-szerződésbe: önálló lekérdezés, must-keep kifejezések, preferenciaszűrők, confidence, opcionális tisztázás.
4. Séma, mezők, típusok és azonosítók validálása; hiba esetén vissza az eredeti lekérdezésre és az örökölt szűrőkre.
5. Először az azonosítós sáv, aztán hibrid, RRF-fel fúzionálva, rerankelve, hivatkozott válasz és az értelmezett lekérdezés megjelenítése.

// The rewrite contract: the model returns this, nothing else.
type Rewrite = {
  standalone: string        // query for the retriever
  must_keep: string[]       // part numbers, units, model names
  filters: { field: string; op: "eq" | "gte" | "lte" | "in"; value: string | number | string[] }[]
  confidence: number
  clarify?: { question: string; options: string[] }
}

const PREFERENCE = new Set(["material", "thread", "length_mm", "brand", "price_net"])
const ENTITLEMENT = new Set(["assortment_id", "price_list_id", "ship_country"])

function validate(r: Rewrite, identifiers: string[]) {
  if (r.filters.some((f) => ENTITLEMENT.has(f.field))) throw new Error("entitlement filter from model")
  if (r.filters.some((f) => !PREFERENCE.has(f.field))) throw new Error("unknown filter field")
  if (!identifiers.every((id) => r.must_keep.includes(id))) throw new Error("identifier lost")
  return r
}

Ha a válasz alatt ott van, hogy „Keresés: inox csavar A6, 5 l, ár 500 EUR-ig", az egy sor UI, és a legtöbb átírási hibát elkapja, mielőtt supportjegy lesz. A vevő szakértő; adjuk neki a javítás lehetőségét.

A nehéz részek az unalmasak: az azonosítóőr, a jogosultságok szétválasztása, a munkamenet-alapú eval-készlet, a visszaesés. A modell a könnyű komponens.

Források

1. Gao et al.: Precise Zero-Shot Dense Retrieval without Relevance Labels, ACL 2023
2. UTokyo-Hitotsubashi at TREC 2025 RAG Track: HyDE-Enhanced Sparse-Dense Retrieval Fusion with LLM Reranking
3. Hypothetical Documents or Knowledge Leakage? Rethinking LLM-based Query Expansion
4. ConvSearch-R1: Enhancing Query Reformulation for Conversational Search with Reasoning via Reinforcement Learning
5. CFDA and CLIP at TREC iKAT 2025: Query Reformulation and Rank Fusion
6. MiniELM: A Lightweight and Adaptive Query Rewriting Framework for E-Commerce Search Optimization
7. Microsoft Learn: Rewrite queries with semantic ranker in Azure AI Search (preview)
8. Microsoft Learn: Agentic retrieval overview in Azure AI Search
9. Microsoft Tech Community: Generative query rewriting and a new semantic ranker
10. Amazon Bedrock User Guide: Configure and customize queries and response generation
11. Ragas documentation: List of available metrics