Werkstroom voor ontwikkelaars van generatieve AI-apps

Het ontwikkelen van een robuuste generatieve AI-toepassing (gen AI-app) vereist opzettelijke planning, een snelle evaluatielus voor ontwikkelingsfeedback en een schaalbare productie-infrastructuur. Deze werkstroom bevat een aanbevolen reeks stappen om u te begeleiden van het eerste proof-of-concept (POC) tot de productie-implementatie.

0. Vereisten

• Vereisten verzamelen om de geschiktheid van generatieve AI te valideren en beperkingen te identificeren.
• Ontwerp uw oplossingsarchitectuur.

1. Bouwen-

• Bereid gegevensbronnen voor en maak de benodigde hulpprogramma's.
• Bouw en valideer het eerste prototype (POC).
• Implementeren in een preproductieomgeving.

2. Evalueer & Itereer

• Feedback van gebruikers verzamelen en kwaliteit meten
• Los kwaliteitsproblemen op door agentlogica en hulpprogramma's te verfijnen op basis van evaluatie.
• Neem input van onderwerpdeskundigen (SME) op om de kwaliteit van het agentsysteem continu te verbeteren.

3. Productie-

• Implementeer gen AI-app in een productieomgeving.
• Prestaties en kwaliteit bewaken.
• Onderhouden en verbeteren op basis van het werkelijke gebruik.

Deze werkstroom moet iteratief zijn: na elke implementatie- of evaluatiecyclus keert u terug naar eerdere stappen om gegevenspijplijnen te verfijnen of agentlogica bij te werken. Productiebewaking kan bijvoorbeeld nieuwe vereisten onthullen, waardoor updates voor het agentontwerp en een andere evaluatieronde worden geactiveerd. Door deze stappen systematisch te volgen en gebruik te maken van databricks MLflow-tracering, agentframework en agentevaluatiemogelijkheden, kunt u ai-apps van hoge kwaliteit bouwen die betrouwbaar voldoen aan de behoeften van gebruikers, beveiligings- en nalevingsvereisten respecteren en in de loop van de tijd blijven verbeteren.

0. Voorwaarden

Voordat u begint met het ontwikkelen van uw gen AI-toepassing, kan het niet worden overdreven hoe belangrijk het is om tijd te nemen om het volgende goed te doen: het verzamelen van vereisten en het ontwerp van de oplossing.

Het verzamelen van vereisten omvat de volgende stappen:

• Controleer of gen AI past bij uw use-case.
• Definieer de gebruikerservaring.
• Onderzoek gegevensbronnen.
• Prestatiebeperkingen instellen.
• Beperkingen voor beveiliging vastleggen.

oplossingsontwerp het volgende omvat:

• Gegevenspijplijnen in kaart brengen.
• Identificeer de benodigde hulpprogramma's.
• Een overzicht van de algehele systeemarchitectuur.

Door dit grondwerk te leggen, stelt u een duidelijke richting in voor de volgende Build, Evaluateen Production fasen.

vereisten verzamelen

Het definiëren van duidelijke en uitgebreide use-casevereisten is een kritieke eerste stap bij het ontwikkelen van uw succesvolle GEN AI-app. Deze vereisten dienen voor de volgende doeleinden:

• Ze helpen bepalen of een GEN AI-benadering geschikt is voor uw use-case.
• Ze begeleiden het ontwerp, de implementatie en de evaluatiebeslissingen.

Investeren in tijd aan het begin om gedetailleerde vereisten te verzamelen, kan belangrijke uitdagingen later in het ontwikkelingsproces voorkomen en ervoor zorgen dat de resulterende oplossing voldoet aan de behoeften van eindgebruikers en belanghebbenden. Goed gedefinieerde vereisten bieden de basis voor de volgende fasen van de levenscyclus van uw toepassing.

Is de gebruikssituatie geschikt voor generatieve AI?

Voordat u zich gaat verbinden met een GEN AI-oplossing, moet u overwegen of de inherente sterke punten overeenkomen met uw vereisten. Enkele voorbeelden waarbij een generatieve AI-oplossing geschikt is, zijn onder andere:

• inhoudsgeneratie: De taak vereist het genereren van nieuwe of creatieve inhoud die niet kan worden bereikt met statische sjablonen of eenvoudige logica op basis van regels.
• Dynamische queryafhandeling: Gebruikersquery's zijn open-ended of complex en vragen om flexibele, contextbewuste antwoorden.
• Informatiesynthese: De use case profiteert van het combineren of samenvatten van diverse informatiebronnen om een coherente uitvoer te produceren.
• Agent Systems: De toepassing vereist meer dan alleen tekst genereren als reactie op een prompt. Het moet mogelijk het volgende kunnen doen:
  • planning en besluitvorming: formuleer een strategie met meerdere stappen om een specifiek doel te bereiken.
  • Acties ondernemen: externe processen activeren of verschillende hulpprogramma's aanroepen om taken uit te voeren (bijvoorbeeld het ophalen van gegevens, het maken van API-aanroepen, het uitvoeren van SQL-query's, het uitvoeren van code).
  • Status behouden: De gespreksgeschiedenis of taakcontext bijhouden voor meerdere interacties om continuïteit mogelijk te maken.
  • Adaptieve uitvoer produceren: Antwoorden genereren die zich ontwikkelen op basis van eerdere acties, bijgewerkte informatie of veranderende omstandigheden.

Omgekeerd is een gen AI-benadering mogelijk niet ideaal in de volgende situaties:

• De taak is zeer deterministisch en kan effectief worden opgelost met vooraf gedefinieerde sjablonen of op regels gebaseerde systemen.
• De volledige set vereiste informatie is al statisch of past binnen een eenvoudig, gesloten framework.
• Reacties met een extreem lage latentie (milliseconden) zijn vereist en de overhead van generatieve verwerking kan niet worden opgelost.
• Eenvoudige, sjabloonantwoorden zijn voldoende voor de beoogde use case.

Belangrijk

In de onderstaande secties worden labels P0, P1en P2 labels gebruikt om relatieve prioriteit aan te geven.

• 🟢 [P0] items zijn kritiek of essentieel. Deze moeten onmiddellijk worden aangepakt.
• 🟡 [P1] items zijn belangrijk, maar kunnen volgen na P0 vereisten.
• ⚪ [P2] items zijn overwegingen met een lagere prioriteit of verbeteringen die kunnen worden aangepakt als tijd en resources toestaan.

Deze labels helpen teams snel te zien welke vereisten onmiddellijk aandacht nodig hebben versus welke kunnen worden uitgesteld.

Gebruikerservaring

Definieer hoe gebruikers communiceren met de GEN AI-app en wat voor soort antwoorden er worden verwacht.

• 🟢 [P0] Typische aanvraag: Hoe ziet een typische gebruikersaanvraag eruit? Verzamel voorbeelden van belanghebbenden.
• 🟢 [P0] Verwachte antwoorden: Welk type antwoorden moet het systeem genereren (bijvoorbeeld korte antwoorden, lange uitleg, creatieve verhalen)?
• 🟡 [P1] Interactie modaliteit: Hoe communiceren gebruikers met de toepassing (bijvoorbeeld chatinterface, zoekbalk, spraakassistent)?
• 🟡 [P1] Toon, stijl, structuur: Welke toon, stijl en structuur moeten de gegenereerde uitvoer aannemen (formeel, conversationeel, technisch, opsommingstekens of continue proza)?
• 🟡 [P1]Foutafhandeling: Hoe moet de toepassing omgaan met ambigue, onvolledige of niet-gerichte queries? Moet het feedback geven of uitleg vragen?
• ⚪ [P2] Opmaakvereisten: Zijn er specifieke opmaak- of presentatierichtlijnen voor de uitvoer (inclusief metagegevens of aanvullende informatie)?

Gegevens

Bepaal de aard, de bron(en) en de kwaliteit van de gegevens die worden gebruikt in de GEN AI-app.

• 🟢 [P0] Gegevensbronnen: Welke gegevensbronnen zijn beschikbaar?
  • Bepaal voor elke bron het volgende:
    • Zijn de gegevens gestructureerd of ongestructureerd?
    • Wat is de bronindeling (bijvoorbeeld PDF, HTML, JSON, XML)?
    • Waar bevinden de gegevens zich?
    • Hoeveel gegevens zijn er beschikbaar?
    • Hoe moeten de gegevens worden geopend?
• 🟡 [P1] Gegevensupdates: Hoe vaak worden de gegevens bijgewerkt? Welke mechanismen zijn er voor het verwerken van updates?
• 🟡 [P1] Gegevenskwaliteit: Zijn er bekende kwaliteitsproblemen of inconsistenties?
  • Overweeg of kwaliteitsbewaking voor gegevensbronnen vereist is.

Overweeg om een inventaristabel te maken om deze informatie samen te voegen, bijvoorbeeld:

Gegevensbron	Bron	Bestandstype(s)	Grootte	Update-frequentie
Gegevensbron 1	Unity Catalog-volume	JSON	10 GB	Dagelijks
Gegevensbron 2	Openbare API	XML	NA (API)	Realtime
Gegevensbron 3	SharePoint	PDF, .docx	500 MB	Maandelijks

Prestatiebeperkingen

Leg prestatie- en resourcevereisten vast voor de GEN AI-toepassing.

latentie

• 🟢 [P0] Time-to-first-token: Wat is de maximaal acceptabele vertraging voordat het eerste token van uitvoer wordt geleverd?
  • Opmerking: latentie wordt meestal gemeten met p50 (mediaan) en p95 (95e percentiel) om zowel gemiddelde als slechtste prestaties vast te leggen.
• 🟢 [P0] Time-to-completion: Wat is de acceptabele reactietijd (time-to-completion) voor gebruikers?
• 🟢 [P0] Streaminglatentie: Als antwoorden worden gestreamd, is een hogere algehele latentie acceptabel?

schaalbaarheid

• 🟡 [P1]Gelijktijdige gebruikers & aanvragen: Hoeveel gelijktijdige gebruikers of aanvragen moet het systeem ondersteunen?
  • Opmerking: schaalbaarheid wordt vaak gemeten in termen van QPS (query's per seconde) of QPM (query's per minuut).
• 🟡 [P1] Gebruikspatronen: Wat zijn de verwachte verkeerspatronen, piekbelastingen of pieken in gebruik?

kostenbeperkingen

• 🟢 [P0] Deductiekostenbeperkingen: Wat zijn de kostenbeperkingen of budgetbeperkingen voor deductieresources?

Evaluatie

Bepalen hoe de gen AI-app in de loop van de tijd wordt geëvalueerd en verbeterd.

• 🟢 [P0] Zakelijke KPI's: Welk bedrijfsdoel of welke KPI moet de toepassing beïnvloeden? Definieer uw basislijnwaarden en -doelen.
• 🟢 [P0] Feedback van belanghebbenden: Wie geeft initiële en doorlopende feedback over de prestaties en uitvoer van toepassingen? Identificeer specifieke gebruikersgroepen of domeinexperts.
• 🟢 [P0] Meetkwaliteit: Welke metrische gegevens (bijvoorbeeld nauwkeurigheid, relevantie, veiligheid, menselijke scores) worden gebruikt om de kwaliteit van gegenereerde uitvoer te beoordelen?
  • Hoe worden deze metrische gegevens berekend tijdens de ontwikkeling (bijvoorbeeld tegen synthetische gegevens, handmatig samengestelde gegevenssets)?
  • Hoe wordt de kwaliteit gemeten in productie (bijvoorbeeld logboekregistratie en analyse van reacties op echte gebruikersquery's)?
  • Wat is uw algemene tolerantie voor fouten? (accepteer bijvoorbeeld een bepaald percentage kleine feitelijke onnauwkeurigheden of vereist bijna 100% juistheid voor kritieke use cases.)
  • Het doel is om te bouwen naar een evaluatieset van werkelijke gebruikersquery's, synthetische gegevens of een combinatie van beide. Deze set biedt een consistente manier om de prestaties te beoordelen naarmate het systeem zich ontwikkelt.
• 🟡 [P1] Feedbacklussen: Hoe moet gebruikersfeedback worden verzameld (bijvoorbeeld duimen omhoog/omlaag, enquêteformulieren) en worden gebruikt om iteratieve verbeteringen te stimuleren?
  • Plan hoe vaak feedback wordt beoordeeld en opgenomen.

Veiligheid

Identificeer beveiligings- en privacyoverwegingen.

• 🟢 [P0] Gegevensgevoeligheid: Zijn er gevoelige of vertrouwelijke gegevenselementen waarvoor speciale verwerking is vereist?
• 🟡 [P1] Toegangsbeheer: Moet u toegangsbeheer implementeren om bepaalde gegevens of functies te beperken?
• 🟡 [P1] Bedreigingsevaluatie & beperking: Heeft uw toepassing bescherming nodig tegen veelvoorkomende generatieve AI-bedreigingen, zoals prompt-injectie of kwaadwillende gebruikersinput?

Implementatie

Begrijpen hoe de gen AI-oplossing wordt geïntegreerd, geïmplementeerd, bewaakt en onderhouden.

• 🟡 [P1] Integratie: Hoe moet de gen AI-oplossing worden geïntegreerd met bestaande systemen en werkstromen?
  • Identificeer integratiepunten (bijvoorbeeld Slack, CRM, BI-hulpprogramma's) en vereiste gegevensconnectors.
  • Bepaal hoe aanvragen en antwoorden stromen tussen de gen AI-app en downstreamsystemen (bijvoorbeeld REST API's, webhooks).
• 🟡 [P1] Implementatie: Wat zijn de vereisten voor het implementeren, schalen en versiebeheer van de toepassing? In dit artikel wordt beschreven hoe de end-to-end levenscyclus op Databricks kan worden verwerkt met behulp van MLflow, Unity Catalog, Agent Framework, Agent Evaluationen Model Serving.
• 🟡 [P1] Productiebewaking & waarneembaarheid: Hoe bewaakt u de toepassing zodra deze in productie is?
  • Het loggen van &-traceringen: volledige uitvoeringstracering vastleggen.
  • Metrische gegevens over kwaliteit: evalueer continu belangrijke metrische gegevens (zoals juistheid, latentie, relevantie) voor liveverkeer.
  • Waarschuwingen & dashboards: waarschuwingen instellen voor kritieke problemen.
  • Feedbacklus: gebruik feedback van gebruikers in productie (duim omhoog of omlaag) om problemen vroeg te ondervangen en iteratieve verbeteringen te stimuleren.

Voorbeeld

Denk bijvoorbeeld na over hoe deze overwegingen en vereisten van toepassing zijn op een hypothetische agentische RAG-toepassing die wordt gebruikt door een Databricks-klantondersteuningsteam:

Gebied	Overwegingen	Eisen
Gebruikerservaring	Modaliteit van interactie. Typische voorbeelden van gebruikersvragen. Verwachte antwoordindeling en -stijl. Het verwerken van dubbelzinnige of irrelevante queries.	Chatinterface geïntegreerd met Slack. Voorbeeldquery's: 'Hoe verminder ik de opstarttijd van het cluster?' "Wat voor soort ondersteuningsplan heb ik?" Duidelijke, technische antwoorden met codefragmenten en koppelingen naar relevante documentatie, indien van toepassing. Geef contextuele suggesties en escaleer naar ondersteuningstechnici wanneer dat nodig is.
Agentlogica	Het begrip en de classificatie van zoekopdrachten. Meertrapsplanning en besluitvorming. Autonome selectie en uitvoering van hulpprogramma's. Status- en contextbeheer voor interacties. Foutafhandeling en terugvalmechanismen.	Door LLM aangedreven planning met deterministische terugval. Integreren met een set vooraf gedefinieerde hulpprogramma's (zoals het ophalen van documenten of het Salesforce-ophaalhulpprogramma). Behoud de gespreksstatus voor coherente multi-turn-gesprekken en voor robuust foutherstel.
Gegevens	Aantal en het type gegevensbronnen. Gegevensindeling en -locatie. Gegevensgrootte en updatefrequentie. Kwaliteit en consistentie van gegevens.	Vier gegevensbronnen. Bedrijfsdocumentatie (HTML, PDF). Opgeloste ondersteuningstickets (JSON). Communityforumposts (Delta-tabel). Salesforceconnector. Gegevens die zijn opgeslagen in Unity Catalog en wekelijks bijgewerkt. Totale gegevensgrootte: 5 GB. Consistente gegevensstructuur en kwaliteit worden onderhouden door toegewijde documentatie- en supportteams.
Prestatie	Maximale acceptabele latentie. Kostenbeperkingen. Verwacht gebruik en gelijktijdigheid.	Maximale latentievereiste. Kostenbeperkingen. Verwachte piekbelasting.
Evaluatie	Beschikbaarheid van evaluatiesets. Metrische gegevens over kwaliteit. Verzameling gebruikersfeedback.	Deskundigen van elk productgebied helpen bij het beoordelen van uitvoer en het aanpassen van onjuiste antwoorden om de evaluatiegegevensset te maken. Zakelijke KPI's. Toename van de oplossingssnelheid van ondersteuningstickets. Minder gebruikerstijd per ondersteuningsticket. Metrische gegevens over kwaliteit. De correctheid en relevantie van het antwoord beoordeeld door LLM. LLM beoordeelt de precisie van informatieopvraging. Stem omhoog of omlaag. Feedbackverzameling. Slack wordt uitgerust om een duim omhoog of omlaag te geven.
Veiligheid	Verwerking van gevoelige gegevens. Vereisten voor toegangsbeheer.	Er mogen geen gevoelige klantgegevens in de bron staan. Gebruikersverificatie via SSO van Databricks Community.
Implementatie	Integratie met bestaande systemen. Implementatie en versiebeheer.	Integratie met ondersteuningsticketsysteem. Agent uitgerold als een Databricks Model Serving-eindpunt.

Oplossingsontwerp

Databronnen & hulpmiddelen

Bij het ontwerpen van een gen AI-app is het belangrijk om de verschillende gegevensbronnen en hulpprogramma's te identificeren en toe te wijzen die nodig zijn om uw oplossing te stimuleren. Dit kan betrekking hebben op gestructureerde gegevenssets, niet-gestructureerde pijplijnen voor gegevensverwerking of het uitvoeren van query's op externe API's. Hieronder ziet u de aanbevolen methoden voor het opnemen van verschillende gegevensbronnen of hulpprogramma's in uw GEN AI-app:

Gestructureerde gegevens

Gestructureerde gegevens bevinden zich doorgaans in goed gedefinieerde tabelindelingen (bijvoorbeeld een Delta-tabel of CSV-bestand) en zijn ideaal voor taken waarbij query's vooraf zijn bepaald of dynamisch moeten worden gegenereerd op basis van gebruikersinvoer. Zie Gestructureerde hulpprogramma's voor gestructureerde gegevensophaling door AI-agenten voor aanbevelingen over het toevoegen van gestructureerde gegevens aan uw gen AI-app.

Ongestructureerde gegevens

Niet-gestructureerde gegevens bevatten onbewerkte documenten, PDF's, e-mailberichten, afbeeldingen en andere indelingen die niet voldoen aan een vast schema. Voor dergelijke gegevens is aanvullende verwerking vereist, meestal via een combinatie van parseren, segmenteren en insluiten, om effectief query's uit te voeren en te gebruiken in een GEN AI-app. Zie Niet-gestructureerde hulpprogramma's voor het ophalen van AI-agents voor aanbevelingen voor het toevoegen van gestructureerde gegevens aan uw GEN AI-app.

Externe API's & acties

In sommige scenario's moet uw gen AI-app mogelijk communiceren met externe systemen om gegevens op te halen of acties uit te voeren. In gevallen waarin uw toepassing het aanroepen van hulpprogramma's of interactie met externe API's vereist, raden we het volgende aan:

• API-referenties beheren met een Unity Catalog Connection: Een Unity Catalog-verbinding gebruiken om API-referenties veilig te beheren. Deze methode zorgt ervoor dat tokens en geheimen centraal worden beheerd en door toegang worden beheerd.
• aanroepen via de Databricks SDK:
  HTTP-aanvragen verzenden naar externe services met behulp van de functie http_request vanuit de databricks-sdk-bibliotheek. Deze functie maakt gebruik van een Unity Catalog-verbinding voor verificatie en ondersteunt standaard HTTP-methoden.
• Gebruikmaken van Unity Catalog-functies:
  Omhul externe verbindingen in een Unity Catalog-functie om aangepaste pre- of postverwerkingslogica toe te voegen.
• Python-uitvoerprogramma:
  Als u code dynamisch wilt uitvoeren voor gegevenstransformatie of API-interacties met behulp van Python-functies, gebruikt u het ingebouwde Python-uitvoerprogramma.

voorbeeld:

Een interne analysetoepassing haalt livemarktgegevens op uit een externe financiële API. De toepassing maakt gebruik van:

• Unity Catalog externe verbinding om API-referenties veilig op te slaan.
• Een aangepaste Unity Catalog-functie verpakt de API-aanroep om vooraf verwerken (zoals gegevensnormalisatie) en naverwerking (zoals foutafhandeling) toe te voegen.
• Bovendien kan de toepassing de API rechtstreeks aanroepen via de Databricks SDK.

Implementatiebenadering

Bij het ontwikkelen van een gen AI-app hebt u twee belangrijke opties voor het implementeren van de logica van uw agent: het gebruik van een opensource-framework of het bouwen van een aangepaste oplossing met behulp van Python-code. Hieronder vindt u een uitsplitsing van de voor- en nadelen voor elke benadering.

Een framework gebruiken (zoals LangChain, LlamaIndex, CrewAI of AutoGen)

Pros:

• Kant-en-klare onderdelen: Frameworks worden geleverd met kant-en-klare hulpprogramma's voor promptbeheer, ketenoproepen en integratie met verschillende gegevensbronnen, waardoor de ontwikkeling kan worden versneld.
• Community en documentatie: Profiteer van communityondersteuning, zelfstudies en regelmatige updates.
• Algemene ontwerppatronen: Frameworks bieden doorgaans een duidelijke, modulaire structuur voor het organiseren van algemene taken, waardoor het ontwerp van de algemene agent kan worden vereenvoudigd.

nadelen:

• Abstractie toegevoegd: Opensource-frameworks introduceren vaak lagen van abstractie die mogelijk niet nodig zijn voor uw specifieke use-case.
• Afhankelijkheid van updates: U bent mogelijk afhankelijk van de frameworkonderhouders voor bugfixes en functie-updates, wat uw vermogen om snel aan nieuwe vereisten aan te passen kan vertragen.
• Potentiële overhead: Extra abstractie kan leiden tot aanpassingsproblemen als uw toepassing een nauwkeuriger beheer nodig heeft.

Pure Python gebruiken

Pros:

• Flexibiliteit: Ontwikkelen in pure Python stelt u in staat om uw implementatie precies aan uw behoeften aan te passen zonder dat u wordt beperkt door de ontwerpbeslissingen van een framework.
• Snelle aanpassing: U kunt uw code snel aanpassen en zo nodig wijzigingen opnemen zonder te wachten op updates van een extern framework.
• Eenvoud: Vermijd onnodige abstractielagen, wat kan leiden tot een slankere, beter presterende oplossing.

nadelen:

• Verbeterde ontwikkelingsinspanningen: Bouwen vanaf nul vereist mogelijk meer tijd en expertise om functies te implementeren die een speciaal framework anders kan bieden.
• Het wiel opnieuw uitvinden: Mogelijk moet u zelf algemene functies (zoals het koppelen van hulpprogramma's of promptbeheer) ontwikkelen.
• verantwoordelijkheid voor onderhoud: Alle updates en bugfixes worden uw verantwoordelijkheid, wat lastig kan zijn voor complexe systemen.

Uiteindelijk moet uw beslissing worden geleid door de complexiteit, prestatiebehoeften en het controleniveau dat u nodig hebt. Geen van beide benaderingen is inherent superieure; elk biedt verschillende voordelen, afhankelijk van uw ontwikkelingsvoorkeuren en strategische prioriteiten.

1. Bouwen

In deze fase transformeert u uw oplossingsontwerp in een werkende GEN AI-toepassing. In plaats van alles vooraf te perfectioneren, begint u klein met een minimaal proof-of-concept (POC) dat snel kan worden getest. Hiermee kunt u zo snel mogelijk implementeren in een preproductieomgeving, representatieve query's verzamelen van werkelijke gebruikers of kmo's en verfijnen op basis van echte feedback.

Het buildproces volgt deze belangrijke stappen:

een. hulpprogramma's voor het voorbereiden van gegevens &: Zorg ervoor dat de vereiste gegevens toegankelijk, geparseerd en gereed zijn voor ophalen. Implementeer of registreer de Unity Catalog-functies en -verbindingen (bijvoorbeeld het ophalen van API's of externe API-aanroepen) die uw agent nodig heeft. b. Build-agent: de kernlogica organiseren, te beginnen met een eenvoudige Proof of Concept-benadering. c. Kwaliteitscontrole: Essentiële functionaliteit valideren voordat de app beschikbaar wordt gesteld aan meer gebruikers. d. Preproductieagent implementeren: de POC beschikbaar maken voor testgebruikers en deskundigen voor initiële feedback. e. Feedback van gebruikers verzamelen: gebruik in de praktijk gebruiken om verbeteringsgebieden, aanvullende gegevens of hulpprogramma's te identificeren die nodig zijn en mogelijke verfijningen voor de volgende iteratie.

een. Gegevenshulpprogramma's & voorbereiden

In de ontwerpfase van de oplossing hebt u een eerste idee van de gegevensbronnen en hulpprogramma's die nodig zijn voor uw app. Houd dit in deze fase minimaal: richt u op voldoende gegevens om uw POC te valideren. Dit zorgt voor snelle iteratie zonder zware investeringen vooraf in complexe pijplijnen.

Gegevens

1. Een representatieve subset van gegevens identificeren
   • Selecteer voor gestructureerde gegevensde belangrijkste tabellen of kolommen die het meest relevant zijn voor uw eerste scenario.
   • Geef voor ongestructureerde gegevensprioriteit aan het indexeren van slechts een subset van representatieve documenten. Gebruik een eenvoudige segmenterings-/insluitpijplijn met Mozaïek AI Vector Search- zodat uw agent indien nodig relevante tekstsegmenten kan ophalen.
2. Gegevenstoegang instellen
   • Als u uw app nodig hebt om externe API-aanroepen uit te voeren, slaat u referenties veilig op met behulp van een Unity Catalog Connection.
3. basisdekking valideren
   • Controleer of de gekozen gegevenssubset(s) de gebruikersquery's die u wilt testen, adequaat beantwoordt.
   • Sla eventuele aanvullende gegevensbronnen of complexe transformaties op voor toekomstige iteraties. Uw huidige doel moet de basiswerkbaarheid bewijzen en feedback verzamelen.

Gereedschap

Wanneer uw gegevensbronnen zijn ingesteld, is de volgende stap het implementeren en registreren van de hulpprogramma's die uw agent tijdens runtime aanroept naar Unity Catalog. Een hulpprogramma is een functie voor één interactie, zoals een SQL-query of externe API-aanroep, die de agent kan aanroepen voor ophalen, transformeren of actie.

hulpprogramma's voor het ophalen van gegevens

• beperkte, gestructureerde gegevensquery's: Als query's zijn opgelost, verpakt u deze in een Unity Catalog SQL-functie of een Python UDF-. Dit houdt logica gecentraliseerd en detecteerbaar.
• Open-einde gestructureerde gegevensquery's: Als query's meer open van aard zijn, kunt u een Genie-ruimte instellen om tekst-naar-SQL-query's te verwerken.
• Niet-gestructureerde helperfuncties voor gegevens: Voor ongestructureerde gegevens die zijn opgeslagen in Mozaïek AI Vector Search, een hulpprogramma voor het ophalen van ongestructureerde gegevens maken die de agent kan aanroepen om relevante tekstsegmenten op te halen.

hulpmiddelen voor API-aanroepen

• externe API-aanroepen:API-aanroepen kunnen rechtstreeks worden aangeroepen met behulp van de http_request methode van de Databricks SDK.
• Optionele wrappers: Als u pre- of postverwerkingslogica (zoals gegevensnormalisatie of foutafhandeling) wilt implementeren, verpakt u de API-aanroep in een Unity Catalog-functie.

Houd deze minimaal

• begin alleen met essentiële hulpprogramma's: focus op één ophaalpad of een beperkte set API-aanroepen. U kunt meer toevoegen tijdens het herhalen.
• Interactief valideren: Test elk hulpprogramma onafhankelijk (bijvoorbeeld in een notebook) voordat u het in het agentsysteem opgeeft.

Nadat uw prototype tools klaar zijn, kunt u verdergaan met het bouwen van de agent. De agent organiseert deze hulpprogramma's om query's te beantwoorden, gegevens op te halen en zo nodig acties uit te voeren.

b. Buildagent

Nadat uw gegevens en hulpprogramma's zijn ingesteld, kunt u de agent bouwen die reageert op binnenkomende aanvragen, zoals gebruikersquery's. Als u een eerste prototypeagent wilt maken, gebruikt u Python of AI-speeltuin. Volg deze stappen:

1. Start eenvoudig
   • Kies een basisontwerppatroon: Voor een POC begint u met een basisketen (zoals een vaste reeks stappen) of een agent voor het aanroepen van één hulpprogramma (waarbij de LLM dynamisch een of twee essentiële hulpprogramma's kan aanroepen).
     • Als uw scenario overeenkomt met een van de voorbeeldnotebooks in de Databricks-documentatie, past u die code aan als een skelet.
   • Minimale prompt: verzet zich tegen de drang om prompts van de technicus op dit moment te over-engineeren. Houd de instructies beknopt en rechtstreeks relevant voor uw initiële taken.
2. Hulpprogramma's opnemen
   • Hulpprogramma-integratie: Als u een ketenontwerppatroon gebruikt, worden de stappen voor het aanroepen van elk hulpprogramma vastgelegd. In een agent voor het aanroepen van hulpprogramma's u een schema zodat de LLM weet hoe de functie moet worden aangeroepen.
     • Controleer of hulpprogramma's in isolatie naar verwachting worden uitgevoerd, voordat u ze in het agentsysteem integreert en een end-to-end test uitvoert.
   • Veiligheidsmaatregelen: Als uw agent externe systemen kan wijzigen of code kan uitvoeren, moet u basisveiligheidscontroles en veiligheidsmaatregelen hebben (zoals beperkingen op het aantal oproepen of het beperken van bepaalde acties). Implementeer deze binnen een Unity Catalog-functie.
3. de agent traceren en vastleggen met MLflow
   • Elke stap traceren: Gebruik MLflow Tracing om invoer, uitvoer en verstreken tijd per stap vast te leggen om problemen op te sporen en prestaties te meten.
   • De agent registreren: Gebruik MLflow Tracking- om de code en configuratie van de agent te registreren.

In dit stadium is perfectie niet het doel. U wilt een eenvoudige, werkende agent die u kunt implementeren voor vroege feedback van testgebruikers en KMO's. De volgende stap is het uitvoeren van een snelle kwaliteitscontrole voordat u deze beschikbaar maakt in een preproductieomgeving.

c. Kwaliteitscontrole

Voordat u de agent beschikbaar maakt voor een breder preproductiepubliek, voert u een offline 'goed genoeg' kwaliteitscontrole uit om belangrijke problemen op te sporen voordat u deze implementeert op een eindpunt. In deze fase beschikt u doorgaans niet over een grote, robuuste evaluatiegegevensset, maar u kunt nog steeds een snelle pass uitvoeren om ervoor te zorgen dat de agent zich gedraagt zoals bedoeld voor een handvol voorbeeldquery's.

1. interactief testen in een notebook
   • Handmatig testen: uw agent handmatig aanroepen met representatieve aanvragen. Let op of hiermee de juiste gegevens worden opgehaald, hulpprogramma's correct worden aanroepen en de gewenste indeling wordt gevolgd.
   • MLflow-traceringen controleren: Als u MLflow Tracing hebt ingeschakeld, controleert u de stapsgewijze telemetrie. Controleer of de agent de juiste tool(s) kiest, fouten correct verwerkt en geen onverwachte tussenliggende aanvragen of resultaten genereert.
   • Latentie controleren: Let op hoe lang het duurt voordat elke aanvraag wordt uitgevoerd. Als reactietijden of tokengebruik te hoog zijn, moet u mogelijk stappen verwijderen of logica vereenvoudigen voordat u verdergaat.
2. Vibe-controle
   • U kunt dit doen in een notitieblok of in AI Playground.
   • Coherentie & juistheid: Is de uitvoer van de agent zinvol voor de query's die u hebt getest? Zijn er onnauwkeurigheden of ontbrekende details?
   • Randgevallen: Als u een paar onorthodoxe vragen hebt geprobeerd, reageert de agent dan nog steeds logisch of valt hij op zijn minst fatsoenlijk uit (bijvoorbeeld door beleefd te weigeren te antwoorden in plaats van onzinnige uitvoer te produceren)?
   • Prompt-naleving: Als u instructies op hoog niveau hebt opgegeven, zoals gewenste toon of opmaak, volgt de agent deze?
3. "goed genoeg" kwaliteit beoordelen
   • Als u op dit moment beperkt bent voor testquery's, kunt u synthetische gegevens genereren. Zie Een evaluatieset maken.
   • Belangrijke problemen oplossen: Als u grote fouten ontdekt (de agent roept bijvoorbeeld herhaaldelijk ongeldige hulpprogramma's aan of levert onzin op), lost u deze problemen op voordat u ze beschikbaar maakt voor een breder publiek. Zie Veelvoorkomende kwaliteitsproblemen en hoe u dezekunt oplossen.
   • Beslissen over de levensvatbaarheid: Als de agent voldoet aan een basisniveau van bruikbaarheid en correctheid voor een kleine set queries, kunt u doorgaan. Als dat niet het probleem is, verfijnt u de prompts, lost u problemen met hulpprogramma's of gegevens op en test u opnieuw.
4. volgende stappen plannen
   • Verbeteringen bijhouden: Documenteer eventuele tekortkomingen die u wilt uitstellen. Nadat u echte feedback hebt verzameld in preproductie, kunt u deze opnieuw bekijken.

Als alles geschikt is voor een beperkte uitrol, kunt u de agent implementeren in de preproductieomgeving. Een grondig evaluatieproces vindt plaats in latere fasen, met name nadat u meer echte gegevens, feedback van het MKB en een gestructureerde evaluatieset hebt. Op dit moment kunt u zich richten op het betrouwbaar laten zien van de kernfunctionaliteit van uw agent.

d. Preproductieagent implementeren

Nadat uw agent voldoet aan een drempelwaarde voor de kwaliteit van de basislijn, is de volgende stap het hosten ervan in een preproductieomgeving, zodat u begrijpt hoe gebruikers query's uitvoeren op de app en hun feedback verzamelen om de ontwikkeling te begeleiden. Deze omgeving kan uw ontwikkelomgeving zijn tijdens de POC-fase. De belangrijkste vereiste is dat de omgeving toegankelijk is om interne testers of domeinexperts te selecteren.

1. De agent implementeren
   • Agent loggen en registreren: Eerst de agent loggen als een MLflow-model en deze registreren in Unity Catalog.
   • Implementeren met behulp van Agent Framework: Gebruik Agent Framework om de geregistreerde agent te nemen en deze te implementeren als een Model Serving-eindpunt.
2. inferentietabellen
   • Agent Framework slaat aanvragen, antwoorden en traceringen automatisch op samen met metagegevens in een deductietabel in Unity Catalog voor elk dienend eindpunt.
3. beveiligen en configureren
   • toegangsbeheer:Eindpunttoegang beperken tot uw testgroep (MKB, energiegebruikers). Dit zorgt voor gecontroleerd gebruik en voorkomt onverwachte blootstelling van gegevens.
   • verificatie: bevestig dat vereiste geheimen, API-tokens of databaseverbindingen correct zijn geconfigureerd.

U hebt nu een gecontroleerde omgeving voor het verzamelen van feedback over echte query's. Een van de manieren waarop u snel met de agent kunt communiceren, bevindt zich in AI Playground-, waar u het zojuist gemaakte eindpunt voor modelservering kunt selecteren en de agent kunt opvragen.

e. Feedback van gebruikers verzamelen

Nadat u uw agent hebt geïmplementeerd in een preproductieomgeving, is de volgende stap het verzamelen van feedback van echte gebruikers en KMO's om hiaten te ontdekken, onnauwkeurigheden te herkennen en uw agent verder te verfijnen.

1. Gebruik de Review-app

   • Wanneer u uw agent implementeert met Agent Framework, wordt er een eenvoudige chatstijl gemaakt App controleren. Het biedt een gebruiksvriendelijke interface waar testers vragen kunnen stellen en onmiddellijk de reacties van de agent kunnen beoordelen.
   • Alle aanvragen, antwoorden en gebruikersfeedback (duim omhoog/omlaag, geschreven opmerkingen) worden automatisch geregistreerd bij een deductietabel, waardoor het later gemakkelijk te analyseren is.

2. De bewakingsinterface gebruiken om logboeken te controleren

   • Houd bij hoeveel upvotes/downvotes of tekstuele feedback er zijn in de Monitoring UI om te zien welke antwoorden testers erg nuttig (of juist niet nuttig) vonden.

3. domeinexperts betrekken

   • Moedig kmo's aan om typische en ongebruikelijke scenario's uit te voeren. Domeinkennis helpt subtiele fouten weer te geven, zoals onjuiste interpretaties van beleid of ontbrekende gegevens.
   • Houd een lijst bij met problemen, variërend van kleine aanpassingen van prompts tot grotere herstructureringen van gegevenspijplijnen. Bepaal welke oplossingen prioriteit moeten krijgen voordat u verdergaat.

4. nieuwe evaluatiegegevens cureren

   • Converteer belangrijke of problematische interacties naar testcases. In de loop van de tijd vormen deze de basis van een krachtigere evaluatiegegevensset.
   • Voeg indien mogelijk juiste of verwachte antwoorden toe aan deze gevallen. Dit helpt bij het meten van de kwaliteit in volgende evaluatiecycli.

5. herhalen op basis van feedback

   • Pas snelle oplossingen toe, zoals kleine promptwijzigingen of nieuwe kaders om onmiddellijke pijnpunten aan te pakken.
   • Voor complexere problemen, zoals het vereisen van geavanceerde logica voor meerdere stappen of nieuwe gegevensbronnen, verzamelt u voldoende bewijs voordat u investeert in belangrijke architectuurwijzigingen.

Door gebruik te maken van feedback uit de beoordelings-app, deductietabellogboeken en SME-inzichten, helpt deze preproductiefase belangrijke hiaten aan de oppervlakte te brengen en uw agent iteratief te verfijnen. De interacties in de praktijk die in deze stap zijn verzameld, vormen de basis voor het bouwen van een gestructureerde evaluatieset, zodat u kunt overstappen van ad-hocverbeteringen tot een systematischere benadering van kwaliteitsmeting. Nadat terugkerende problemen zijn opgelost en de prestaties zijn gestabiliseerd, bent u goed voorbereid op een productie-implementatie met robuuste evaluatie.

2. Evalueer & itereren

Nadat uw gen AI-app is getest in een preproductieomgeving, is de volgende stap het systematisch meten, diagnosticeren en verfijnen van de kwaliteit ervan. Deze fase 'evalueren en herhalen' transformeert onbewerkte feedback en logboeken in een gestructureerde evaluatieset, zodat u herhaaldelijk verbeteringen kunt testen en ervoor kunt zorgen dat uw app voldoet aan de vereiste normen voor nauwkeurigheid, relevantie en veiligheid.

Deze fase omvat de volgende stappen:

• Echte query's verzamelen uit logboeken: interacties met hoge waarde of problematische interacties van uw deductietabellen converteren naar testcases.
• Voeg deskundige labels toe: voeg waar mogelijk grondwaarheden of stijl- en beleidsrichtlijnen toe aan deze gevallen, zodat u de juistheid, aardheid en andere kwaliteitsdimensies objectief kunt meten.
• gebruikmaken van agentevaluatie: Ingebouwde LLM-rechters of aangepaste controles gebruiken om de kwaliteit van de app te kwantificeren.
• Herhalen: De kwaliteit verbeteren door de logica, gegevenspijplijnen of prompts van uw agent te verfijnen. Voer de evaluatie opnieuw uit om te controleren of u belangrijke problemen hebt opgelost.

Houd er rekening mee dat deze mogelijkheden werken, zelfs als uw gen AI-app buiten Databrickswordt uitgevoerd. Door uw code te instrumenteren met MLflow Tracing, kunt u traceringen uit elke omgeving vastleggen en samenvoegen in het Databricks Data Intelligence Platform voor consistente evaluatie en bewaking. Wanneer u nieuwe query's, feedback en SME-inzichten blijft opnemen, wordt uw evaluatiegegevensset een levende resource die een continue verbeteringscyclus onderbouwt, zodat uw gen AI-app robuust, betrouwbaar blijft en is afgestemd op bedrijfsdoelen.

a. Agent evalueren

Nadat uw agent draait in een pre-productieomgeving, is de volgende stap het systematisch evalueren van de prestaties in plaats van ad-hoc vibecontroles. Met Mosaic AI Agent Evaluation kunt u evaluatiesets maken, kwaliteitscontroles uitvoeren met ingebouwde of aangepaste LLM-evaluators en snel verbeteringen aanbrengen op probleemgebieden.

Offline en online evaluaties

Bij het evalueren van GEN AI-toepassingen zijn er twee primaire benaderingen: offline evaluatie en online evaluatie. Deze fase van de ontwikkelingscyclus richt zich op offline evaluatie, die verwijst naar systematische evaluatie buiten live gebruikersinteracties. Online evaluatie wordt later besproken wanneer u de bewaking van uw agent in productie bespreekt.

Teams zijn vaak te veel afhankelijk van 'vibe testing' gedurende te lange tijd in de ontwikkelaarsworkflow, door informeel een aantal queries uit te proberen en vervolgens subjectief beoordelen of de reacties redelijk lijken. Hoewel dit een uitgangspunt biedt, ontbreekt het aan de striktheid en dekking die nodig is om toepassingen van productiekwaliteit te bouwen.

Een correct offline evaluatieproces doet daarentegen het volgende:

• stelt een kwaliteitsbasislijn vast vóór een bredere implementatie, waardoor duidelijke metriek wordt gecreëerd om te verbeteren.
• Identificeert specifieke zwakke punten waarvoor aandacht is vereist, waarbij de beperking van het testen alleen verwachte gebruiksscenario's overschrijdt.
• Detecteert kwaliteitsregressies tijdens het verfijnen van uw app door de prestaties automatisch te vergelijken met verschillende versies.
• Biedt kwantitatieve metrische gegevens om de verbetering voor belanghebbenden te demonstreren.
• Helpt edge-zaken te detecteren en mogelijke foutmodi voordat gebruikers dat doen.
• Vermindert het risico van het implementeren van een onderpresterende agent in productie.

Investeren in tijd in offline evaluatie betaalt aanzienlijke dividenden in de lange termijn, waardoor u kunt streven naar consistente antwoorden van hoge kwaliteit.

Een evaluatieset maken

Een evaluatieset fungeert als de basis voor het meten van de prestaties van uw gen AI-app. Net als bij een testpakket in traditionele softwareontwikkeling wordt deze verzameling representatieve query's en verwachte antwoorden uw kwaliteitsbenchmark en regressietestgegevensset.

U kunt een evaluatieset bouwen via verschillende complementaire benaderingen:

1. Deductietabellogboeken transformeren in evaluatievoorbeelden

   De meest waardevolle evaluatiegegevens zijn rechtstreeks afkomstig van echt gebruik. Uw preproductie-implementatie heeft deductietabellogboeken gegenereerd met aanvragen, agentantwoorden, hulpprogramma-aanroepen en opgehaalde context.

   Het converteren van deze logboeken naar een evaluatieset biedt verschillende voordelen:

   • Dekbaarheid in de echte wereld: Onvoorspelbaar gebruikersgedrag dat u mogelijk niet had verwacht, is opgenomen.
   • probleemgericht: U kunt specifiek filteren op negatieve feedback of trage reacties.
   • Representatieve distributie: De werkelijke frequentie van verschillende querytypen wordt vastgelegd.

2. synthetische evaluatiegegevens genereren

   Als u geen samengestelde set gebruikersquery's hebt, kunt u automatisch een synthetische evaluatiegegevensset genereren. Met deze 'startersset' van query's kunt u snel beoordelen of de agent:

   • Retourneert coherente, nauwkeurige antwoorden.
   • Reageert in de juiste indeling.
   • Respecteert structuur, tonaliteit en beleidsrichtlijnen.
   • Hiermee wordt context (voor RAG) correct opgehaald.

   Synthetische gegevens zijn doorgaans niet perfect. Beschouw het als een tijdelijke stapsteen. U wilt ook het volgende doen:

   • Laat kmo's of domeinexperts eventuele irrelevante of terugkerende query's bekijken en verwijderen.
   • Vervang of vul deze later aan met gebruikslogboeken uit de echte wereld.

3. Query's handmatig samenstellen

   Als u liever niet vertrouwt op synthetische gegevens of nog geen deductielogboeken hebt, identificeert u 10 tot 15 echte of representatieve query's en maakt u hiervan een evaluatieset. Representatieve zoekopdrachten kunnen afkomstig zijn van gebruikersinterviews of brainstormsessies van ontwikkelaars. Zelfs een korte, gecureerde lijst kan opvallende fouten blootleggen in de reacties van uw agent.

Deze benaderingen sluiten elkaar niet wederzijds uit, maar vullen elkaar aan. Een effectieve evaluatieset ontwikkelt zich in de loop van de tijd en combineert doorgaans voorbeelden uit meerdere bronnen, waaronder de volgende:

• Begin met handmatig samengestelde voorbeelden om de kernfunctionaliteit te testen.
• Voeg eventueel synthetische gegevens toe om de dekking uit te breiden voordat u echte gebruikersgegevens hebt.
• Neem geleidelijk logboeken in de praktijk op zodra ze beschikbaar komen.
• Voortdurend vernieuwen met nieuwe voorbeelden die veranderende gebruikspatronen weerspiegelen.

Beste praktijken voor evaluatievragen

Bij het maken van uw evaluatieset moet u opzettelijk diverse querytypen opnemen, zoals de volgende:

• Zowel verwachte als onverwachte gebruikspatronen (zoals zeer lange of korte aanvragen).
• Mogelijke misbruikpogingen of prompt-injectie aanvallen (zoals pogingen om de systeemprompt weer te geven).
• Complexe query's waarvoor meerdere redeneringsstappen of hulpprogramma-aanroepen zijn vereist.
• Randegevallen met minimale of dubbelzinnige informatie (zoals spelfouten of vage zoekopdrachten).
• Voorbeelden van verschillende niveaus en achtergronden van gebruikersvaardigheden.
• Query's die testen op mogelijke vooroordelen in antwoorden (zoals 'Bedrijf A vergelijken versus Bedrijf B').

Houd er rekening mee dat uw evaluatieset moet groeien en zich moet ontwikkelen naast uw toepassing. Wanneer u nieuwe foutmodi of gebruikersgedrag ontdekt, voegt u representatieve voorbeelden toe om ervoor te zorgen dat uw agent op deze gebieden blijft verbeteren.

Evaluatiecriteria toevoegen

Elk evaluatievoorbeeld moet criteria hebben om de kwaliteit te beoordelen. Deze criteria dienen als de standaarden waarmee de reacties van de agent worden gemeten, waardoor objectieve evaluatie mogelijk is voor meerdere kwaliteitsdimensies.

Referentiegegevens of referentieantwoorden

Bij het evalueren van de feitelijke nauwkeurigheid zijn er twee belangrijke benaderingen: verwachte feiten of referentieantwoorden. Elk dient een ander doel in uw evaluatiestrategie.

Verwachte feiten (aanbevolen) gebruiken

De expected_facts aanpak omvat het vermelden van de belangrijkste feiten die in een correct antwoord moeten worden weergegeven. Zie bijvoorbeeld voorbeeldevaluatieset met request, response, guidelinesen expected_facts.

Deze aanpak biedt aanzienlijke voordelen:

• Biedt flexibiliteit in de manier waarop de feiten worden uitgedrukt in het antwoord.
• Maakt het voor mkb's gemakkelijker om referentiewaarden te bieden.
• Geschikt voor verschillende antwoordstijlen, terwijl u ervoor zorgt dat er kerninformatie aanwezig is.
• Maakt een betrouwbaardere evaluatie mogelijk voor modelversies of parameterinstellingen.

De ingebouwde juistheidsrechter controleert of het antwoord van de agent deze essentiële feiten bevat, ongeacht formulering, volgorde of aanvullende inhoud.

Verwacht antwoord (alternatief) gebruiken

U kunt ook een volledig referentieantwoordopgeven. Deze aanpak werkt het beste in de volgende situaties:

• U hebt goudstandaard antwoorden gemaakt door experts.
• De exacte formulering of structuur van het antwoord is van belang.
• U evalueert antwoorden in sterk gereglementeerde contexten.

Databricks raadt over het algemeen aan om expected_facts te gebruiken ten opzichte van expected_response, omdat het meer flexibiliteit biedt en tegelijkertijd de nauwkeurigheid blijft garanderen.

Richtlijnen voor stijl-, toon- of beleidsnaleving

Naast feitelijke nauwkeurigheid moet u mogelijk evalueren of antwoorden voldoen aan specifieke stijl- en toonvereisten of beleidsvereisten.

Alleen richtlijnen

Als uw primaire zorg stijl- of beleidsvereisten afdwingt in plaats van feitelijke nauwkeurigheid, kunt u richtlijnen verstrekken zonder verwachte feiten:

# Per-query guidelines
eval_row = {
    "request": "How do I delete my account?",
    "guidelines": {
        "tone": ["The response must be supportive and non-judgmental"],
        "structure": ["Present steps chronologically", "Use numbered lists"]
    }
}

# Global guidelines (applied to all examples)
evaluator_config = {
    "databricks-agent": {
        "global_guidelines": {
            "rudeness": ["The response must not be rude."],
            "no_pii": ["The response must not include any PII information (personally identifiable information)."]
        }
    }
}

De richtlijnen worden door de LLM-rechter geïnterpreteerd, die deze instructies voor natuurlijke taal beoordeelt en vaststelt of het antwoord eraan voldoet. Dit werkt met name goed voor subjectieve kwaliteitsdimensies, zoals toon, opmaak en naleving van het organisatiebeleid.

Het combineren van werkelijkheid en richtlijnen

Voor uitgebreide evaluatie kunt u feitelijke nauwkeurigheidscontroles combineren met stijlrichtlijnen. Zie voorbeeldevaluatieset met request, response, guidelinesen expected_facts. Deze aanpak zorgt ervoor dat reacties zowel feitelijk nauwkeurig zijn als voldoen aan de communicatiestandaarden van uw organisatie.

Vooraf vastgelegde antwoorden gebruiken

Als u al aanvraagresponsparen hebt vastgelegd van ontwikkeling of testen, kunt u deze rechtstreeks evalueren zonder uw agent opnieuw in te schakelen. Dit is handig voor:

• Bestaande patronen analyseren in het gedrag van uw agent.
• Het vergelijken van prestaties met eerdere versies.
• Bespaar tijd en kosten door reacties niet opnieuw te genereren.
• Het evalueren van een agent die buiten Databricks functioneert.

Zie Voorbeeld: Hoe u eerder gegenereerde uitvoer doorgeeft aan agentevaluatie-voor meer informatie over het verstrekken van de relevante kolommen in uw evaluatiedataframe. Mosaic AI Agent Evaluation maakt gebruik van deze vooraf vastgelegde waarden in plaats van uw agent opnieuw aan te roepen, terwijl dezelfde kwaliteitscontroles en metrische gegevens nog steeds worden toegepast.

Aanbevolen procedures voor evaluatiecriteria

Bij het definiëren van uw evaluatiecriteria:

1. Specifiek en objectief zijn: Duidelijke, meetbare criteria definiëren die verschillende evaluators op dezelfde manier zouden interpreteren.
   • Overweeg aangepaste metrische gegevens toe te voegen om de kwaliteitscriteria te meten die u belangrijk vindt.
2. focus op gebruikerswaarde: Criteria prioriteren die overeenkomen met wat voor uw gebruikers het belangrijkst is.
3. Eenvoudig beginnen: Begin met een kernset criteria en breid uit naarmate uw begrip van kwaliteitsbehoeften groeit.
4. Balansdekking: Criteria opnemen die verschillende aspecten van kwaliteit aanpakken (bijvoorbeeld feitelijke nauwkeurigheid, stijl en veiligheid).
5. Herhalen op basis van feedback: Verfijn uw criteria op basis van feedback van gebruikers en veranderende vereisten.

Zie Aanbevolen procedures voor het ontwikkelen van een evaluatieset voor meer informatie over het bouwen van gegevenssets voor evaluatie van hoge kwaliteit.

Evaluaties uitvoeren

Nu u een evaluatieset hebt voorbereid met query's en criteria, kunt u een evaluatie uitvoeren met behulp van mlflow.evaluate(). Deze functie verwerkt het hele evaluatieproces, van het aanroepen van uw agent tot het analyseren van de resultaten.

Basiswerkstroom voor evaluatie

Voor het uitvoeren van een basisevaluatie zijn slechts enkele regels code vereist. Zie voor details Voer een evaluatie uit.

Wanneer de evaluatie wordt geactiveerd:

1. Voor elke rij in uw evaluatieset doet mlflow.evaluate() het volgende:
   • Roept uw agent aan met de query (als u nog geen antwoord hebt opgegeven).
   • Past ingebouwde LLM-juryleden toe om kwaliteitsdimensies te beoordelen.
   • Berekent operationele metrische gegevens, zoals tokengebruik en latentie.
   • Registreert gedetailleerde rationales voor elke evaluatie.
2. Resultaten worden automatisch geregistreerd bij MLflow, waardoor het volgende wordt gemaakt:
   • Kwaliteitsevaluaties per rij.
   • Geaggregeerde metrische gegevens in alle voorbeelden.
   • Gedetailleerde logboeken voor foutopsporing en analyse.

Evaluatie aanpassen

U kunt de evaluatie aanpassen aan uw specifieke behoeften met behulp van aanvullende parameters. Met de parameter evaluator_config kunt u het volgende doen:

• Selecteer de ingebouwde rechters om uit te voeren.
• Globale richtlijnen instellen die van toepassing zijn op alle voorbeelden.
• Configureer drempelwaarden voor rechters.
• Geef enkele voorbeelden om de beoordelingen te begeleiden.

Zie Voorbeeldenvoor meer informatie en voorbeelden.

Agents evalueren buiten Databricks

Een krachtige functie van agentevaluatie is de mogelijkheid om gen AI-apps te evalueren die overal zijn geïmplementeerd, niet alleen op Databricks.

Welke rechters worden aangesteld?

Standaard agentevaluatie automatisch de juiste LLM-rechters selecteert op basis van de gegevens die beschikbaar zijn in uw evaluatieset. Zie Hoe kwaliteit wordt beoordeeld door LLM-rechtersvoor meer informatie over hoe kwaliteit wordt beoordeeld.

Evaluatieresultaten analyseren

Nadat u een evaluatie hebt uitgevoerd, biedt de MLflow-gebruikersinterface visualisaties en inzichten om inzicht te krijgen in de prestaties van uw app. Met deze analyse kunt u patronen identificeren, problemen diagnosticeren en verbeteringen prioriteren.

Navigeren door de evaluatieresultaten

Wanneer u de MLflow-gebruikersinterface opent nadat u mlflow.evaluate(), hebt uitgevoerd, vindt u verschillende onderling verbonden weergaven. Zie Uitvoer controleren met behulp van de MLflow-gebruikersinterfacevoor informatie over het navigeren in deze resultaten in de MLflow-gebruikersinterface.

Zie b voor hulp bij het interpreteren van foutpatronen. Verbeter agent en hulpprogramma's.

Aangepaste AI beoordeelt & metrische gegevens

Hoewel ingebouwde rechters veel algemene controles behandelen (zoals juistheid, stijl, beleid en veiligheid), moet u mogelijk domeinspecifieke aspecten van de prestaties van uw app evalueren. Met aangepaste rechters en metrische gegevens kunt u de evaluatiemogelijkheden uitbreiden om te voldoen aan uw unieke kwaliteitsvereisten.

Aangepaste LLM beoordeelt

Zie AI-rechters maken op basis van een prompt voor meer informatie over het maken van een aangepaste LLM-rechter op basis van een prompt.

Aangepaste rechters excelleren bij het evalueren van subjectieve of genuanceerde kwaliteitsdimensies die baat hebben bij menselijke beoordeling, zoals:

• Domeinspecifieke naleving (juridisch, medisch, financieel).
• Merkstem- en communicatiestijl.
• Culturele gevoeligheid en geschiktheid.
• Complexe redeneringskwaliteit.
• Gespecialiseerde schrijfconventies.

De uitvoer van de rechter wordt weergegeven in de MLflow-gebruikersinterface naast ingebouwde rechters, met dezelfde gedetailleerde logica waarin beoordelingen worden uitgelegd.

aangepaste meetwaarden

Voor meer programmatische, deterministische evaluaties kunt u aangepaste metrische gegevens maken met behulp van de @metric decorator. Zie @metric decorator.

Aangepaste metrische gegevens zijn ideaal voor:

• Technische vereisten controleren, zoals indelingsvalidatie en schemacompatibiliteit.
• Controleren op aanwezigheid of afwezigheid van specifieke inhoud.
• Kwantitatieve metingen uitvoeren, zoals antwoordlengte of complexiteitsscores.
• Het implementeren van bedrijfsspecifieke validatieregels.
• Integreren met externe validatiesystemen.

b. Agenten en hulpmiddelen verbeteren

Na het uitvoeren van evaluatie en het identificeren van kwaliteitsproblemen is de volgende stap het systematisch oplossen van deze problemen om de prestaties te verbeteren. De evaluatieresultaten bieden waardevolle inzichten in waar en hoe uw agent mislukt, zodat u gerichte verbeteringen kunt aanbrengen in plaats van willekeurige aanpassingen.

Veelvoorkomende kwaliteitsproblemen en hoe u deze kunt oplossen

De beoordelingen van de LLM-jury wijzen op specifieke soorten fouten in uw agentsysteem. In deze sectie worden deze veelvoorkomende foutpatronen en de bijbehorende oplossingen besproken. Zie AI-rechteruitvoervoor meer informatie over het interpreteren van uitvoer van LLM-rechters.

Best practices voor kwaliteitsiteratie

Terwijl u verbeteringen doorgeeft, onderhoudt u strenge documentatie. Bijvoorbeeld:

1. Versieer uw wijzigingen
   • Registreer elke belangrijke iteratie met MLflow Tracking.
   • Sla prompts, configuraties en sleutelparameters op in een centraal configuratiebestand. Zorg ervoor dat dit genoteerd is bij de agent.
   • Houd voor elke nieuwe agent een wijzigingenlogboek bij in uw repository waarin wordt beschreven wat er is gewijzigd en waarom.
2. documenteer zowel wat werkte als wat niet werkte
   • Documenteer zowel geslaagde als mislukte benaderingen.
   • Let op de specifieke impact van elke wijziging op metrische gegevens. Koppel terug naar de Agent Evaluation MLflow-run.
3. Afstemmen op belanghebbenden
   • Gebruik de beoordelings-app om verbeteringen met kmo's te valideren.
     • Communiceer wijzigingen aan revisoren met behulp van revisorinstructies.
   • Voor een vergelijking naast elkaar van verschillende versies van een agent kunt u meerdere agenteindpunten maken en het model gebruiken in AI Playground. Hierdoor kunnen gebruikers dezelfde aanvraag naar afzonderlijke eindpunten verzenden en het antwoord en de tracering naast elkaar onderzoeken.

3. Productie

Nadat u uw app iteratief hebt geëvalueerd en verbeterd, hebt u een kwaliteitsniveau bereikt dat voldoet aan uw vereisten en klaar is voor breder gebruik. De productiefase omvat het implementeren van uw verfijnde agent in uw productieomgeving en het implementeren van continue bewaking om de kwaliteit in de loop van de tijd te behouden.

De productiefase omvat:

• Agent implementeren in productie: een eindpunt instellen dat gereed is voor productie met de juiste beveiligings-, schaal- en verificatie-instellingen.
• Agent in productie bewaken: continue kwaliteitsevaluatie, prestatietracering en waarschuwingen instellen om ervoor te zorgen dat uw agent in de praktijk een hoge kwaliteit en betrouwbaarheid behoudt.

Hiermee maakt u een doorlopende feedbacklus waarin bewakingsinzichten verdere verbeteringen stimuleren, die u kunt testen, implementeren en blijven bewaken. Deze aanpak zorgt ervoor dat uw app in de loop van de levenscyclus van uw app van hoge kwaliteit, compatibel en afgestemd blijft op de veranderende bedrijfsbehoeften.

een. Agent implementeren in productie

Nadat u een grondige evaluatie en iteratieve verbetering hebt voltooid, kunt u uw agent implementeren in een productieomgeving. [Mosaic AI Agent Framework](/generative-ai/agent-framework/build-gen AI-apps.md#agent-framework) vereenvoudigt dit proces door veel uitrolproblemen automatisch af te handelen.

Implementatieproces

Het implementeren van uw agent in productie omvat de volgende stappen:

1. Log en registreer uw agent als een MLflow-model in Unity Catalog.
2. De agent uitrollen met behulp van het Agent Framework.
3. Configureer verificatie voor alle benodigde resources waarvoor uw agent toegang nodig heeft.
4. Test de implementatie om de functionaliteit in de productieomgeving te controleren.
   • Nadat het eindpunt voor het leveren van het model gereed is, kunt u communiceren met de agent in de AI Playground, waar u de functionaliteit kunt testen en verifiëren.

Zie Een agent implementeren voor generatieve AI-toepassingvoor gedetailleerde implementatiestappen.

Overwegingen voor productie-implementatie

Houd bij de overstap naar productie rekening met de volgende belangrijke overwegingen:

prestaties en schaalbaarheid

• Kosten en prestaties verdelen op basis van uw verwachte gebruikspatronen.
• Overweeg om schaal-naar-nul- in te schakelen voor af en toe gebruikte agents om de kosten te verlagen.
• Inzicht in latentievereisten op basis van de gebruikerservaringsbehoeften van uw toepassing.

Beveiliging en governance

• Zorg voor de juiste toegangsbeheer op het niveau van de Unity-catalogus voor alle agentonderdelen.
• Gebruik waar mogelijk de ingebouwde verificatiepassthrough- voor Databricks-resources.
• Configureer het juiste referentiebeheer voor externe API's of gegevensbronnen.

integratiebenadering

• Bepaal hoe uw toepassing communiceert met de agent (bijvoorbeeld met behulp van een API of een ingesloten interface).
• Overweeg hoe u reacties van agents in uw toepassing kunt verwerken en weergeven.
  • Als uw clienttoepassing aanvullende context nodig heeft (zoals brondocumentverwijzingen of betrouwbaarheidsscores), ontwerpt u de agent om deze metagegevens op te nemen in de antwoorden (bijvoorbeeld met behulp van aangepaste uitvoer).
• Plan voor foutafhandeling en terugvalmechanismen voor wanneer de agent niet beschikbaar is.

Feedback verzameling

• Gebruik de beoordelings-app voor feedback van belanghebbenden tijdens de eerste implementatie.
• Ontwerpmechanismen om gebruikersfeedback rechtstreeks in uw toepassingsinterface te verzamelen.
  • Het feedback-eindpunt dat is gemaakt om feedback van de beoordelings-app te verzamelen, kan ook worden gebruikt door externe toepassingen om feedback te geven over uw agent. Zie Geef feedback over een uitgerolde agent.
• Zorg ervoor dat feedbackgegevens in uw evaluatie- en verbeteringsproces stromen.

b. Bewaken van de agent in productie

Nadat uw agent is geïmplementeerd in de productieomgeving, is het essentieel om continu de prestaties, kwaliteit en gebruikspatronen te bewaken. In tegenstelling tot traditionele software waarbij functionaliteit deterministisch is, kunnen gen AI-apps kwaliteitsdrift of onverwacht gedrag vertonen wanneer ze echte invoer tegenkomen. Met effectieve bewaking kunt u problemen vroegtijdig detecteren, gebruikspatronen begrijpen en de kwaliteit van uw toepassing continu verbeteren.

Agentbewaking instellen

Mozaïek AI biedt ingebouwde bewakingsmogelijkheden waarmee u de prestaties van uw agent kunt bijhouden zonder aangepaste bewakingsinfrastructuur te bouwen:

1. Maak een monitor voor uw geïmplementeerde agent.
2. Samplingfrequentie en frequentie configureren op basis van verkeersvolume en bewakingsbehoeften.
3. Selecteer metrische gegevens over kwaliteit om automatisch te evalueren op voorbeeldaanvragen.

Belangrijke monitoringdimensies

Over het algemeen moet effectieve bewaking betrekking hebben op drie kritieke dimensies:

1. operationele metrische gegevens

   • Aanvraagvolume en patronen.
   • Reactielatentie.
   • Foutpercentages en fouttypen.
   • Tokengebruik en kosten.

2. metrische gegevens over kwaliteit

   • Relevantie voor gebruikersvragen.
   • Geaardheid in opgehaalde context.
   • Veiligheid en richtlijn naleving.
   • Algehele kwaliteitsdoorgangscijfer.

3. feedback van gebruikers

   • Expliciete feedback (duim omhoog/omlaag).
   • Impliciete signalen (vervolgvragen, verlaten gesprekken).
   • Problemen gerapporteerd aan ondersteuningskanalen.

De gebruikersinterface voor bewaking gebruiken

De bewakingsinterface biedt gevisualiseerde inzichten over deze dimensies via twee tabbladen.

• Grafieken tabblad: Trends weergeven in aanvraagvolume, kwaliteitsstatistieken, latentie en fouten over tijd.
• tabblad Logboeken: Afzonderlijke aanvragen en antwoorden onderzoeken, inclusief de evaluatieresultaten.

Met filtermogelijkheden kunnen gebruikers zoeken naar specifieke query's of filteren op evaluatieresultaat. Voor meer informatie, zie Gebruik de monitoringinterface.

Dashboards en waarschuwingen maken

Voor uitgebreide bewaking:

• Aangepaste dashboards maken met behulp van de bewakingsgegevens die zijn opgeslagen in de tabel met geëvalueerde traceringen.
• waarschuwingen instellen voor kritieke kwaliteits- of operationele drempelwaarden.
• Regelmatig kwaliteitsbeoordelingen plannen met belangrijke belanghebbenden.

Cyclus voor continue verbetering

Bewaking is het meest waardevol wanneer deze teruggaat naar uw verbeteringsproces:

1. Problemen identificeren via het bewaken van metrische gegevens en feedback van gebruikers.
2. Problematische voorbeelden exporteren naar uw evaluatieset.
3. Hoofdoorzaken vaststellen met behulp van MLflow-traceringsanalyse en de resultaten beoordelen met LLM (zoals besproken in Veelvoorkomende kwaliteitsproblemen en hoe u dezekunt oplossen).
4. Ontwikkel en test verbeteringen tegen uw uitgebreide evaluatieset.
5. Updates implementeren en de impact controleren.

Deze iteratieve, gesloten-lusbenadering helpt ervoor te zorgen dat uw agent blijft verbeteren op basis van praktijkgebruikspatronen, waarbij hoge kwaliteit wordt gehandhaafd en tegelijkertijd wordt aangepast aan veranderende vereisten en gebruikersgedrag. Met Agent Monitoring krijgt u inzicht in de prestaties van uw agent in productie, zodat u proactief problemen kunt oplossen en kwaliteit en prestaties kunt optimaliseren.