1 WerkmapDoel, scope, status en voortgang van een ftmodel-project.
2 DataJSON/JSONL/TXT import, automatisch of expliciet SFT/DPO/RFT.
3 ReviewMenselijke goedkeuring, correctie, scores en afwijzing.
4 AzureValideren, uploaden, job starten, syncen en resultaat vastleggen.
5 GebruikZien welk model waar draait en pas daarna koppelen.
1. Ftmodel-projectmap
Een ftmodel-projectmap is de werkruimte rond een modeldoel. Die kan al bestaan voordat er een echte Azure/GRITT deployment is geregistreerd. Dat is normaal: je kunt eerst data verzamelen, reviewen en een Azure-run doen, en pas daarna de deployment registreren.
Projectmap: doel, beschrijving, scope, importgeschiedenis, voorbeelden, beoordelingen, exports en runs.
Deployment: de naam waaronder Azure een getraind model later echt beschikbaar maakt voor GRITT-runtime.
- Als je een projectmap selecteert zonder deployment, blijft de werkmap bruikbaar maar zijn modeldocumenten en runtimekoppeling nog uitgeschakeld.
- Gebruik `Deploymentregistratie voorbereiden` om de linker registratievelden te vullen wanneer de Azure deployment bekend is.
- De statistiekstrook bovenaan toont voortgang: voorbeelden, routes, reviewstatussen, runs en laatste wijziging/training.
2. Trainingsdata import/export
Import is bedoeld voor bulkdata: JSON, JSONL of TXT. De import kan automatisch/gemengd werken of alles forceren naar SFT, DPO, RFT of evaluatie. Review blijft daarna verplicht: import maakt materiaal, geen definitieve trainingswaarheid.
SFT: voorbeeld van goed gedrag. Nodig: prompt/context plus ideale assistantreactie.
DPO: voorkeurspaar. Nodig: dezelfde opgave met gekozen antwoord en afgewezen antwoord.
RFT: smalle verifieerbare taak. Nodig: referentieantwoord plus controleerbare expected/verifier/rubric.
- Bij automatisch/gemengd kijkt GRITT per JSON-item naar velden zoals `example_type`, `chosen_answer`, `rejected_answer`, `verifier`, `expected` en `rubric`.
- TXT-import kan blokken automatisch typeren, maar blijft minder betrouwbaar dan JSON/JSONL met expliciete velden.
- Exports nemen alleen reviewed, approved of eerder exported items mee; rejected en needs_revision blijven leerbaar maar gaan niet naar training.
3. Review en goedkeuring
De reviewqueue toont de geïmporteerde of handmatig gemaakte trainingitems. Selecteer een item, pas prompt/context/antwoord aan, en zet de status op reviewed, approved, needs_revision, rejected, exported of archived.
- Gebruik approved voor items die trainingsklaar zijn.
- Gebruik needs_revision wanneer het item inhoudelijk bruikbaar is maar nog herschreven moet worden.
- Gebruik rejected voor slechte of risicovolle voorbeelden die als leersignaal bewaard mogen blijven maar niet in export horen.
4. Azure fine-tune runs
Azure-runs zijn reproduceerbare trainingspogingen. Dit paneel is technisch omdat Azure meerdere objecten kent: een datasetbestand, een job, een resultaatmodel en pas daarna een deployment die GRITT kan gebruiken.
Valideer dataset: GRITT maakt voor Azure een strikt JSONL-bestand. Bij SFT staan er alleen `messages` op elke regel; interne GRITT-metadata blijft in de projectmap en gaat niet mee naar Azure preprocessing.
Upload bestanden: training- en eventueel validatiebestand worden als Azure file opgeslagen. GRITT uploadt dit Azure-bestand als UTF-8 met BOM, omdat Azure die encoding expliciet verwacht.
Start fine-tune training: Azure maakt een job. Die kan lang lopen, falen, geannuleerd worden of een fine-tuned model opleveren.
Sync run: GRITT haalt status, events, metrics, checkpoints en eventueel resultaatmodel op.
Registreer ftmodel: pas na een bruikbaar resultaat/deployment komt het model in de GRITT modelregistry.
- Gebruik SFT als standaardroute voor toon, taakvorm en antwoordstijl.
- Gebruik DPO pas wanneer er voldoende gekozen/afgewezen paren zijn.
- Deploy-preview is bewust apart van deployment maken, omdat een deployment operationele gevolgen kan hebben.
- Een geslaagde fine-tune is nog niet automatisch actief in GRITT. Stap 5 bepaalt pas waar het model gebruikt wordt.
5. Implementatie in GRITT
Na training is het model nog niet automatisch actief. Stap 5 is primair een overzicht: welke modelregistraties en projectmappen bestaan, hoeveel data eraan hangt, wanneer er voor het laatst is getraind en waar het model wordt gebruikt.
- Technische koppeling aan globale taakroutes of bedrijfsspecifieke instellingen staat achter `Geavanceerd`.
- Bedrijf-ID's zijn alleen nodig wanneer een model voor een specifieke klant/instelling moet gelden.
- Zelflerend is voorlopig een markering; automatische periodieke training moet later via runs, reviewregels en expliciete approvals worden toegevoegd.
Werkregel
Deze pagina is geen losse verzameling tools. De normale route is: model kiezen of maken, projectmap beschrijven, data importeren, items reviewen, Azure-run starten, model registreren, implementatie controleren.
- Als iets niet in die route past, hoort het waarschijnlijk in admin modelbeheer of in modeldocumenten.
- Als een model later zelflerend wordt, moeten nieuwe voorbeelden eerst via dezelfde reviewqueue voordat ze training mogen beïnvloeden.
