Kort antwoord: Definieer wat "goed" vir jou gebruiksgeval lyk, en toets dan met verteenwoordigende, weergawe-aanwysings en randgevalle. Koppel outomatiese metrieke met menslike rubriektelling, tesame met teenstrydige veiligheid en aanwysings-inspuitingskontroles. Indien koste- of latensiebeperkings bindend word, vergelyk modelle volgens taaksukses per pond bestee en p95/p99-reaksietye.
Belangrike wegneemetes:
Verantwoordelikheid : Ken duidelike eienaars toe, hou weergawelogboeke en voer evaluasies weer uit na enige aanwysings of modelverandering.
Deursigtigheid : Skryf sukseskriteria, beperkings en mislukkingskoste neer voordat jy begin om punte in te samel.
Ouditbaarheid : Handhaaf herhaalbare toetssuites, geëtiketteerde datastelle en nagespoorde p95/p99-latensiemetrieke.
Betwisbaarheid : Gebruik menslike hersieningsrubrieke en 'n gedefinieerde appèlpad vir betwiste uitsette.
Misbruikweerstand : Rooi-span vinnige inspuiting, sensitiewe onderwerpe en oormatige weiering om gebruikers te beskerm.
As jy 'n model vir 'n produk, 'n navorsingsprojek of selfs 'n interne hulpmiddel kies, kan jy nie net "dit klink slim" en dit versend nie (sien die OpenAI-evalueringsgids en die NIST AI RMF 1.0 ). Só kry jy 'n kletsbot wat met selfvertroue verduidelik hoe om 'n vurk in die mikrogolfoond te verhit. 😬
Artikels wat jy dalk na hierdie een wil lees:
🔗 Die toekoms van KI: tendense wat die volgende dekade vorm.
Belangrike innovasies, impak op werkgeleenthede en etiek om dop te hou.
🔗 Grondslagmodelle in generatiewe KI verduidelik vir beginners
Leer wat hulle is, hoe hulle opgelei word en hoekom hulle saak maak.
🔗 Hoe KI die omgewing en energieverbruik beïnvloed
Verken emissies, elektrisiteitsvraag en maniere om voetspoor te verminder.
🔗 Hoe KI-opskaling vandag vir skerper beelde werk.
Kyk hoe modelle detail byvoeg, geraas verwyder en skoon vergroot.
1) Definieer "goed" (dit hang af, en dis goed so) 🎯
Voordat jy enige evaluering doen, besluit hoe sukses lyk. Andersins sal jy alles meet en niks leer nie. Dis soos om 'n maatband te bring om 'n koekkompetisie te beoordeel. Sekerlik, jy sal syfers kry, maar hulle sal jou nie veel vertel nie 😅
Verduidelik:
-
Gebruikersdoelwit : opsomming, soektog, skryfwerk, redenasie, feite-onttrekking
-
Mislukkingskoste : 'n verkeerde fliekaanbeveling is snaaks; 'n verkeerde mediese instruksie is ... nie snaaks nie (risikoraming: NIST AI RMF 1.0 ).
-
Looptydomgewing : op toestel, in die wolk, agter 'n firewall, in 'n gereguleerde omgewing
-
Primêre beperkings : latensie, koste per versoek, privaatheid, verduidelikbaarheid, veeltalige ondersteuning, toonbeheer
'n Model wat die "beste" in een werk is, kan 'n ramp in 'n ander wees. Dis nie 'n teenstrydigheid nie, dis die werklikheid. 🙂
2) Hoe 'n stewige KI-model-evalueringsraamwerk lyk 🧰
Ja, dis die deel wat mense oorslaan. Hulle gryp 'n maatstaf, voer dit een keer uit en maak 'n einde daaraan. 'n Stewige evalueringsraamwerk het 'n paar konsekwente eienskappe (praktiese gereedskapvoorbeelde: OpenAI Evals / OpenAI evals gids ):
-
Herhaalbaar - jy kan dit volgende week weer doen en vergelykings vertrou
-
Verteenwoordigend - dit weerspieël jou werklike gebruikers en take (nie net trivia nie)
-
Veelvlakkig - kombineer outomatiese metrieke + menslike hersiening + teenstrydige toetse
-
Aksiebaar - resultate sê vir jou wat om reg te stel, nie net "telling het gedaal" nie
-
Peuterbestand - vermy "onderrig tot die toets" of toevallige lekkasie
-
Kostebewus - evaluering self behoort jou nie bankrot te maak nie (tensy jy van pyn hou)
As jou evaluering nie kan oorleef deur 'n skeptiese spanmaat wat sê "Goed, maar koppel dit aan produksie" nie, dan is dit nog nie klaar nie. Dis die vibe-toets.
3) Hoe om KI-modelle te evalueer deur te begin met gebruiksgevalsnitte 🍰
Hier is 'n truuk wat 'n klomp tyd bespaar: breek die gebruiksgeval in skywe op .
In plaas daarvan om “die model te evalueer”, doen:
-
Begrip van voorneme (kry dit wat die gebruiker wil hê)
-
Herwinning of konteksgebruik (gebruik dit die verskafde inligting korrek)
-
Redenering / meerstap-take (bly dit samehangend oor stappe heen)
-
Formatering en struktuur (volg dit instruksies)
-
Veiligheid en beleidsbelyning (vermy dit onveilige inhoud; sien NIST AI RMF 1.0 )
-
Toon en handelsmerkstem (klink dit soos jy wil hê dit moet klink)
Dit laat “Hoe om KI-modelle te evalueer” minder soos een groot eksamen voel en meer soos 'n stel geteikende vasvrae. Vasvrae is irriterend, maar hanteerbaar. 😄
4) Basiese beginsels van vanlyn evaluering - toetsstelle, etikette en die onglansvolle besonderhede wat saak maak 📦
Vanlyn-evaluering is waar jy beheerde toetse doen voordat gebruikers enigiets aanraak (werkvloeipatrone: OpenAI Evals ).
Bou of versamel 'n toetsstel wat werklik joune is
'n Goeie toetsstel sluit gewoonlik die volgende in:
-
Goue voorbeelde : ideale uitsette wat jy met trots sou versend
-
Randgevalle : dubbelsinnige aanwysings, onordelike insette, onverwagte formatering
-
Foutmodus-ondersoeke : aanwysings wat hallusinasies of onveilige antwoorde uitlok (risikotoetsraamwerk: NIST AI RMF 1.0 )
-
Diversiteitsdekking : verskillende gebruikersvaardigheidsvlakke, dialekte, tale, domeine
As jy slegs op "skoon" aanwysings toets, sal die model fantasties lyk. Dan verskyn jou gebruikers met tikfoute, halfsinne en woedende energie. Welkom by die werklikheid.
Etiketteringskeuses (ook bekend as: strengheidsvlakke)
Jy kan uitsette benoem as:
-
Binêr : slaag/druip (vinnig, hard)
-
Ordinaal : 1-5 kwaliteittelling (genuanseerd, subjektief)
-
Multi-eienskap : akkuraatheid, volledigheid, toon, aanhalingsgebruik, ens. (beste, stadiger)
Multi-eienskap is die ideale keuse vir baie spanne. Dis soos om kos te proe en southeid afsonderlik van tekstuur te beoordeel. Andersins sê jy net "goed" en trek jou skouers op.
5) Metrieke wat nie lieg nie - en metrieke wat dit soort van doen 📊😅
Metrieke is waardevol ... maar hulle kan ook 'n glinsterbom wees. Blink, oral, en moeilik om skoon te maak.
Algemene metrieke families
-
Akkuraatheid / presiese ooreenstemming : ideaal vir ekstraksie, klassifikasie, gestruktureerde take
-
F1 / presisie / herroeping : handig wanneer iets mis erger is as ekstra geraas (definisies: scikit-leer presisie/herroeping/F-telling )
-
BLEU / ROUGE-styloorvleueling : goed vir opsommingsagtige take, dikwels misleidend (oorspronklike statistieke: BLEU en ROUGE )
-
Inbedding van ooreenkoms : nuttig vir semantiese ooreenstemming, kan verkeerde maar soortgelyke antwoorde beloon
-
Taaksukseskoers : "het die gebruiker gekry wat hulle nodig gehad het" goue standaard wanneer dit goed gedefinieer is
-
Beperkingsnakoming : volg formaat, lengte, JSON-geldigheid, skema-nakoming
Die sleutelpunt
As jou taak oop is (skryf, redeneer, ondersteuningsklets), kan enkelgetalmetrieke ... wankelrig wees. Nie nutteloos nie, net wankelrig. Om kreatiwiteit met 'n liniaal te meet is moontlik, maar jy sal dom voel om dit te doen. (Jy sal waarskynlik ook jou oog uitsteek.)
So: gebruik metrieke, maar anker dit aan menslike hersiening en werklike taakuitkomste (een voorbeeld van LLM-gebaseerde evalueringsbespreking + voorbehoude: G-Eval ).
6) Die Vergelykingstabel - top evalueringsopsies (met eienaardighede, want die lewe het eienaardighede) 🧾✨
Hier is 'n praktiese spyskaart van evalueringsbenaderings. Meng en pas. Die meeste spanne doen dit.
| Gereedskap / Metode | Gehoor | Prys | Hoekom dit werk |
|---|---|---|---|
| Handgeboude prompt toets suite | Produk + eng | $ | Baie geteiken, vang regressies vinnig op - maar jy moet dit vir altyd onderhou 🙃 (beginnershulpmiddels: OpenAI Evals ) |
| Menslike rubriek-puntepaneel | Spanne wat beoordelaars kan spaar | $$ | Beste vir toon, nuanse, "sou 'n mens dit aanvaar", effense chaos afhangende van resensente |
| LLM-as-beoordelaar (met rubrieke) | Vinnige iterasielusse | $-$$ | Vinnig en skaalbaar, maar kan vooroordeel erf en soms vibrasies gradeer, nie feite nie (navorsing + bekende vooroordeelkwessies: G-Eval ) |
| Teenstanders rooi-span sprint | Veiligheid + nakoming | $$ | Vind pittige mislukkingsmodusse, veral vinnige inspuiting - voel soos 'n strestoets by die gimnasium (bedreigingsoorsig: OWASP LLM01 Vinnige Inspuiting / OWASP Top 10 vir LLM-programme ) |
| Sintetiese toetsgenerering | Data-ligte spanne | $ | Goeie dekking, maar sintetiese aanwysings kan te netjies, te beleefd wees ... gebruikers is nie beleefd nie |
| A/B-toetsing met regte gebruikers | Volwasse produkte | $$$ | Die duidelikste sein - ook die mees emosioneel stresvolle wanneer metrieke swaai (klassieke praktiese gids: Kohavi et al., “Beheerde eksperimente op die web” ) |
| Herwinningsgebaseerde evaluering (RAG-kontroles) | Soek + QA-programme | $$ | Meet "gebruik konteks korrek," verminder hallusinasietelling-inflasie (RAG-evalueringsoorsig: Evaluering van RAG: 'n Opname ) |
| Monitering + drywingsopsporing | Produksiestelsels | $$-$$$ | Vang agteruitgang oor tyd op - onopvallend tot die dag wat dit jou red 😬 (oorsig van drywing: Konsep-drywingsopname (PMC) ) |
Let op dat die pryse doelbewus laag is. Dit hang af van skaal, gereedskap en hoeveel vergaderings jy per ongeluk skep.
7) Menslike evaluering - die geheime wapen wat mense onderbefonds 👀🧑⚖️
As jy slegs outomatiese evaluering doen, sal jy die volgende mis:
-
Toonwanpassing ("hoekom is dit so sarkasties")
-
Subtiele feitelike foute wat vlot lyk
-
Skadelike implikasies, stereotipes of ongemaklike formulering (risiko + vooroordeelraamwerk: NIST AI RMF 1.0 )
-
Instruksie-volgende mislukkings wat steeds "slim" klink
Maak rubrieke konkreet (of beoordelaars sal vrystyl)
Swak rubriek: “Behulpsaamheid”
Beter rubriek:
-
Korrektheid : feitelik akkuraat gegewe die aanwysing + konteks
-
Volledigheid : dek vereiste punte sonder om te veel te lees
-
Duidelikheid : leesbaar, gestruktureerd, minimale verwarring
-
Beleid / veiligheid : vermy beperkte inhoud, hanteer weiering goed (veiligheidsraamwerk: NIST AI RMF 1.0 )
-
Styl : pas by stem, toon, leesvlak
-
Getrouheid : versin nie bronne of bewerings wat nie ondersteun word nie
Doen ook soms interbeoordelaarskontroles. As twee beoordelaars voortdurend verskil, is dit nie 'n "menseprobleem" nie, maar 'n rubriekprobleem. Gewoonlik (basiese beginsels van interbeoordelaarsbetroubaarheid: McHugh oor Cohen se kappa ).
8) Hoe om KI-modelle te evalueer vir veiligheid, robuustheid en "ag, gebruikers" 🧯🧪
Dit is die deel wat jy doen voor die bekendstelling – en dan aanhou doen, want die internet slaap nooit.
Robuustheidstoetse om in te sluit
-
Tikfoute, sleng, gebrekkige grammatika
-
Baie lang aanwysings en baie kort aanwysings
-
Teenstrydige instruksies (“wees kort maar sluit elke detail in”)
-
Meervoudige gesprekke waar gebruikers doelwitte verander
-
Spoedinspuitingspogings (“ignoreer vorige reëls…”) (bedreigingsbesonderhede: OWASP LLM01 Spoedinspuiting )
-
Sensitiewe onderwerpe wat versigtige weiering vereis (risiko/veiligheidsraamwerk: NIST AI RMF 1.0 )
Veiligheidsevaluering is nie net "weier dit" nie
'n Goeie model moet:
-
Weier onveilige versoeke duidelik en kalm (riglyne vir raamwerk: NIST AI RMF 1.0 )
-
Verskaf veiliger alternatiewe wanneer toepaslik
-
Vermy die oormatige weiering van onskadelike navrae (vals positiewe)
-
Hanteer dubbelsinnige versoeke met verduidelikende vrae (wanneer toegelaat)
Oormatige weiering is 'n werklike produkprobleem. Gebruikers hou nie daarvan om soos verdagte kabouters behandel te word nie. 🧌 (Selfs al is hulle verdagte kabouters.)
9) Koste, latensie en operasionele realiteit - die evaluering wat almal vergeet 💸⏱️
'n Model kan "verstommend" wees en steeds verkeerd wees vir jou as dit stadig, duur of operasioneel broos is.
Evalueer:
-
Latensieverspreiding (nie net gemiddeld nie - p95 en p99 maak saak) (hoekom persentiele saak maak: Google SRE Werkboek oor monitering )
-
Koste per suksesvolle taak (nie koste per teken in isolasie nie)
-
Stabiliteit onder las (tydsberekeninge, tempolimiete, anomale pieke)
-
Betroubaarheid van gereedskapoproepe (as dit funksies gebruik, tree dit op)
-
Tendense vir uitsetlengte (sommige modelle dwaal af, en dwaal af kos geld)
’n Effens slegter model wat twee keer so vinnig is, kan in oefening wen. Dit klink voor die hand liggend, maar mense ignoreer dit. Soos om ’n sportmotor vir ’n inkopietog te koop en dan oor bagasieruimte te kla.
10) 'n Eenvoudige end-tot-end werkvloei wat jy kan kopieer (en aanpas) 🔁✅
Hier is 'n praktiese vloei vir Hoe om KI-modelle te evalueer sonder om in eindelose eksperimente vasgevang te word:
-
Definieer sukses : taak, beperkings, mislukkingskoste
-
Skep 'n klein "kern"-toetsstel : 50-200 voorbeelde wat werklike gebruik weerspieël
-
Voeg rand- en teenstrydige stelle by : inspuitpogings, dubbelsinnige aanwysings, veiligheidsprobes (aanwysingsinspuitingsklas: OWASP LLM01 )
-
Voer outomatiese kontroles uit : formatering, JSON-geldigheid, basiese korrektheid waar moontlik
-
Voer menslike hersiening uit : voorbeelduitsette oor kategorieë heen, punte met rubriek
-
Vergelyk afwegings : kwaliteit teenoor koste teenoor latensie teenoor veiligheid
-
Loodsprojek in beperkte vrystelling : A/B-toetse of gefaseerde bekendstelling (A/B-toetsgids: Kohavi et al. )
-
Monitor in produksie : drywing, regressies, gebruikersterugvoerlusse (drywingsoorsig: Konsepdrywingsopname (PMC) )
-
Itereer : opdateringsaanwysings, herwinning, fyn afstemming, skutrelings, voer dan evaluering weer uit (evalueringsiterasiepatrone: OpenAI-evalueringsgids )
Hou weergawe-logboeke. Nie omdat dit pret is nie, maar omdat jy in die toekoms jou sal bedank terwyl jy 'n koffie vashou en mompel "wat het verander..." ☕🙂
11) Algemene slaggate (ook bekend as: maniere waarop mense hulself per ongeluk flous) 🪤
-
Opleiding tot die toets : jy optimaliseer aanwysings totdat die maatstaf goed lyk, maar gebruikers ly daaronder
-
Lekkende evalueringsdata : toetsaanwysings verskyn in opleidings- of fyninstellingsdata (oeps)
-
Enkelmetriese aanbidding : jaag een telling na wat nie gebruikerswaarde weerspieël nie
-
Ignoreer verspreidingsverskuiwing : gebruikersgedrag verander en jou model degradeer stilweg (produksierisiko-raamwerk: Konsep-drywingsopname (PMC) )
-
Oor-indeksering van "slimheid" : slim redenasie maak nie saak of dit formatering breek of feite uitdink nie.
-
Nie die kwaliteit van weiering getoets nie : "Nee" kan korrek wees, maar steeds aaklige gebruikerservaring.
Wees ook versigtig vir demonstrasies. Demo's is soos filmvoorskoue. Hulle wys hoogtepunte, versteek die stadige dele en lieg soms met dramatiese musiek. 🎬
12) Slotopsomming oor Hoe om KI-modelle te evalueer 🧠✨
Die evaluering van KI-modelle is nie 'n enkele telling nie, dis 'n gebalanseerde maaltyd. Jy benodig proteïene (korrektheid), groente (veiligheid), koolhidrate (spoed en koste), en ja, soms nagereg (toon en plesier) 🍲🍰 (risiko-raamwerk: NIST AI RMF 1.0 )
As jy niks anders onthou nie:
-
Definieer wat "goed" beteken vir jou gebruiksgeval
-
Gebruik verteenwoordigende toetsstelle, nie net bekende maatstawwe nie
-
Kombineer outomatiese statistieke met menslike rubriekhersiening
-
Toets robuustheid en veiligheid soos gebruikers teëstanders is (want soms ... is hulle) (snelle inspuitklas: OWASP LLM01 )
-
Sluit koste en latensie in die evaluering in, nie as 'n nagedagte nie (hoekom persentiele saak maak: Google SRE Werkboek )
-
Monitor na bekendstelling - modelle dryf, toepassings ontwikkel, mense raak kreatief (dryfoorsig: Konsepdryfopname (PMC) )
Dis hoe om KI-modelle te evalueer op 'n manier wat hou wanneer jou produk aktief is en mense onvoorspelbare mense-dinge begin doen. Wat altyd is. 🙂
Gereelde vrae
Wat is die eerste stap in hoe om KI-modelle vir 'n werklike produk te evalueer?
Begin deur te definieer wat "goed" beteken vir jou spesifieke gebruiksgeval. Dui die gebruikersdoelwit aan, wat mislukkings jou kos (lae risiko's teenoor hoë risiko's), en waar die model sal loop (wolk, op die toestel, gereguleerde omgewing). Lys dan harde beperkings soos latensie, koste, privaatheid en toonbeheer. Sonder hierdie fondament sal jy baie meet en steeds 'n slegte besluit neem.
Hoe bou ek 'n toetsstel wat my gebruikers werklik weerspieël?
Bou 'n toetsstel wat werklik joune is, nie net 'n publieke maatstaf nie. Sluit goue voorbeelde in wat jy met trots sal stuur, plus raserige, in-die-wilde aanwysings met tikfoute, halfsinne en dubbelsinnige versoeke. Voeg randgevalle en mislukkingsmodus-probes by wat hallusinasies of onveilige antwoorde uitlok. Dek diversiteit in vaardigheidsvlak, dialekte, tale en domeine sodat resultate nie in produksie ineenstort nie.
Watter maatstawwe moet ek gebruik, en watter kan misleidend wees?
Pas statistieke by taaktipe. Presiese ooreenstemming en akkuraatheid werk goed vir ekstraksie en gestruktureerde uitsette, terwyl presisie/herroeping en F1 help wanneer iets mis erger is as ekstra geraas. Oorvleuelende statistieke soos BLEU/ROUGE kan misleidend wees vir oop take, en die inbedding van ooreenkoms kan "verkeerde maar soortgelyke" antwoorde beloon. Vir skryfwerk, ondersteuning of redenasie, kombineer statistieke met menslike hersiening en taaksukseskoerse.
Hoe moet ek evaluasies struktureer sodat hulle herhaalbaar en produksieklas is?
'n Stewige evalueringsraamwerk is herhaalbaar, verteenwoordigend, veelvlakkig en uitvoerbaar. Kombineer outomatiese kontroles (formaat, JSON-geldigheid, basiese korrektheid) met menslike rubriektelling en teenstrydige toetse. Maak dit peuterbestand deur lekkasie te vermy en "aan die toets te leer". Hou die evaluering kostebewus sodat jy dit gereeld kan herhaal, nie net een keer voor bekendstelling nie.
Wat is die beste manier om menslike evaluering te doen sonder dat dit in chaos ontaard?
Gebruik 'n konkrete rubriek sodat beoordelaars nie vrystyl nie. Beoordeel eienskappe soos korrektheid, volledigheid, duidelikheid, veiligheid-/beleidshantering, styl-/stem-ooreenstemming en getrouheid (nie om bewerings of bronne uit te dink nie). Kontroleer gereeld die ooreenkoms tussen beoordelaars; as beoordelaars voortdurend verskil, moet die rubriek waarskynlik verfyn word. Menslike hersiening is veral waardevol vir toonwanpassing, subtiele feitelike foute en mislukkings met die navolg van instruksies.
Hoe evalueer ek veiligheid, robuustheid en vinnige inspuitingsrisiko's?
Toets met "ag, gebruikers"-insette: tikfoute, sleng, teenstrydige instruksies, baie lang of baie kort aanwysings, en veranderinge aan doelwitte oor verskeie beurte. Sluit vinnige inspuitpogings soos "ignoreer vorige reëls" en sensitiewe onderwerpe in wat versigtige weierings vereis. Goeie veiligheidsprestasie is nie net weiering nie - dit is om duidelik te weier, veiliger alternatiewe aan te bied wanneer toepaslik, en om onskadelike navrae wat gebruikerservaring benadeel, te veel te weier wat dit benadeel.
Hoe evalueer ek koste en latensie op 'n manier wat ooreenstem met die werklikheid?
Moenie net gemiddeldes meet nie - hou die vertragingsverspreiding dop, veral p95 en p99. Evalueer die koste per suksesvolle taak, nie die koste per teken in isolasie nie, want herprobeer en onstabiele uitsette kan besparings uitwis. Toets stabiliteit onder las (tyd-uit, tempolimiete, pieke) en die betroubaarheid van gereedskap-/funksie-oproepe. 'n Effens swakker model wat twee keer so vinnig of meer stabiel is, kan die beter produkkeuse wees.
Wat is 'n eenvoudige end-tot-end werkvloei vir hoe om KI-modelle te evalueer?
Definieer sukseskriteria en beperkings, en skep dan 'n klein kerntoetsstel (ongeveer 50–200 voorbeelde) wat werklike gebruik weerspieël. Voeg rand- en teenstrydige stelle by vir veiligheid en inspuitpogings. Voer outomatiese kontroles uit, en monster dan uitsette vir menslike rubriektelling. Vergelyk kwaliteit teenoor koste teenoor latensie teenoor veiligheid, loods met 'n beperkte uitrol of A/B-toets, en monitor in produksie vir drywing en regressies.
Wat is die mees algemene maniere waarop spanne hulself per ongeluk flous in model-evaluering?
Algemene lokvalle sluit in die optimalisering van aanwysings om 'n maatstaf te slaag terwyl gebruikers ly, die lek van evalueringsaanwysings in opleidings- of fyninstellingsdata, en die aanbidding van 'n enkele maatstaf wat nie gebruikerswaarde weerspieël nie. Spanne ignoreer ook verspreidingsverskuiwing, oorindekseer "slimheid" in plaas van formaatnakoming en getrouheid, en slaan weieringskwaliteitstoetsing oor. Demonstrasies kan hierdie probleme wegsteek, so vertrou op gestruktureerde evaluasies, nie op rolle nie.
Verwysings
-
OpenAI - OpenAI-evalueringsgids - platform.openai.com
-
Nasionale Instituut vir Standaarde en Tegnologie (NIST) - KI-risikobestuursraamwerk (KI RMF 1.0) - nist.gov
-
OpenAI - openai/evals (GitHub-bewaarplek) - github.com
-
scikit-leer - presisie_herroeping_fscore_ondersteuning - scikit-learn.org
-
Vereniging vir Berekeningslinguistiek (ACL-bloemlesing) - BLEU - aclanthology.org
-
Vereniging vir Berekeningslinguistiek (ACL-bloemlesing) - ROUGE - aclanthology.org
-
arXiv - G-Evaluering - arxiv.org
-
OWASP - LLM01: Vinnige Inspuiting - owasp.org
-
OWASP - OWASP Top 10 vir Groot Taalmodel Toepassings - owasp.org
-
Stanford Universiteit - Kohavi et al., “Beheerde eksperimente op die web” - stanford.edu
-
arXiv - Evaluering van RAG: 'n Opname - arxiv.org
-
PubMed Central (PMC) - Konsep-drywingsopname (PMC) - nih.gov
-
PubMed Central (PMC) - McHugh oor Cohen se kappa - nih.gov
-
Google - SRE Werkboek oor monitering - google.werkboek