Inleiding tot evaluatie en bewaking van RAG-toepassingen
Evaluatie en bewaking zijn essentiële onderdelen om te begrijpen of uw RAG-toepassing presteert op basis van de *kwaliteit, kosten en latentievereisten die zijn bepaald door uw use-case. Technisch gezien vindt evaluatie plaats tijdens de ontwikkeling en bewaking zodra de toepassing in productie is geïmplementeerd, maar de fundamentele onderdelen zijn vergelijkbaar.
RAG over ongestructureerde gegevens is een complex systeem met veel onderdelen die van invloed zijn op de kwaliteit van de toepassing. Het aanpassen van een enkel element kan trapsgewijze effecten hebben op de andere elementen. Wijzigingen in gegevensopmaak kunnen bijvoorbeeld van invloed zijn op de opgehaalde segmenten en de mogelijkheid van de LLM om relevante antwoorden te genereren. Daarom is het van cruciaal belang om elk van de onderdelen van de toepassing naast de toepassing als geheel te evalueren om deze iteratief te verfijnen op basis van deze evaluaties.
Evaluatie en bewaking: Klassieke ML versus generatieve AI
Evaluatie en bewaking van Generatieve AI-toepassingen, waaronder RAG, verschilt op verschillende manieren van klassieke machine learning:
| Onderwerp | Klassieke Machine Learning | Generatieve AI |
|---|---|---|
| Metrische gegevens | Metrics evalueren de invoer en uitvoer van het onderdeel, bijvoorbeeld functiedrift, precisie, terugroepwaarde, latentie, enzovoort. Omdat er slechts één onderdeel is, zijn algemene metrische gegevens == metrische gegevens van onderdelen. | Metrische onderdelen evalueren de invoer en uitvoer van elk onderdeel, bijvoorbeeld precisie @ K, nDCG, latentie, toxiciteit, enzovoort. Samengestelde meetwaarden evalueren hoe meerdere componenten interacteren: Getrouwheid beoordeelt hoe goed de generator zich houdt aan de kennis van een retriever, waarvoor de keteninvoer, ketenuitvoer en uitvoer van de interne retriever nodig zijn. Algemene metrische gegevens evalueren de algehele invoer en uitvoer van het systeem, bijvoorbeeld de juistheid en latentie van het antwoord. |
| Beoordeling | Antwoord is deterministisch 'juist' of 'verkeerd'. Deterministische maatstaven werken. | Antwoord is 'juist' of 'verkeerd', maar: • Er zijn veel juiste antwoorden (niet-deterministisch). • Sommige juiste antwoorden zijn meer juist. U hebt het volgende nodig: • Menselijke feedback om zeker te zijn. • Metrische gegevens die door LLM worden beoordeeld om de evaluatie te schalen. |
Onderdelen van evaluatie en bewaking
Voor het effectief evalueren en bewaken van rag-toepassingskwaliteit, kosten en latentie zijn verschillende onderdelen vereist:
- evaluatieset: Om uw RAG-toepassing grondig te evalueren, hebt u een samengestelde set evaluatiequery's (en idealiter uitvoer) nodig die representatief zijn voor het beoogde gebruik van de toepassing. Deze evaluatievoorbeelden moeten lastig, divers en bijgewerkt zijn om het veranderende gebruik en de vereisten weer te geven.
- Metrische definities: u kunt niet beheren wat u niet meet. Om de RAG-kwaliteit te verbeteren, is het essentieel om te definiëren welke kwaliteit voor uw use-case betekent. Afhankelijk van de toepassing kunnen belangrijke metrische gegevens betrekking hebben op de nauwkeurigheid van de reactie, latentie, kosten of beoordelingen van belangrijke belanghebbenden. U hebt metrische gegevens nodig waarmee elk onderdeel wordt gemeten, hoe de onderdelen met elkaar communiceren en het algehele systeem.
- LLM-rechters: Gezien de open-end aard van LLM-antwoorden, is het niet haalbaar om elke reactie te lezen wanneer u evalueert om te bepalen of de uitvoer juist is. Met behulp van een extra, andere LLM om de uitvoer te controleren, kunt u uw evaluatie schalen en aanvullende metrische gegevens berekenen, zoals de onderbouwing van een reactie in duizenden tokens van context, wat voor menselijke beoordelaars niet haalbaar is om effectief op grote schaal te beoordelen.
- Evaluatiekader: Tijdens de ontwikkeling helpt een evaluatiekader u snel uw toepassing te draaien voor elk gegeven in uw evaluatieset en daarna elke uitvoer te verwerken via uw LLM-beoordelaars en metrische berekeningen. Dit is bijzonder lastig omdat deze stap uw interne ontwikkellus blokkeert, dus snelheid is van het grootste belang. Met een goed evaluatiekader wordt dit werk zoveel mogelijk parallel uitgevoerd, waarbij vaak extra infrastructuur zoals meer LLM-capaciteit wordt opgezet om dit mogelijk te maken.
- Gebruikersinterface met belanghebbenden: als ontwikkelaar bent u mogelijk geen domeinexpert in de inhoud van de toepassing die u ontwikkelt. Als u feedback wilt verzamelen van menselijke experts die de kwaliteit van uw toepassing kunnen beoordelen, hebt u een interface nodig waarmee ze met de toepassing kunnen communiceren en gedetailleerde feedback kunnen geven.
- Logboekregistratie voor productietracering: Eenmaal in productie moet u een aanzienlijk hogere hoeveelheid aanvragen/antwoorden evalueren en hoe elk antwoord is gegenereerd. U moet bijvoorbeeld weten of de hoofdoorzaak van een antwoord van lage kwaliteit te wijten is aan de ophaalstap of een hallucinatie. De productielogboekregistratie moet de invoer, uitvoer en tussenliggende stappen bijhouden, zoals het ophalen van documenten, om doorlopende bewaking en vroege detectie en diagnose van problemen die zich in de productie voordoen, mogelijk te maken.
Deze documenten behandelen de evaluatie veel gedetailleerder in RAG-kwaliteit evalueren.