RAG werkt beter als je data al op orde is
Elk retrieval-project dat ik mis zag gaan, ging mis om dezelfde reden, en dat was niet het model.
De demo werkt. Je richt hem op een schone map met twintig documenten en hij beantwoordt vragen netjes. Dan richt je hem op de echte gedeelde schijf en begint hij vol overtuiging een beleid te citeren dat in 2022 is vervangen.
Slechte chunks leveren beleefde onzin
Rommelige bronnen laten retrieval niet falen. Dat zou makkelijker zijn. Het geeft iets plausibels terug, netjes opgemaakt en verkeerd. Als een inhoudsopgave in dezelfde chunk belandt als een alinea echt beleid, matcht die chunk de helft van je queries en helpt hij bij geen enkele. Het chunken repareren wint van weer een ronde prompt engineering, elke keer.
Metadata doet meer werk dan de embeddings
Documenttype, bronsysteem, ingangsdatum, eigenaar. Filter daarop voordat je iets rangschikt en een flink deel van de slechte antwoorden verdwijnt, omdat het model de vervangen versie helemaal nooit ziet. Dit is ETL zonder glamour en het is het grootste deel van het werk.
Log wat er opgehaald is
Bewaar de chunk-id's, de scores en of het fallback-pad is gebruikt. Zonder dat wordt elke klacht over een slecht antwoord een archeologisch project. Met dat erbij zie je meestal binnen een minuut of retrieval het miste of het model negeerde wat het kreeg, en die twee los je heel anders op.
Smal wint van breed
RAG houdt stand als de corpus een eigenaar heeft en de vragen een vorm. Doorzoek alles wat het bedrijf ooit geschreven heeft is geen afgebakend probleem, en geen hoeveelheid reranking maakt er een van. Ik lever liever het handboek van één afdeling dat goed werkt dan alles dat een beetje werkt.