Het model-portfolio

Elk hoofdstuk van Het model-portfolio met het motto uit de gedrukte editie, wat je erna kunt, en wanneer je het nodig hebt.

1. Introductie

   Stop met het vereren van het leaderboard

   De benchmarkwinnaar is altijd andermans model op andermans taken: geprijsd, gemeten en gevierd onder omstandigheden die niets met jouw productieomgeving te maken hebben.

   Wat je erna kunt

   Je ziet dat het routeren van elk request naar de benchmarkleider een gewoonte is met cumulatieve kosten (geld, latentie en datablootstelling) en dat het beheren van modellen als een portfolio ze alle drie zichtbaar, meetbaar en bestuurbaar maakt.

   Gebruik dit hoofdstuk wanneer

   Je API-factuur zojuist omhoog is geschoten zonder corresponderende stijging in waarde, je team discussieert over modelkeuzes op basis van Twitter-consensus, of je je huidige routeringslogica niet kunt uitleggen zonder te zeggen "we gebruiken gewoon het beste."

2. Hoofdstuk 1

   Het modelselectieprobleem

   Je herkent een modelselectieproces aan zijn sporen: een Slack-bericht, een schermafbeelding van een benchmark en een keuze die vier minuten duurde. Het bewijs dat die keuze een beoordeling verdiende, duikt meestal veel later op.

   Wat je erna kunt

   Je kunt de vier faalmodi van onbeheerde modelselectie benoemen en een selectie-audit uitvoeren die de impliciete regels blootlegt waar je huidige stack op draait.

   Gebruik dit hoofdstuk wanneer

   Je op het punt staat een model te kiezen voor een nieuwe use case, of je een stack hebt geërfd en niet kunt uitleggen waarom de helft van de modellen daarin is gekozen.

3. Hoofdstuk 2

   ROUTE-overzicht

   Vijf vaardigheden. Één feedbacklus. Twee teams kunnen dezelfde modellen draaien, het ene als collectie en het andere als portfolio, en wat hen scheidt is de discipline die ze op die modellen toepassen.

   Wat je erna kunt

   Je overziet het complete ROUTE-framework als één mentaal model, begrijpt hoe de vijf vaardigheden verbonden zijn in een feedbacklus, en kunt elk model in je huidige stack in één van de vier archetypen plaatsen (frontier, workhorse, lokaal, specialist), elk met een expliciete opdracht.

   Gebruik dit hoofdstuk wanneer

   Je hebt aanvaard dat leaderboard-gestuurd routeren een gewoonte is waar je team in is gerold, eerder dan een strategie die iemand heeft gekozen, en je klaar bent om die te vervangen door een framework waar je in de praktijk mee kunt werken. Lees dit hoofdstuk als de architectuursessie die aan de bouw voorafgaat.

4. Hoofdstuk 3

   Registreer het portfolio

   Zodra een model zonder item in het register je stack binnenkomt, heb je geen ability toegevoegd, maar een aansprakelijkheid zonder eigenaar.

   Wat je erna kunt

   Je bouwt een model-register dat concreet genoeg is om echt te gebruiken (geen spreadsheet-begraafplaats), zodat elk model dat je team beheert een heldere taakopdracht, kostenklasse, privacyklasse en uitfaseringsstatus draagt.

   Gebruik dit hoofdstuk wanneer

   Je niet kunt zeggen, zonder in de code te kijken, welke modellen je team op dit moment draait, welke gegevens elk model mag aanraken, of wie verantwoordelijk is voor de uitfasering ervan als ze verouderen.

5. Hoofdstuk 4

   Doel-typering

   Een taak die je niet kunt beschrijven, kun je niet routeren. Een taak die je slecht beschrijft, routeer je slecht. De discipline van typering gaat altijd vooraf aan de discipline van routing.

   Wat je erna kunt

   Je kunt elke agentstaak karakteriseren op vijf dimensies (diepte, format, latentieklasse, kwaliteitsdrempel en privacyklasse) en een eisenprofiel opstellen dat elke volgende routekeuze helder en verdedigbaar maakt.

   Gebruik dit hoofdstuk wanneer

   Je routing-logica bouwt voor een nieuwe use case, een bestaande route controleert die onverwachte kosten of latentie produceert, of een taakinventarisatie voorbereidt voordat je een routebeleid schrijft.

6. Hoofdstuk 5

   Routebeleid

   Een beleid in proza kan worden bediscussieerd. Een beleid als beslistabel kan worden getest. Slechts één van die twee vormen vertelt je of je routing doet wat je bedoeld hebt.

   Wat je erna kunt

   Je bent straks in staat een expliciet routebeleid te schrijven voor een productoppervlak (condities, toewijzingen, fallback-ketens en override-governance) en te testen of het zich gedraagt zoals geschreven, vóór het ook maar in de buurt van productie komt.

   Gebruik dit hoofdstuk wanneer

   Je routekeuzes leven in het gedeelde mentale model van je team in plaats van in een document, of je staat op het punt een nieuw productoppervlak toe te voegen en wilt het vanaf de eerste aanroep correct routeren.

7. Hoofdstuk 6

   Cascades en fallbacks

   De duurste keuze in een routebeleid is de keuze die je nooit hebt gemaakt: altijd het krachtigste beschikbare model inzetten.

   Wat je erna kunt

   Je kunt een productiegeschikte cascade ontwerpen voor elke taak met hoog volume: de goedkoop-eerste model-tier benoemen, het escalatiesignaal definiëren, het time-outbeleid vastleggen en de fallback-keten opzetten, en je kunt uitleggen waarom een cascade zonder circuit-breaker-logica een incident in de maak is.

   Gebruik dit hoofdstuk wanneer

   Eén taaktype een onevenredig groot deel van je modelbudget opslokt; je elke aanvraag via een frontier-model routeert terwijl de meeste requests eenvoudig zijn; of je een fallback hebt die in een commentaarregel staat maar nooit is getest.

8. Hoofdstuk 7

   Lokaal vs. cloud vs. hybrid

   Waar een model draait, is een portfolio-allocatiebeslissing, met kostenconsequenties, latentiegevolgen en een datasoevereiniteitsbeperking. Net als elke andere allocatiebeslissing kun je ook deze rationeel nemen.

   Wat je erna kunt

   Je kunt elke taak scoren op drie dimensies: privacyvereiste, latentieprofiel en volume, en de juiste deployment-tier bepalen: lokaal, cloud of hybrid. Je hebt ook een uitgewerkt amortisatiemodel waarmee je je eigen hardware kunt doorrekenen, en een failover-plan dat je vandaag aan je routebeleid kunt toevoegen.

   Gebruik dit hoofdstuk wanneer

   Je een nieuwe route ontwerpt en de standaardkeuze voor cloud nooit echt is onderzocht, of je al lokaal hebt gedeployed en je afvraagt of de economie echt klopt, of je privacy-tierreview een grens heeft blootgelegd die cloud-hosting niet kan oplossen.

9. Hoofdstuk 8

   Privacy-tiers en compliance

   Een routing-systeem dat optimaliseert voor kosten en capaciteit maar datasensitiviteit negeert, heeft een juridisch probleem. Wie het een privacyprobleem noemt, zet het in het verkeerde vakje, en dat onderscheid telt, want de oplossing is een andere.

   Wat je erna kunt

   Je definieert een viertrapig privacy-schema voor jouw productcontext en koppelt elk actief taaktype aan een tier. Je ontwerpt ook de geblokkeerde-routeafhandeling die jouw compliancepositie sluitend houdt wanneer het gewenste model een gevoelig request niet kan verwerken.

   Gebruik dit hoofdstuk wanneer

   Je staat op het punt een nieuw taaktype door je stack te routeren en hebt nog niet vastgelegd welke tier van data het draagt. Of een compliancereview heeft modelaanbieders blootgelegd die je juridisch team niet voor bepaalde datacategorieën kan goedkeuren.

10. Hoofdstuk 9

    Volg kosten en latentie

    De factuur is niet het dashboard. Tegen de tijd dat een maandelijkse rekening een kostenprobleem zichtbaar maakt, loopt de routekeuze die het veroorzaakte al weken.

    Wat je erna kunt

    Je beschikt over de metrics, het dashboardontwerp en de drempelwaarden die je per route inzicht geven in kosten en latentie, en je kunt een verspillingspatroon identificeren voordat de factuur binnenkomt.

    Gebruik dit hoofdstuk wanneer

    Je hebt een routebeleid ingericht (Hoofdstuk 5 en 6) maar je vliegt blind op de vraag of het zich gedraagt zoals bedoeld. Gebruik dit hoofdstuk ook wanneer een kostenpiek zich zonder waarschuwing aandient en je geen data hebt om te verklaren welke route de oorzaak is.

11. Hoofdstuk 10

    Kwaliteitssignalen en evaluatie

    Een modelwissel die de benchmark verbetert maar het product breekt, rolt uit als promotie en landt als een regressie die niemand heeft onderschept.

    Wat je erna kunt

    Je kunt voor elke route in je portfolio een online kwaliteitssignaal definiëren dat in productie meedraait zonder de respons merkbaar te vertragen. Je ontwerpt daarnaast een lichtgewicht offline evaluatiesuite die is afgestemd op je echte taakverdeling, en je stelt een regressiepoort in die een kwaliteitsverslechterende modelwissel tegenhoudt voordat gebruikers er iets van merken.

    Gebruik dit hoofdstuk wanneer

    Je staat op het punt een model op een live route te wisselen en hebt een poort nodig die aangeeft of je door kunt gaan. Of je hebt gemerkt dat de uitvoerkwaliteit op een route slechter aanvoelt, maar je hebt geen geïnstrumenteerd signaal om dit te bevestigen. Of je draait een cascade en wilt weten of het fout-negatief-percentage van de workhorse-tier (requests die hij zou moeten escaleren maar niet escaleert) onder de drempel blijft die je bij het ontwerp hebt vastgelegd.

12. Hoofdstuk 11

    Evolueer de mix

    Een portfolio dat op de kalender wordt beheerd, wordt beheerd. Een portfolio dat met de hypecyclus meebeweegt, wordt erdoor gestuurd. Het verschil zie je terug op je factuur, in je regressielogboeken en in het vertrouwen dat je team heeft in de volgende wissel.

    Wat je erna kunt

    Je verlaat dit hoofdstuk met een kwartaalproces voor portfolio-evolutie dat vanaf dag één in gebruik is: een reviewkalender, expliciete criteria voor promotie en demotie, een checklist voor leveranciersrisico, het zesfasige Model-uitfaseringsprotocol en een providerevaluatiekader met bijbehorend risicoregister. Het bevat ook een 90-dagenplan-sjabloon voor je portfolio dat modelwissels behandelt als beheerde releases en niet als reactieve verwisselingen.

    Gebruik dit hoofdstuk wanneer

    Je team wisselt modellen op basis van aankondigingen, benchmarkreports of kostenpieken, en je wilt die reactieve gewoonte vervangen door een vast, op bewijs gebaseerd proces. Gebruik ook wanneer je op het punt staat een model in een route met veel verkeer te plaatsen en geen formele gate hebt voor die keuze.

13. Conclusie

    Conclusie: alloceer modellen zoals kapitaal

    Een portfolio zonder governance wordt nog steeds beheerd: door wie toevallig de laatste ad-hockeuze maakte. De enige vraag is of dat beheer weloverwogen gebeurt.

    Wat je erna kunt

    Je sluit dit boek af met de vijf ROUTE-disciplines samengevat in één operationeel protocol, een heldere uitwerking van wat de allocator-mindset in de praktijk betekent, en een concrete zevendaagse veldtest, één actie per letter, die je vandaag kunt beginnen.

    Gebruik dit hoofdstuk wanneer

    Je hebt het framework doorgewerkt, je kent de onderdelen, en je wilt het nu verankeren in de manier waarop je je model-portfolio echt beheert.