End-to-end productie: verificatie, monitoring en ethiek

Winst:

• Kan de end-to-end-architectuur ontwerpen die een LLM-functie van idee naar productie brengt
• Creëert lagen voor verificatiehandhaving, menselijke goedkeuring en tracking (logboekregistratie/statistieken)
• Grenzen vertalen ethische en privacyprincipes naar productiebeslissingen

In de voorgaande tien eenheden hebben we de onderdelen één voor één geleerd: verzoekstructuur, tokeneconomie, flow, systeemprompt, modelselectie, cache, batch, foutbeheer, veilige sleutel en automatisering. In deze laatste unit combineren we de onderdelen en stellen we de holistische architectuur vast die een LLM-kenmerk van idee tot productie met zich meebrengt. Productie is anders dan een ‘werkdemonstratie’: verificatie is verplicht, de output moet worden gemonitord, grenzen en ethische principes moeten in beslissingen worden verankerd. Deze eenheid is de draagkolom van de module; Alle voorgaande komen hier samen.

Lagen van productiearchitectuur

Een solide LLM-kwalificatie bestaat uit grofweg vijf lagen:

1. Invoerlaag: verzamel gegevens, maak deze schoon, maskeer gevoelige gebieden, verzend alleen wat nodig is.
2. Modellaag: Selecteer het juiste model (eenheid 5), stel de systeemprompt en parameters in (eenheid 4), cache (eenheid 6).
3. Validatielaag: Controleer indien nodig de uitvoer aan de hand van schema/regel, bron en menselijke goedkeuring.
4. Actielaag: actie uitvoeren met gevalideerde uitvoer; Leg acties met een grote impact vast.
5. Monitoringlaag: registreer en meet elk gesprek, de kosten, de fouten en de kwaliteit.

Deze lagen vormen een pijpleiding; elk controleert de uitvoer van de vorige.

Waarom is verificatie vereist?

LLM's kunnen vloeiende maar soms onnauwkeurige uitvoer produceren. Dit wordt hallucinatie genoemd: het model kan informatie verzinnen die waar lijkt, maar dat niet is. In een chatgame is dit acceptabel; kan niet worden getolereerd in een productiesysteem (factuur, gezondheidszorg, juridisch, financieel). Het bleek dus blindelings onbetrouwbaar; wordt bevestigd.

Verificatielagen (toenemend door impact):

• Formaat-/schemavalidatie: voldoet de uitvoer aan het verwachte JSON-schema? (De gestructureerde output garandeert dit grotendeels.)
• Regel-/logische verificatie: zijn de waarden redelijk? (Is het bedrag negatief, ligt de datum in de toekomst, is de categorie geldig?)
• Bronverificatie: Is de claim gebaseerd op de verstrekte documentatie? Zegt het model iets dat niet in het document staat?
• Menselijke goedkeuring: Een expert beoordeelt beslissingen met een grote impact of dubbelzinnige beslissingen.

Let op: "Het model is zo goed dat er geen verdere verificatie nodig is" is de gevaarlijkste productiefout. Hoe goed het model ook is, de verificatielaag vormt een vangnet bij beslissingen met grote impact. Zelfs één verkeerde automatische beslissing kan alle bespaarde tijd wegnemen.

Mens in de lus

Niet elke beslissing hoeft volledig automatisch te zijn. Bij de human-in-the-loop-benadering versnelt het model het werk en keurt de mens het goed. De juiste balans hangt af van de impact van de beslissing en de betrouwbaarheid van het model voor die taak.

Gevolgen van het besluit

Benadering

Laag (labelsuggestie, diepgang)

Volledige automatisering; fout is goedkoop en omkeerbaar

Medium (routing, prioritering)

Automatisering + bemonsteringscontrole

Hoog (geld, contract, gezondheid, verwijdering)

Menselijke toestemming is verplicht; het model suggereert alleen maar

Monitoring: wat u niet ziet, kunt u niet beheren

In de productie moet u elk gesprek monitoren. Zonder monitoring kunt u de kosten en kwaliteit niet verbeteren of een probleem vroegtijdig onderkennen. Belangrijke statistieken om vast te leggen:

• Gebruik/kosten: per aanvraag en totaal aantal tokens, modeldistributie, dagelijkse uitgaven.
• Latency: gemiddelde responstijd en in het slechtste geval.
• Foutpercentage: 429/500 percentages, nieuwe pogingen, stopzettingen.
• Kwaliteit: afgewezen uitvoerpercentage op verificatielaag, correctiepercentage bij menselijke goedkeuring, feedback van gebruikers.

Tip: Schrijf geen gevoelige gegevens (persoonlijke informatie, sleutels) naar monitoringlogboeken. Overweeg logs in het kader van de vertrouwelijkheid; opnemen door indien nodig te maskeren (eenheid 9).

Ethiek en grenzen

Ethische verantwoordelijkheid is net zo goed een onderdeel van de productiebeslissing als technische nauwkeurigheid:

• Transparantie: De gebruiker moet weten of hij met een kunstmatige intelligentie of met een mens praat.
• Eerlijkheid en vooringenomenheid: Het model kan vooringenomenheid vertonen door de gegevens waarop het is getraind; Houd toezicht op discriminerende gevolgen bij beslissingen met grote impact (aanwerving, krediet).
• Aansprakelijkheid: Als een geautomatiseerd besluit schade veroorzaakt, bent u verantwoordelijk; ‘Het model zei het’ is geen verdediging.
• Acceptatie van limieten: Het model kan sommige taken niet betrouwbaar uitvoeren; het niet automatiseren ervan is ook een ontwerpbeslissing.

Kopieerbare sjablonen

# Validatiechecklist (na het genereren van output)1) Is het schema geldig? (gestructureerde outputvalidatie)2) Kloppen de waarden? (regelcontrole: bereik, datum, enum)3) Is de claim gebaseerd op de bron? (afwijzen indien niet in het document)4) Is de impact groot? → stuur om menselijke goedkeuring5) Als alles is geslaagd → actie toestaan, opslaan

# Systeemprompt die dwingt om alleen op sourceRely te vertrouwen op informatie in het verstrekte document. Voeg niets toe dat niet in het document staat. Als informatie niet in het document staat, schrijf dan 'Niet gevonden in het document'. Nooit dingen raden of verzinnen.

# Menselijke goedkeuringsdrempel (beslissingsregel)IF beslissingstype in [geld, contract, verwijderen, gezondheid] → menselijke goedkeuring verplichtIF model_trust < drempel OF validatie "onzeker" → onderwerpen aan menselijke goedkeuringOTHER → automatisch toepassen + steekproefcontrole

# Trace log-sjabloon (gevoelige gegevens schrijven){ "time":...", "model":...", "input_token":..., "output_token":..., "delay_ms":..., "stop_reason":..., "stop_reason"...", "authentication": "passed|rejected|human", "cost_usd":... } // persoonlijke gegevens en sleutel worden NOOIT geschreven

Zwakke prompt/sterke prompt (productiebetrouwbaarheid)

# ZWAK (geen verificatie, geen bron, wordt automatisch toegepast) Evalueer dit verzoek, neem een terugbetalingsbesluit en dien een aanvraag in.

# STERK (brongebaseerd, genereert aanbevelingen, laat het over aan menselijke goedkeuring)Evalueer dit retourverzoek alleen op basis van het retourbeleiddocument. Beveel het besluit aan met motivering, maar voer het niet uit: {"recommendation": goedkeuren|afwijzen", "reason"...", "policy_clause"..."}. Als er geen duidelijke basis in het beleidsdocument staat, geef dan "onduidelijk" op. Een vertegenwoordiger zal het definitieve besluit goedkeuren.

Krachtige versie; Het schrijft de beslissing toe aan de bron, positioneert het model als een ‘suggestor’ in plaats van een ‘doener’, en plaatst de stap met grote impact achter menselijke goedkeuring. Dit is de essentie van productiebetrouwbaarheid.

Drie mini-hoesjes

Geval 1 – De dag waarop de verificatielaag werd opgeslagen. Een fintech liet het model transactiebeschrijvingen classificeren en automatische boekhoudgegevens aanmaken. Ze voegden regelvalidatie toe: zodra het model het bedrag onjuist uitvoerde (12.500 in plaats van 1.250 in het document), verwierp de regel 'bedrag komt niet overeen met het document' de uitvoer en viel het record in handen van de mens. Als er geen verificatie zou plaatsvinden, zou de onjuiste record stilletjes in het systeem terechtkomen.

Casus 2 — Vluchteling betrapt door surveillance. Een SaaS-team had een monitoringpanel opgezet; Op een ochtend verdrievoudigden de dagelijkse kosten. Uit de logboeken bleek dat een client in een lus terechtkwam en duizenden keren hetzelfde verzoek verzond. Ze voegden quota en deduplicatie toe; Het probleem was binnen enkele uren opgelost. Zonder tracking zou de rekening aan het eind van de maand een verrassing zijn.

Geval 3 — De limiet accepteren. Een zorgstartup was van plan om volautomatisch een diagnoseadvies te geven en dit aan de patiënt te laten zien. In een ethiek- en aansprakelijkheidsonderzoek besloten ze dat dit verboden terrein was: het model geeft alleen een samenvatting en mogelijke punten aan een arts, de arts stelt de diagnose. Het niet automatiseren van een taak is ook een volwassen ontwerpbeslissing.

Veel voorkomende fouten

• Validatie overslaan: de uitvoer blindelings toepassen en zeggen: "het model is goed".
• Automatisering van beslissingen met grote impact: menselijke goedkeuring is essentieel op het gebied van geld/gezondheid/recht.
• Geen monitoring: Kosten- en kwaliteitsproblemen worden laat ontdekt.
• Gevoelige gegevens naar logboeken schrijven: schending van de privacy; Bewaar het door het te maskeren.
• Niet proberen te vertrouwen op de bron: het model kan verzinnen wat niet in het document staat.
• Grenzen negeren: Het niet automatiseren van sommige taken is de juiste beslissing; Transparantie en verantwoordelijkheid zijn van jou.

Dieper: Releasebeheer, terugdraaien en incrementele implementatie

Het in productie nemen van een LLM-functie gaat niet over het opzetten en vergeten ervan; is het veilig wijzigen van een live systeem in de loop van de tijd. Het heeft drie pijlers.

Versiebeheer. Uw systeemprompt, modelselectie en verificatieregels veranderen in de loop van de tijd. Versie elke belangrijke wijziging en leg vast welke versie live is. Als de kwaliteit op een dag daalt, "wat hebben we dan veranderd?" Je zou de vraag binnen enkele minuten moeten kunnen beantwoorden. In een versieloos systeem duurt het dagen om de hoofdoorzaak van een regressie te vinden.

Terugdraaien. Als een nieuwe prompt of een nieuw model zich live slechter gedraagt ​​dan verwacht, zou u snel moeten kunnen terugkeren naar de vorige, bekende versie. Een verandering zonder een terugdraaiplan is het blindelings accepteren van een reëel risico. "Ik heb iets veranderd, het is slecht geworden, ik kan niet meer terug" is het duurste productiescenario.

Geleidelijke uitrol. In plaats van een wijziging in één keer op al het verkeer toe te passen, rolt u deze eerst uit naar een klein percentage (bijvoorbeeld 5%) en bewaakt u de statistieken (kwaliteit, kosten, fouten). Als het goed is, verhoog je het percentage; Als het slecht is, krijg je het terug, waarbij slechts een klein gedeelte is aangetast. Dit beperkt het risico aanzienlijk.

Deze drie praktijken combineren technieken uit alle voorgaande eenheden: evaluatie (eenheid 5) meet veranderingen vooraf, monitoring (deze eenheid) geeft vroegtijdige waarschuwing tijdens de verspreiding, de verificatielaag vangt foutieve resultaten op voordat ze actiegericht worden. Productie is niet één enkele juiste opzet; Het is een continue discipline die met vertrouwen meet, monitort en kan veranderen. De hele module is voor jou om deze discipline vast te leggen.

Samengevat

Productie is meer dan een werkende demo: het is een pijplijn van input-, model-, verificatie-, actie- en monitoringlagen. De uitvoer is onbetrouwbaar zonder verificatie; beslissingen met een grote impact zijn gebonden aan menselijke goedkeuring; Elk gesprek wordt gecontroleerd op kosten, fouten en kwaliteit. Ethiek, transparantie, vooringenomenheidscontrole, verantwoordelijkheid en acceptatie van limieten zijn een integraal onderdeel van technische beslissingen. Elk stukje dat in deze module wordt geleerd, komt samen in dit holistische ontwerp.

Applicatie taak

Ontwerp een LLM-functie end-to-end. (1) Vul de vijf lagen (invoer, model, verificatie, actie, monitoring) in voor jouw specifieke taak. (2) Markeer aan de hand van de impact welke beslissingen menselijke goedkeuring vereisen. (3) Schrijf ten minste drie validatiecontroles (schema, regel, bron). (4) Bepaal de belangrijkste statistieken die u gaat bijhouden en wat u niet gaat loggen. (5) Schrijf in dit onderdeel een grens en een ethisch principe op dat u accepteert.

controlelijst

• [ ] Ik kan vijf lagen van de productiepijplijn ontwerpen.
• [ ] Ik kan de uitvoer valideren op basis van schema, regel en bron.
• [ ] Ik kan een menselijke goedkeuringsdrempel instellen op basis van de impact van de beslissing.
• [ ] Ik houd de kosten, fouten en kwaliteit in de gaten en oefen om geen gevoelige gegevens in logboeken te schrijven.
• [ ] Ik kan ethiek, verantwoordelijkheid en grenzen omzetten in productiebeslissingen.

Module-examen

1. Wat doet de rol 'systeem' in een LLM-chat-API?

• A) Geeft het model permanente instructies en gedragsregels die gedurende het hele gesprek gelden ✔
• B) Bewaart de laatste vraag die door de gebruiker is geschreven
• C) Slaat de respons op die door het model wordt geproduceerd
• D) Versleutelt de API-sleutel

Beschrijving: De systeemrol geeft het model persistente instructies, persoonlijkheid en regels die gedurende het hele gesprek van toepassing zijn; Het is een omleiding op hoog niveau, los van gebruikersberichten.

2. Waarom wordt de gespreksgeschiedenis (eerdere berichten) elke keer opnieuw verzonden bij een API-verzoek?

• A) Het is noodzakelijk om een back-up te maken omdat de server de geschiedenis verwijdert
• B) API-aanroepen zijn staatloos; ✔ Bij elk verzoek wordt de context opnieuw verzonden omdat het model de geschiedenis niet onthoudt
• C) Alleen vereist voor facturering, heeft geen effect op het model
• D) Het verzenden van de geschiedenis is verplicht om te voorkomen dat de reactie wordt vertraagd

Uitleg: LLM API-aanroepen zijn staatloos; Het model onthoudt eerdere rondes niet, dus bij elk verzoek wordt alle relevante geschiedenis opnieuw verzonden om de context te behouden.

3. Wat is een 'token' in LLM-prijzen?

• A) Eenmalig wachtwoord om in te loggen op de API
• B) Een vast bedrag dat voor elke aanvraag wordt betaald
• C) De kleinste eenheid waarin het model de tekst verwerkt; komt meestal overeen met woorddeel ✔
• D) Een eenheid die alleen de lengte van de uitvoer meet

Beschrijving: Token is de kleinste eenheid waarin het model tekst verwerkt; Het komt meestal overeen met een fragment van een woord, en zowel de invoer als de uitvoer worden in rekening gebracht op basis van het aantal tokens.

4. Waarom zijn uitvoertokens bij de meeste LLM-aanbieders duurder dan invoertokens?

• A) Uitvoertokens zijn altijd langer dan invoer
• B) Invoertokens zijn gratis
• C) Uitvoertokens worden tweemaal via internet verzonden
• D) De eenheidskosten zijn hoger omdat het genereren van output aanvullende berekeningen voor elk token vereist ✔

Beschrijving: voor elk van de uitvoertokens moet het model stapsgewijze generatie (berekening) uitvoeren; Deze productiekosten zijn hoger dan het in één keer verwerken van de input, dus de output-eenheidsprijs is meestal hoger.

5. In welke situatie is het gebruik van streaming het meest nuttig?

• A) In lange antwoorden; Vermindert waargenomen vertraging en voorkomt time-out ✔
• B) Alleen in zeer korte antwoorden van één woord
• C) Om de kosten tot nul terug te brengen
• D) Om de API-sleutel te verbergen

Beschrijving: bij lange reacties vermindert streaming de waargenomen latentie door de eerste woorden onmiddellijk te laten verschijnen en voorkomt het HTTP-time-outs bij grote max_tokens-waarden.

6. Waar heeft het verhogen van de parameter 'inspanning' in moderne modellen doorgaans invloed op?

• A) Kort het antwoord altijd in
• B) Roteert automatisch de API-sleutel
• C) Het verlaagt alleen de prijs van het invoertoken
• D) Verhoogt de denkdiepte en tokenuitgaven; Het kan de kwaliteit verbeteren, maar het verhoogt ook de latentie en de kosten ✔

Beschrijving: De inspanningsparameter past aan hoe diep het model over een taak zal nadenken en hoeveel tokens het zal uitgeven; Upgraden kan de kwaliteit verbeteren, maar verhoogt ook de latentie en de kosten. Voor eenvoudige taken is een lage inspanning voldoende.

7. Wat is over het algemeen de meest kosteneffectieve aanpak voor een eenvoudige classificatietaak met grote volumes?

• A) Gebruik altijd het duurste en krachtigste model
• B) Bij elke aanvraag alle modellen tegelijkertijd bellen
• C) Het selecteren van het lichtste/goedkoopste model dat de taak volbrengt door het met een kleine evaluatie te verifiëren ✔
• D) het onnodig te hoog houden van de waarde max_tokens

Uitleg: Als de taak niet complex is, zal het kiezen van een sneller en goedkoper model dat de taak gemakkelijk volbrengt (bijvoorbeeld Haiku-klasse) in plaats van het gebruik van het duurste en krachtigste model de kosten aanzienlijk verlagen.

8. In welk scenario verlaagt prompt caching de kosten het meest?

• A) Wanneer een grote en vaste context herhaaldelijk wordt gebruikt bij veel verzoeken ✔
• B) Wanneer bij elk verzoek een geheel andere tekst wordt verzonden
• C) Wanneer er slechts één verzoek wordt gedaan
• D) Om uitvoertokens te verminderen

Beschrijving: Caching is een voorvoegselmatch; In gevallen waarin een grote, onveranderlijke context (systeemprompt, documenten) voor veel verzoeken wordt hergebruikt, is het lezen uit de cache een klein deel (~0,1x) van de volledige prijs.

9. Hoe moet ik de prompt bewerken zodat de promptcache wordt gevonden?

• A) Plaats variabele inhoud aan het begin en vaste inhoud aan het einde
• B) Integreer voor elk verzoek de huidige datum en tijd in de systeemprompt
• C) Vaste inhoud (systeemprompt, documenten) aan het begin en variabele inhoud aan het einde ✔
• D) Bij elke aanvraag de volgorde van de gereedschapslijst wijzigen

Uitleg: Omdat de cache een voorvoegselmatch is, wordt vaste/onveranderlijke inhoud (systeemprompt, documenten) geïnitialiseerd; variabele inhoud (datum, gebruikersvraag, verzoek-ID) wordt aan het einde geplaatst. Zelfs een enkele byte die aan het begin wordt gewijzigd, maakt de cache ongeldig.

10. Voor welk type werklast is batchverwerking het meest geschikt?

• A) Livechat waarbij de gebruiker direct een reactie op het scherm verwacht
• B) Slechts één korte vraag
• C) API-sleutel genereren
• D) Taken die vertragingstolerant zijn, een groot volume hebben en geen onmiddellijke resultaten vereisen ✔

Omschrijving: Batchverwerking is geschikt voor grote hoeveelheden opdrachten die geen onmiddellijke reactie vereisen en die vertraging verdragen; de resultaten worden na enige tijd geleverd, maar de kosten per eenheid zijn meestal lager.

11. Wat wordt gebruikt om met zekerheid te matchen bij welke aanvraag de resultaten horen in een batch?

• A) Verzenden van volgorde (positie) van verzoeken
• B) Lengte van antwoorden
• C) Laatste 4 cijfers van de API-sleutel
• D) Een unieke custom_id die aan elk verzoek wordt gegeven ✔

Opmerking: Bulkresultaten kunnen in een andere volgorde worden geretourneerd dan de volgorde van indiening; het is dus noodzakelijk om de resultaten te matchen op ID, niet op locatie, waarbij aan elk verzoek een unieke custom_id wordt gegeven.

12. Wat is het aanbevolen gedrag als u een 429-fout (snelheidslimiet) ontvangt van de API?

• A) Forceren door veel meer verzoeken tegelijkertijd te verzenden
• B) Opnieuw proberen met exponentieel uitstel, volgens de kop 'opnieuw proberen na' ✔
• C) Annuleer het verzoek volledig en toon de fout als een crash aan de gebruiker
• D) Het wijzigen van de API-sleutel

Uitleg: 429 is een fout die opnieuw kan worden geprobeerd; De juiste aanpak is om het opnieuw te proberen met exponentieel uitstel, met inachtneming van de retry-after-header. De meeste officiële SDK's doen dit automatisch.

13. Welke van de volgende HTTP-foutcodes worden over het algemeen als opnieuw te proberen beschouwd?

• A) 400 (ongeldig verzoek)
• B) 401 (authenticatiefout)
• C) 529 (server overbelast) ✔
• D) 404 (niet gevonden)

Uitleg: 429 (snelheidslimiet), 500 (serverfout) en 529 (overbelasting) zijn tijdelijke fouten en kunnen opnieuw worden geprobeerd door zich terug te trekken. Fouten zoals 400 en 401 zijn verzoek-/identiteitsproblemen; Opnieuw proberen lost het niet op.

14. Welke van de volgende is de veilige manier om API-sleutels te beheren?

• A) Opslaan in de omgevingsvariabele/verborgen manager, niet inbedden in de code en regelmatig roteren ✔
• B) Schrijf de sleutel rechtstreeks in de broncode en stuur deze naar de repository
• C) De sleutel in JavaScript aan de clientzijde (browser) plaatsen
• D) Eén enkele sleutel delen met het hele team via e-mail

Beschrijving: Sleutels worden nooit naar de broncode of repository geschreven; Het wordt opgeslagen in een omgevingsvariabele of verborgen beheertool, verleend met minimale rechten, en regelmatig gerouleerd.

15. Wat is de beste aanpak voor LLM-integratie met een automatiseringstool (n8n, Zapier, Make) op het gebied van privacy?

• A) Het verzenden van alle ruwe gegevens naar het model, zelfs als dit niet nodig is
• B) Het schrijven van de API-sleutel in platte tekst binnen de stroomstap
• C) Het minimaliseren en maskeren van gevoelige gegevens en het opslaan van de sleutel als geheime inloggegevens ✔
• D) Het permanent bewaren van persoonlijke gegevens in de stroomgeschiedenis

Beschrijving: Omdat gegevens die de automatisering binnenkomen via systemen en modellen van derden gaan, moeten gevoelige/persoonlijke gegevens worden geminimaliseerd en gemaskeerd en moeten alleen de verplichte velden worden verzonden; De API-sleutel wordt ook opgeslagen als geheime inloggegevens binnen de tool.

16. Waarom is validatie van output verplicht in een op LLM gebaseerde productiefunctie?

• A) Er is alleen opmaak nodig omdat het model nooit fouten maakt
• B) Omdat het model vloeiend maar soms foutief kan produceren; Schema/regel moet worden gecontroleerd met goedkeuring van middelen en mensen ✔
• C) Validatie moet worden vermeden omdat dit de kosten alleen maar verhoogt
• D) Verificatie is alleen bedoeld om het aantal tokens te verminderen

Beschrijving: LLM's kunnen vloeiende maar soms onnauwkeurige (hallucinerende) output produceren; het kwam dus naar voren in beslissingen met een grote impact; Het moet worden gecontroleerd door controle van schema's/regels, bronvalidatie en indien nodig menselijke goedkeuring.