Van LLM naar Agent: De lagen tussen model en applicatie begrijpen

Het artikel beschrijft het volledige pad van een LLM naar een agent. In de kern voorspelt het model het volgende token in een autoreg ressieve lus, waarbij een tokenizer wordt gebruikt om tekst om te zetten naar token-ID's en een detokenizer om weer terug te converteren. KV-cache versnelt de generatie door eerdere sleutel-waardeparen op te slaan. De invoertekst die het model verwacht, is geen rauwe JSON, maar een opgemaakte prompt volgens het chattemplate van het model, een Jinja-sjabloon dat een lijst van berichten omzet in een string met speciale tokens (bijv. ChatML, Llama 3). Bij redeneermodellen kan de prompt een <think>-blok bevatten; als het model te veel tokens besteedt aan redeneren, kan het zonder generatiebudget komen te zitten voordat het een definitief antwoord produceert. Het artikel legt ook uit dat facturering en contextlengte gebaseerd zijn op de getokeniseerde prompt na het chattemplate, niet op de API JSON. Opslag van modellen op schijf omvat safetensors-gewichten, config.json, tokenizer-bestanden en het chat_template in tokenizer_config.json. Runtime-omgevingen zoals llama.cpp laden een GGUF-bestand dat deze componenten bundelt en biedt een interface op hoog niveau van tekst naar tekst.