BM25, embeddings en rerankers: zoekfasen kiezen
Automatische vertaling
Dit artikel is automatisch vertaald vanuit de oorspronkelijke Engelse versie.
BM25 rangschikt tekst op basis van overeenkomende zoektermen. Embeddings vinden kandidaten met een vergelijkbare betekenis. Een reranker geeft de opgehaalde kandidaten opnieuw een score om hun volgorde te verbeteren. Voor engineers die zoeksystemen of RAG bouwen, pakken deze fasen verschillende problemen aan en moeten ze afzonderlijk worden getest.
Begin met BM25 en handhaaf documentrechten. Voeg embeddings toe wanneer relevante passages ontbreken doordat de zoekopdracht andere woorden gebruikt. Voeg een reranker toe wanneer de juiste passages worden opgehaald, maar te laag in de lijst staan. Behoud elke fase alleen als die de resultaten op gelabelde gegevens verbetert binnen het tijd- en kostenbudget.
Een zoekopdracht naar ERR-42 vereist bijvoorbeeld een correcte verwerking van identifiers. Een vraag over een fout na het ontwaken uit de slaapstand kan semantische matching nodig hebben als de handleiding spreekt over een ‘fout bij hervatten’. Reranking helpt pas nadat de benodigde passage in de kandidatenset terechtkomt.
Wat elke fase doet
| Fase | Methode | Doel |
|---|---|---|
| Filteren | Gestructureerde filters | Beperkingen voor tenant, rechten, product, taal, tijd en beschikbaarheid handhaven. |
| Lexicale retrieval | BM25 | Termen matchen; IDs en foutcodes behouden met geschikte velden of analyzers. |
| Dense retrieval | Embeddings | Synoniemen, parafrases, onduidelijke intentie en semantische recall. |
| Samenvoegen | Reciprocal Rank Fusion of gewogen combinatie van retrievers | Sparse en dense kandidaten samenvoegen zonder hun scores als vergelijkbaar te behandelen. |
| Reranking | Cross-encoder | De zoekopdracht samen met elke kandidaat lezen om een korte lijst te scoren. |
| Uiteindelijke precisie | LLM-reranker of antwoordmodel | Nuances in relevantie pas beoordelen wanneer de lijst klein is. |
| Evaluatie | Recall@k, nDCG, MRR, kliklabels, menselijke labels | Controleren of elke toegevoegde fase de baseline verbetert. |
Uitgangspunten per toepassing
| Product | Te testen aanpak | Waarom |
|---|---|---|
| Zoeken in documentatie | BM25 plus embeddings plus cross-encoder | Exacte API-namen en semantische vragen zijn allebei belangrijk. |
| RAG retrieval | BM25-baseline; hybrid retrieval en reranking vergelijken | Bewijsdekking, onderbouwing van antwoorden en latency beoordelen. |
| Zoeken naar producten | Lexicale filters plus hybrid retrieval plus zakelijke kenmerken | Beschikbaarheid, prijs, populariteit en exacte facetten zijn belangrijk. |
| Zoeken voor ondersteuning | Hybrid retrieval plus actualiteit en ticketmetadata | Vergelijkbare formuleringen en actueel beleid zijn allebei belangrijk. |
| Interne kennisbank | BM25-baseline, daarna dense retrieval op basis van zoeklogboeken | Begin met meetbare resultaten voordat je modelkosten toevoegt. |
| Juridisch zoeken of zoeken voor naleving | Lexicale baseline plus strikte filters, daarna zorgvuldige semantische uitbreiding | Fout-positieve en fout-negatieve resultaten zijn allebei kostbaar. |
Waarom BM25 nog steeds in de stack hoort
Embeddings vinden tekst met een vergelijkbare betekenis, maar vervangen exacte matching niet betrouwbaar. Foutcodes, functienamen, product-SKUs, juridische formuleringen en persoonsnamen geven de bedoeling vaak aan door hun exacte spelling. BM25 is een nuttige baseline omdat het overeenkomende termen beloont. Tekstanalyse kan deze termen wijzigen: de standaardanalyzer van Elasticsearch splitst tekst en zet die om naar kleine letters. Behoud IDs die gevoelig zijn voor leestekens, zoals ERR-42, met een geschikte analyzer of een veld voor exacte waarden. BM25-ranking garandeert geen exacte gelijkheid van tekenreeksen.
Dense retrieval kan relevante resultaten toevoegen wanneer gebruikers de woordenschat van het document niet kennen. Test het naast BM25. Als de twee retrievers nuttige, aanvullende resultaten vinden, kan RRF hun gerangschikte lijsten combineren. Het gebruikt resultaatposities in plaats van ruwe lexicale scores en embeddingscores te vergelijken.
Wanneer je een reranker toevoegt
Voeg een cross-encoder toe wanneer relevante documenten in de kandidatenset terechtkomen, maar te laag worden gerangschikt. Een cross-encoder leest de zoekopdracht samen met elk kandidaatdocument. Daarvoor is per paar een modelpass nodig, dus pas dit toe op een korte lijst. Kies het aantal kandidaten op basis van gemeten recall en latency; de eerste 50 zijn een nuttig experiment, geen universele drempel.
Test een LLM-reranker wanneer een cross-encoder verschillen mist die je toepassing nodig heeft, zoals welke versie van een beleidsregel geldt. Dit voegt modelwerk toe waarvan de kosten afhangen van het aantal kandidaten en de invoerlengte. Vergelijk kwaliteit, latency en kosten op dezelfde korte lijst voordat je de reranker behoudt.
Recall@k meet hoeveel gelabeld relevant materiaal in de eerste k resultaten verschijnt. MRR beloont een hoge positie voor het eerste relevante resultaat; nDCG meet de volgorde wanneer labels verschillende relevantieniveaus hebben. Precision@1 controleert of het eerste resultaat relevant is.
Evaluatievolgorde
- Label echte zoekopdrachten voor belangrijke intenties, talen, rechten en foutkosten. Begin klein en breid uit totdat de deelgroepen en onzekerheid de beslissing ondersteunen.
- Meet BM25 afzonderlijk.
- Test dense retrieval wanneer BM25 relevante passages mist.
- Als de twee resultaatsets elkaar aanvullen, test dan samenvoeging met nDCG en Recall@k.
- Test cross-encoder reranking wanneer relevante kandidaten te laag staan; meet Precision@1 en nDCG.
- Voeg LLM reranking alleen toe als dit de kwaliteit verbetert nadat kosten en latency zijn meegerekend.
- Volg productiemetingen: aandeel zoekopdrachten zonder resultaten, aandeel herformuleringen, klikratio, antwoordcorrecties, p95-latency en kosten.
Verder lezen
- Opbouw van zoekranking bevat de volledige implementatiehandleiding.
- Evaluatiemetrieken voor RAG licht de evaluatie van retrieval en bronverwijzingen toe.