Het bouwen van geavanceerde systemen voor generatie met retrieval ondersteuning.

In dit artikel wordt retrieval-augmented generation (RAG) diepgaand onderzocht. We beschrijven het werk en de overwegingen die ontwikkelaars nodig hebben om een rag-oplossing te maken die gereed is voor productie.

Voor meer informatie over twee opties voor het bouwen van een 'chat over uw gegevens'-toepassing, een van de belangrijkste use cases voor generatieve AI in bedrijven, raadpleegt u LLM's uitbreiden met RAG of afstemmen.

In het volgende diagram ziet u de stappen of fasen van RAG:

Deze weergave wordt naïeve RAGgenoemd. Het is een handige manier om in eerste instantie inzicht te krijgen in de mechanismen, rollen en verantwoordelijkheden die nodig zijn voor het implementeren van een RAG-chatsysteem.

Maar een echte implementatie heeft nog veel meer voorverwerkings- en naverwerkingsstappen om de artikelen, query's en antwoorden voor gebruik voor te bereiden. Het volgende diagram is een realistischer beeld van een RAG, ook wel geavanceerde RAG-genoemd:

Dit artikel biedt een conceptueel kader voor het begrijpen van de voorverwerkings- en naverwerkingsfasen in een echt RAG-chatsysteem:

• Opnamefase
• Inference-pijplijnfase
• Evaluatiefase

Opname

Gegevensinvoer gaat voornamelijk over het opslaan van de documenten van uw organisatie, zodat deze eenvoudig kunnen worden opgehaald om de vraag van een gebruiker te beantwoorden. De uitdaging is ervoor te zorgen dat de gedeelten van de documenten die het beste overeenkomen met de query van de gebruiker zich bevinden en worden gebruikt tijdens deductie. Matching wordt voornamelijk bereikt door vectorized embeddings en een cosinus-gelijkeniszoekopdracht. Vergelijking wordt echter mogelijk gemaakt door inzicht te krijgen in de aard van de inhoud (bijvoorbeeld patronen en vormen) en de strategie van de gegevensorganisatie (de structuur van de gegevens wanneer deze worden opgeslagen in de vectordatabase).

Voor opname moeten ontwikkelaars rekening houden met de volgende stappen:

• Voorverwerking en extractie van inhoud
• Segmenteringsstrategie
• Segmenteringsorganisatie
• Strategie bijwerken

Voorverwerking en extractie van inhoud

Schone en nauwkeurige inhoud is een van de beste manieren om de algehele kwaliteit van een RAG-chatsysteem te verbeteren. Om schone, nauwkeurige inhoud te krijgen, analyseert u eerst de vorm en vorm van de documenten die moeten worden geïndexeerd. Voldoen de documenten aan de opgegeven inhoudspatronen, zoals documentatie? Zo niet, welke typen vragen kunnen de documenten beantwoorden?

Creëer op zijn minst stappen in de aanvoerpijplijn om:

• Tekstopmaak standaardiseren
• Speciale tekens verwerken
• Niet-gerelateerde, verouderde inhoud verwijderen
• Account voor versieversies van inhoud
• Account voor inhoudservaring (tabbladen, afbeeldingen, tabellen)
• Metagegevens extraheren

Sommige van deze informatie (zoals metagegevens, bijvoorbeeld) kunnen nuttig zijn als het wordt bewaard bij het document in de vectordatabase dat moet worden gebruikt tijdens het ophalen en evalueren van de deductiepijplijn. Het kan ook worden gecombineerd met het tekstsegment om de vectorinbedding van het segment te beïnvloeden.

Segmenteringsstrategie

Als ontwikkelaar moet u beslissen hoe u een groter document opsplitst in kleinere segmenten. Segmentering kan de relevantie van de aanvullende inhoud die naar de LLM wordt verzonden verbeteren om gebruikersquery's nauwkeurig te beantwoorden. Overweeg ook hoe u de segmenten kunt gebruiken na het ophalen. Systeemontwerpers moeten algemene industrietechnieken onderzoeken en experimenteren. U kunt uw strategie zelfs testen in een beperkte capaciteit in uw organisatie.

Ontwikkelaars moeten rekening houden met:

• Optimalisatie van segmentgrootte: Bepaal de ideale segmentgrootte en hoe u een segment aanwijst. Per sectie? Per alinea? Op zin?
• Overlappende en schuifvenstersegmenten: Bepaal of de inhoud moet worden verdeeld in afzonderlijke segmenten of overlappen de segmenten? U kunt beide zelfs doen, in een schuifvensterontwerp.
• Small2Big: wanneer segmentering wordt uitgevoerd op een gedetailleerd niveau als één zin, is de inhoud geordend, zodat u gemakkelijk de aangrenzende zinnen of de alinea met de zin kunt vinden? Als u deze informatie opvraagt en aan de LLM levert, kan deze informatie meer context bieden om gebruikersquery's te beantwoorden. Zie de volgende sectie voor meer informatie.

Segmenteringsorganisatie

In een RAG-systeem is het strategisch ordenen van uw gegevens in de vectordatabase een sleutel tot het efficiënt ophalen van relevante informatie om het generatieproces te verbeteren. Hier volgen de typen indexerings- en ophaalstrategieën die u kunt overwegen:

• hiërarchische indexen: bij deze benadering moet u meerdere lagen indexen maken. Een index op het hoogste niveau (een samenvattingsindex) beperkt de zoekruimte snel tot een subset van mogelijk relevante segmenten. Een index op het tweede niveau (een segmentindex) biedt gedetailleerdere aanwijzers naar de werkelijke gegevens. Deze methode kan het ophaalproces aanzienlijk versnellen omdat het aantal vermeldingen dat in de gedetailleerde index moet worden gescand, wordt verminderd door eerst door de samenvattingsindex te filteren.
• Gespecialiseerde indexen: afhankelijk van de aard van de gegevens en de relaties tussen segmenten, kunt u gespecialiseerde indexen gebruiken, zoals op grafieken gebaseerde of relationele databases:
  • Indexen op basis van grafieken zijn handig wanneer de segmenten onderling verbonden informatie of relaties hebben die het ophalen kunnen verbeteren, zoals bronvermeldingsnetwerken of kennisgrafieken.
  • kunnen relationele databases effectief zijn als de delen in tabelvorm zijn gestructureerd. Gebruik SQL-query's om gegevens te filteren en op te halen op basis van specifieke kenmerken of relaties.
• hybride indexen: een hybride benadering combineert meerdere indexeringsmethoden om hun sterke punten toe te passen op uw algehele strategie. U kunt bijvoorbeeld een hiërarchische index gebruiken voor het initiële filteren en een index op basis van grafieken om relaties tussen segmenten dynamisch te verkennen tijdens het ophalen.

Optimalisatie van uitlijning

Als u de relevantie en nauwkeurigheid van de opgehaalde segmenten wilt verbeteren, moet u deze nauwkeurig uitlijnen op de vraag- of querytypen die ze beantwoorden. Een strategie is het genereren en invoegen van een hypothetische vraag voor elk segment dat de vraag aangeeft die het segment het meest geschikt is om te beantwoorden. Dit helpt op verschillende manieren:

• Verbeterde overeenkomsten: Tijdens het ophalen kan het systeem de binnenkomende query vergelijken met deze hypothetische vragen om te zoeken naar de beste overeenkomst en de relevantie van de opgehaalde segmenten te verbeteren.
• Trainingsgegevens voor machine learning-modellen: deze combinaties van vragen en segmenten kunnen trainingsgegevens zijn om de machine learning-modellen te verbeteren die de onderliggende onderdelen van het RAG-systeem zijn. Het RAG-systeem leert welke typen vragen het beste door elk segment worden beantwoord.
• Directe query-afhandeling: Als een echte gebruikersquery nauw aansluit bij een hypothetische vraag, kan het systeem het bijbehorende segment snel ophalen en gebruiken, en zo de reactietijd versnellen.

De hypothetische vraag van elk segment fungeert als een label dat het ophaalalgoritme begeleidt, zodat het beter gericht en contextbewuster is. Dit soort optimalisatie is handig wanneer de segmenten betrekking hebben op een breed scala aan informatieonderwerpen of -typen.

Strategieën bijwerken

Als uw organisatie documenten indexeert die regelmatig worden bijgewerkt, is het essentieel om een bijgewerkte verzameling te onderhouden om ervoor te zorgen dat het retriever-onderdeel toegang heeft tot de meest recente informatie. Het retriever-onderdeel is de logica in het systeem waarmee de query wordt uitgevoerd op de vectordatabase en vervolgens resultaten retourneert. Hier volgen enkele strategieën voor het bijwerken van de vectordatabase in deze typen systemen:

• incrementele updates:

  • regelmatige intervallen: Updates plannen met regelmatige tussenpozen (bijvoorbeeld dagelijks of wekelijks) afhankelijk van de frequentie van documentwijzigingen. Deze methode zorgt ervoor dat de database periodiek wordt vernieuwd volgens een bekend schema.
  • updates op basis van triggers: Implementeer een systeem waarin een update dient als trigger voor herindexering. Een wijziging of toevoeging van een document start bijvoorbeeld automatisch opnieuw indexeren in de betreffende secties.

• gedeeltelijke updates:

  • Selectief opnieuw indexeren: In plaats van een volledige database opnieuw te indexeren, werkt u alleen de gewijzigde verzamelingsonderdelen bij. Deze aanpak kan efficiënter zijn dan volledig opnieuw indexeren, met name voor grote gegevenssets.
  • Delta-codering: Sla alleen de verschillen op tussen de bestaande documenten en de bijgewerkte versies. Deze aanpak vermindert de belasting van gegevensverwerking door te voorkomen dat ongewijzigde gegevens moeten worden verwerkt.

• versiebeheer:

  • Momentopnamen: behoud documentinhoudsversies op verschillende tijdstippen. Deze techniek biedt een back-upmechanisme en stelt het systeem in staat om terug te keren naar of te verwijzen naar eerdere versies.
  • Documentversiebeheer: gebruik een versiebeheersysteem om documentwijzigingen systematisch bij te houden voor het onderhouden van de wijzigingsgeschiedenis en het vereenvoudigen van het updateproces.

• realtime-updates:

  • streamverwerking: wanneer de actualiteit van informatie cruciaal is, gebruikt u technologieën voor streamverwerking om realtime updates van vectordatabases uit te voeren bij documentwijzigingen.
  • Live-query's uitvoeren: in plaats van alleen te vertrouwen op vooraf geïndexeerde vectoren, gebruikt u een benadering voor livegegevensquery's voor up-to-datumreacties, waarbij livegegevens mogelijk worden gecombineerd met resultaten in de cache voor efficiëntie.

• Optimalisatietechnieken:

  • Batch-verwerking: Batchverwerking verzamelt wijzigingen om deze minder vaak toe te passen, wat de optimalisatie van resources en de vermindering van overhead bevordert.

  • Hybride benaderingen: Verschillende strategieën combineren:

    • Gebruik incrementele updates voor kleine wijzigingen.
    • Gebruik volledige herindexering voor belangrijke updates.
    • Documenteer structurele wijzigingen die worden aangebracht in het corpus.

Het kiezen van de juiste updatestrategie of de juiste combinatie is afhankelijk van specifieke vereisten, waaronder:

• Grootte van documentinhoud
• Updatefrequentie
• Reële tijd gegevensbehoeften
• Resourcebeschikbaarheid

Evalueer deze factoren op basis van de behoeften van de specifieke toepassing. Elke benadering heeft een afweging in complexiteit, kosten en updatelatentie.

Deductiepijplijn

Uw artikelen worden gesegmenteerd, gevectoriseerd en opgeslagen in een vectordatabase. Draai nu uw focus om voltooiingsproblemen op te lossen.

Om de meest nauwkeurige en efficiënte voltooiingen te krijgen, moet u rekening houden met veel factoren:

• Is de query van de gebruiker geschreven op een manier om de resultaten te verkrijgen die de gebruiker zoekt?
• Schendt de query van de gebruiker een van de beleidsregels van de organisatie?
• Hoe herschrijft u de query van de gebruiker om de kans te verbeteren dat de dichtstbijzijnde overeenkomsten in de vectordatabase worden gevonden?
• Hoe evalueert u queryresultaten om ervoor te zorgen dat de artikelsegmenten zijn uitgelijnd op de query?
• Hoe evalueert en wijzigt u de queryresultaten voordat u ze doorgeeft aan de LLM om ervoor te zorgen dat de meest relevante details worden opgenomen in de voltooiing?
• Hoe evalueert u het antwoord van de LLM om ervoor te zorgen dat de voltooiing van de LLM de oorspronkelijke query van de gebruiker beantwoordt?
• Hoe zorgt u ervoor dat het antwoord van de LLM voldoet aan het beleid van de organisatie?

De volledige deductiepijplijn wordt in realtime uitgevoerd. Er is geen goede manier om uw stappen voor voorverwerking en naverwerking te ontwerpen. Waarschijnlijk kiest u een combinatie van programmeerlogica en andere LLM-aanroepen. Een van de belangrijkste overwegingen is de afweging tussen het bouwen van de meest nauwkeurige en compatibele pijplijn en de kosten en latentie die nodig zijn om dit te laten gebeuren.

Laten we specifieke strategieën identificeren in elke fase van de deductiepijplijn.

Stappen voor het vooraf verwerken van query's

Het voorverwerken van query's vindt direct plaats nadat de gebruiker de query heeft verzonden:

Het doel van deze stappen is om ervoor te zorgen dat de gebruiker vragen stelt die zich binnen het bereik van uw systeem bevinden en de query van de gebruiker voorbereidt om de kans te vergroten dat het de best mogelijke artikelsegmenten vindt met behulp van de cosinus-gelijkenis of de dichtstbijzijnde buur zoeken.

beleidscontrole: deze stap omvat logica die bepaalde inhoud identificeert, verwijdert, markeert of weigert. Enkele voorbeelden zijn het verwijderen van persoonlijke gegevens, het verwijderen van expletives en het identificeren van 'jailbreak'-pogingen. Jailbreaking- verwijst naar pogingen van gebruikers om de ingebouwde veiligheids-, ethische of operationele richtlijnen van het model te omzeilen of te manipuleren.

Query herschrijven: deze stap kan bestaan uit het uitvouwen van acroniemen en het verwijderen van slang tot het zo herformuleren van de vraag dat deze abstracter wordt gesteld, om concepten en principes op hoog niveau te extraheren (terugstap-prompt).

Een variatie op stapsgewijze instructies is Hypothetical Document Embeddings (HyDE). HyDE gebruikt de LLM om de vraag van de gebruiker te beantwoorden, maakt een insluiting voor dat antwoord (het hypothetische document insluiten) en gebruikt vervolgens de insluiting om een zoekopdracht uit te voeren op de vectordatabase.

Subquery's

De verwerkingsstap voor subquery's is gebaseerd op de oorspronkelijke query. Als de oorspronkelijke query lang en complex is, kan het handig zijn om deze programmatisch op te splitsen in verschillende kleinere query's en vervolgens alle antwoorden te combineren.

Een vraag over wetenschappelijke ontdekkingen in de natuurkunde kan bijvoorbeeld zijn: "Wie heeft meer significante bijdragen geleverd aan moderne natuurkunde, Albert Einstein of Niels Bohr?"

Door complexe query's op tesplitsen in subquery's, kunnen ze beter worden beheerd:

• Subquery 1: "Wat zijn de belangrijkste bijdragen van Albert Einstein aan moderne natuurkunde?"
• Subquery 2: "Wat zijn de belangrijkste bijdragen van Niels Bohr aan moderne natuurkunde?"

De resultaten van deze subquery's beschrijven de belangrijkste theorieën en ontdekkingen van elke fysicus. Voorbeeld:

• Voor Einstein kunnen bijdragen de theorie van relativiteit, het foto-elektrische effect en E=mc^2omvatten.
• Voor Bohr zijn bijdragen mogelijk het model van het waterstofatomen, bohr's werk aan kwantummechanica en bohr's principe van complementariteit.

Wanneer deze bijdragen worden beschreven, kunnen ze worden beoordeeld om meer subquery's te bepalen. Voorbeeld:

• Subquery 3: "Hoe hebben de theorieën van Einstein invloed gehad op de ontwikkeling van moderne natuurkunde?"
• Subquery 4: "Hoe hebben Bohr's theorieën invloed op de ontwikkeling van moderne natuurkunde?"

Deze subquery's verkennen de invloed van elke wetenschapper op de natuurkunde, zoals:

• Hoe De theorieën van Newton leidden tot vooruitgang in cosmologie en kwantumtheorie
• Hoe Bohr's werk heeft bijgedragen aan het begrijpen van atomische structuur en kwantummechanica

Door de resultaten van deze subquery's te combineren, kan het taalmodel een uitgebreider antwoord vormen over wie meer significante bijdragen heeft geleverd aan moderne natuurkunde op basis van hun theoretische ontwikkelingen. Deze methode vereenvoudigt de oorspronkelijke complexe query door toegang te krijgen tot specifiekere, beantwoordbare onderdelen en deze bevindingen vervolgens samen te stellen in een coherent antwoord.

Queryrouter

Uw organisatie kan ervoor kiezen om het inhoudsbestand te verdelen in meerdere vectorarchieven of in volledige ophaalsystemen. In dat scenario kunt u een queryrouter gebruiken. Een queryrouter de meest geschikte database of index selecteert om de beste antwoorden op een specifieke query te bieden.

Een queryrouter werkt doorgaans op een punt nadat de gebruiker de query heeft geformuleerd, maar voordat deze wordt verzonden naar ophaalsystemen.

Hier volgt een vereenvoudigde werkstroom voor een queryrouter:

1. queryanalyse: de LLM of een ander onderdeel analyseert de binnenkomende query om inzicht te krijgen in de inhoud, context en het type informatie dat waarschijnlijk nodig is.
2. indexselectie: op basis van de analyse selecteert de queryrouter een of meer indexen uit mogelijk verschillende beschikbare indexen. Elke index kan worden geoptimaliseerd voor verschillende typen gegevens of query's. Sommige indexen zijn bijvoorbeeld geschikter voor feitelijke query's. Andere indexen kunnen excelleren in het verstrekken van meningen of subjectieve inhoud.
3. query verzenden: de query wordt verzonden naar de geselecteerde index.
4. resultatenaggregatie: antwoorden van de geselecteerde indexen worden opgehaald en mogelijk geaggregeerd of verder verwerkt om een uitgebreid antwoord te vormen.
5. Answer Generation: de laatste stap omvat het genereren van een coherent antwoord op basis van de opgehaalde informatie, waarbij mogelijk inhoud uit meerdere bronnen wordt geïntegreerd of gesyntheteerd.

Uw organisatie kan meerdere ophaalengines of indexen gebruiken voor de volgende gebruiksscenario's:

• specialisatie van gegevenstypen: sommige indexen zijn mogelijk gespecialiseerd in nieuwsartikelen, andere in academische documenten en nog andere in algemene webinhoud of specifieke databases, zoals voor medische of juridische informatie.
• optimalisatie van querytypen: bepaalde indexen kunnen worden geoptimaliseerd voor snelle feitelijke opzoekacties (bijvoorbeeld datums of gebeurtenissen). Andere kunnen beter worden gebruikt voor complexe redeneringstaken of voor query's waarvoor uitgebreide domeinkennis is vereist.
• Algoritmeverschillen: Verschillende ophaalalgoritmen kunnen worden gebruikt in verschillende engines, zoals op vector gebaseerde overeenkomsten, traditionele zoekopdrachten op basis van trefwoorden of geavanceerdere semantische begripsmodellen.

Stel dat een RAG-systeem wordt gebruikt in een medische adviescontext. Het systeem heeft toegang tot meerdere indexen:

• Een medische onderzoeksdocumentindex die is geoptimaliseerd voor gedetailleerde en technische uitleg
• Een klinische casestudy-index die praktijkvoorbeelden van symptomen en behandelingen biedt
• Een algemene index voor gezondheidsinformatie voor basisquery's en openbare gezondheidsinformatie

Als een gebruiker een technische vraag stelt over de chemische effecten van een nieuw medicijn, kan de queryrouter prioriteit geven aan de medische onderzoekspapierindex vanwege de diepte en technische focus. Voor een vraag over typische symptomen van een veelvoorkomende ziekte, kan de algemene gezondheidsindex echter worden gekozen voor zijn brede en gemakkelijk begrijpelijke inhoud.

Verwerkingsstappen na het ophalen

Na het ophalen vindt de verwerking plaats nadat het retriever-onderdeel relevante inhoudssegmenten ophaalt uit de vectordatabase:

Bij het ophalen van segmenten van kandidaat-inhoud is de volgende stap het valideren van het artikelsegment wanneer het toevoegen van de LLM-prompt voordat u de prompt voorbereidt die aan de LLM moet worden gepresenteerd.

Hier volgen enkele promptaspecten die u moet overwegen:

• Het opnemen van te veel aanvullingsinformatie kan ertoe leiden dat de belangrijkste informatie wordt genegeerd.
• Het opnemen van irrelevante informatie kan een negatieve invloed hebben op het antwoord.

Een andere overweging is het naald in een hooiberg probleem, een term die verwijst naar een bekende eigenaardigheid van sommige LLM's waarbij de inhoud aan het begin en einde van een prompt meer gewicht voor de LLM heeft dan de inhoud in het midden.

Houd ten slotte rekening met de maximale contextvensterlengte van de LLM en het aantal tokens dat nodig is om buitengewoon lange prompts te voltooien (met name voor query's op schaal).

Om deze problemen op te lossen, kan een pijplijn voor het ophalen van de verwerkingspijplijn de volgende stappen bevatten:

• Resultaten filteren: Zorg er in deze stap voor dat de artikelsegmenten die door de vectordatabase worden geretourneerd relevant zijn voor de query. Als dat niet zo is, wordt het resultaat genegeerd wanneer de LLM-prompt is samengesteld.
• Opnieuw rangschikken: Rangschik de artikelsegmenten die zijn opgehaald uit het vectorarchief om ervoor te zorgen dat relevante details zich aan de randen (het begin en het einde) van de prompt bevinden.
• Promptcompressie: Gebruik een klein, goedkoop model om meerdere artikelsegmenten te comprimeren en samen te vatten in één gecomprimeerde prompt voordat u de prompt naar de LLM verzendt.

Verwerkingsstappen na voltooiing

Na voltooiing wordt de verwerking uitgevoerd nadat de query van de gebruiker en alle inhoudssegmenten naar de LLM zijn verzonden:

Nauwkeurigheidsvalidatie vindt plaats nadat de prompt van de LLM is voltooid. Een verwerkingspijplijn na voltooiing kan de volgende stappen bevatten:

• Feitencontrole: de bedoeling is om specifieke claims te identificeren die in het artikel worden gepresenteerd als feiten en om deze feiten vervolgens op nauwkeurigheid te controleren. Als de stap voor het controleren van feiten mislukt, kan het handig zijn om de LLM opnieuw te vragen in de hoop een beter antwoord te krijgen of om een foutbericht te retourneren aan de gebruiker.
• Beleid controleert: de laatste verdedigingslinie om ervoor te zorgen dat antwoorden geen schadelijke inhoud bevatten, ongeacht of deze voor de gebruiker of voor de organisatie zijn.

Beoordeling

Het evalueren van de resultaten van een niet-deterministisch systeem is niet zo eenvoudig als het uitvoeren van de eenheidstests of integratietests waarmee de meeste ontwikkelaars bekend zijn. U moet rekening houden met verschillende factoren:

• Zijn gebruikers tevreden over de resultaten die ze krijgen?
• Krijgen gebruikers nauwkeurige antwoorden op hun vragen?
• Hoe legt u feedback van gebruikers vast? Hebt u beleidsregels die bepalen welke gegevens u over gebruikersgegevens kunt verzamelen?
• Voor de diagnose van onbevredigende reacties, hebt u inzicht in al het werk dat is gegaan om de vraag te beantwoorden? Houdt u een logboek bij van elke fase in de deductiepijplijn van invoer en uitvoer, zodat u een hoofdoorzaakanalyse kunt uitvoeren?
• Hoe kunt u wijzigingen aanbrengen in het systeem zonder regressie of degradatie van resultaten?

Feedback van gebruikers vastleggen en erop reageren

Zoals eerder beschreven, moet u mogelijk samenwerken met het privacyteam van uw organisatie om mechanismen voor het vastleggen van feedback te ontwerpen, evenals telemetrie en het loggen voor forensische analyse en hoofdoorzaakanalyse van een querysessie.

De volgende stap is het ontwikkelen van een evaluatiepijplijn. Een evaluatiepijplijn helpt bij de complexiteit en de tijdintensieve aard van het analyseren van exacte feedback en de hoofdoorzaken van de antwoorden die door een AI-systeem worden geleverd. Deze analyse is van cruciaal belang omdat er elke reactie moet worden onderzocht om te begrijpen hoe de AI-query de resultaten heeft geproduceerd, waarbij de geschiktheid wordt gecontroleerd van de inhoudssegmenten die worden gebruikt uit documentatie en de strategieën die worden gebruikt bij het opdelen van deze documenten.

Het omvat ook eventuele extra voorverwerkings- of naverwerkingsstappen die de resultaten kunnen verbeteren. Met dit gedetailleerde onderzoek worden vaak hiaten in de inhoud ontdekt, met name wanneer er geen geschikte documentatie bestaat om te reageren op de query van een gebruiker.

Het bouwen van een evaluatiepijplijn wordt essentieel om de schaal van deze taken effectief te beheren. Een efficiënte pijplijn maakt gebruik van aangepaste hulpprogramma's om metrische gegevens te evalueren die de kwaliteit van de antwoorden van AI benaderen. Dit systeem stroomlijnt het proces om te bepalen waarom een specifiek antwoord is gegeven op de vraag van een gebruiker, welke documenten zijn gebruikt om dat antwoord te genereren en de effectiviteit van de deductiepijplijn die de query's verwerkt.

Gouden gegevensset

Een strategie voor het evalueren van de resultaten van een niet-deterministisch systeem zoals een RAG-chatsysteem is het gebruik van een gouden gegevensset. Een gouden gegevensset is een gecureerde set vragen en goedgekeurde antwoorden, metagegevens (zoals onderwerp en type vraag), verwijzingen naar brondocumenten die kunnen dienen als grondwaar voor antwoorden en zelfs variaties (verschillende formuleringen om de diversiteit vast te leggen van hoe gebruikers dezelfde vragen kunnen stellen).

Een gouden gegevensset vertegenwoordigt het 'beste scenario'. Ontwikkelaars kunnen het systeem evalueren om te zien hoe goed het presteert en vervolgens regressietests uitvoeren wanneer ze nieuwe functies of updates implementeren.

Schade beoordelen

Schademodellering is een methodologie die is gericht op het voorzien van potentiële schade, het opsporen van tekortkomingen in een product dat risico's kan vormen voor individuen en het ontwikkelen van proactieve strategieën om dergelijke risico's te beperken.

Een hulpprogramma dat is ontworpen voor het beoordelen van de impact van technologie, met name AI-systemen, zou verschillende belangrijke onderdelen bevatten op basis van de principes van schademodellering, zoals beschreven in de verstrekte resources.

Belangrijke functies van een hulpprogramma voor evaluatie van schadelijke effecten kunnen zijn:

• belanghebbenden identificeren: het hulpprogramma kan gebruikers helpen bij het identificeren en categoriseren van verschillende belanghebbenden die worden beïnvloed door de technologie, waaronder directe gebruikers, indirect betrokken partijen en andere entiteiten, zoals toekomstige generaties of niet-menselijke factoren, zoals milieukwesties.

• Categorieën en beschrijvingen van schade: het hulpprogramma kan een uitgebreide lijst met mogelijke schade bevatten, zoals privacyverlies, emotionele nood of economische exploitatie. Het hulpprogramma kan de gebruiker door verschillende scenario's leiden, laten zien hoe de technologie deze schade kan veroorzaken en helpt bij het evalueren van zowel beoogde als onbedoelde gevolgen.

• Ernst- en waarschijnlijkheidsevaluaties: het hulpprogramma kan gebruikers helpen bij het beoordelen van de ernst en waarschijnlijkheid van elke geïdentificeerde schade. De gebruiker kan prioriteit geven aan problemen om eerst op te lossen. Voorbeelden zijn kwalitatieve evaluaties die worden ondersteund door gegevens, indien beschikbaar.

• strategieën voor risicobeperking: het hulpprogramma kan potentiële risicobeperkingsstrategieën voorstellen nadat deze schadelijke effecten heeft geïdentificeerd en geëvalueerd. Voorbeelden hiervan zijn wijzigingen in het systeemontwerp, het toevoegen van beveiligingen en alternatieve technologische oplossingen die geïdentificeerde risico's minimaliseren.

• feedbackmechanismen: het hulpprogramma moet mechanismen bevatten voor het verzamelen van feedback van belanghebbenden, zodat het evaluatieproces dynamisch en responsief is op nieuwe informatie en perspectieven.

• Documentatie en rapportage: voor transparantie en verantwoordelijkheid kan het hulpprogramma gedetailleerde rapporten vergemakkelijken die het evaluatieproces, bevindingen en mogelijke risicobeperkingsacties documenteert.

Deze functies kunnen u helpen bij het identificeren en beperken van risico's, maar ze helpen u ook bij het ontwerpen van meer ethische en verantwoorde AI-systemen door vanaf het begin een breed scala aan effecten te overwegen.

Zie de volgende artikelen voor meer informatie:

• Grondbeginselen van het beoordelen van schade
• Soorten schade

De beveiliging testen en controleren

In dit artikel worden verschillende processen beschreven die zijn gericht op het beperken van de mogelijkheid van een RAG-chatsysteem dat wordt misbruikt of gecompromitteerd. Red-teaming speelt een cruciale rol bij het garanderen dat de maatregelen effectief zijn. Red-teaming omvat het simuleren van de acties van een potentiële kwaadwillende persoon om potentiële zwakke punten of beveiligingsproblemen in de toepassing te ontdekken. Deze aanpak is vooral essentieel bij het aanpakken van het aanzienlijke risico op jailbreaking.

Ontwikkelaars moeten de op RAG gebaseerde chatsysteembeveiligingen grondig beoordelen in verschillende richtlijnscenario's om ze effectief te testen en te verifiëren. Deze aanpak zorgt niet alleen voor robuustheid, maar helpt u ook bij het verfijnen van de reacties van het systeem om strikt te voldoen aan gedefinieerde ethische normen en operationele procedures.

Laatste overwegingen voor toepassingsontwerp

Hier volgt een korte lijst met zaken die u kunt overwegen en andere punten uit dit artikel die van invloed kunnen zijn op uw ontwerpbeslissingen voor uw toepassing:

• Bevestig de niet-deterministische aard van generatieve AI in uw ontwerp. Plan de variabiliteit in uitvoer en stel mechanismen in om consistentie en relevantie in reacties te garanderen.
• Beoordeel de voordelen van het vooraf verwerken van gebruikersprompts tegen de mogelijke toename van latentie en kosten. Het vereenvoudigen of wijzigen van prompts voordat verzending de reactiekwaliteit kan verbeteren, maar het kan complexiteit en tijd toevoegen aan de reactiecyclus.
• Als u de prestaties wilt verbeteren, onderzoekt u strategieën voor het parallelliseren van LLM-aanvragen. Deze benadering vermindert mogelijk de latentie, maar vereist zorgvuldig beheer om verhoogde complexiteit en mogelijke gevolgen voor de kosten te voorkomen.

Als u onmiddellijk wilt experimenteren met het bouwen van een generatieve AI-oplossing, raden we u aan om Aan de slag met chatten te bekijken met behulp van uw eigen gegevensvoorbeeld voor Python. De zelfstudie is ook beschikbaar voor .NET-, Javaen JavaScript-.