Questo è il quarto e ultimo articolo della serie sull’architettura interna di tokensave. Nel primo articolo abbiamo introdotto il concetto di grafo semantico e la pipeline ad alto livello; nel secondo abbiamo analizzato il modello dei dati e la fase di estrazione. Qui vediamo come il grafo viene interrogato: algoritmi di traversata, analisi statiche, server MCP e context builder per gli agenti AI.

Avete mai guardato un modello linguistico “pensare” — quella sequenza di frasi ordinate, quasi filosofiche, che scorrono prima della risposta finale — e avuto la netta sensazione che stesse davvero ragionando? Bene. Questo articolo è un antidoto a quella sensazione.

Questo è il secondo articolo della serie sull’architettura interna di tokensave. Nel primo articolo abbiamo visto cos’è un grafo semantico del codice e come è strutturata la pipeline ad alto livello. Qui entriamo nel codice Rust: come sono definiti i dati, come vengono estratti dai file sorgente e come viene mantenuta la sincronizzazione con il filesystem.

Chatbot, form di contatto, caselle email condivise, ticket di supporto: in tutti questi contesti, prima ancora di rispondere, serve capire cosa vuole davvero l’utente. È un preventivo? Un reclamo? Assistenza tecnica? Una candidatura spontanea? Questo problema si chiama intent detection (letteralmente “riconoscimento dell’intento”) ed è uno dei task di NLP più classici: quando il numero di intent è chiuso e conosciuto, un classificatore statistico classico è spesso più veloce, più economico e più affidabile di un LLM.

Se hai letto la guida all’installazione di tokensave su Windows, sai già che si tratta di uno strumento di code intelligence che espone un grafo semantico del codice agli agenti AI tramite il protocollo MCP. Ma cosa significa esattamente “grafo semantico del codice”? E perché è così importante per chi lavora con agenti AI sul codice?

I Dockerfile permettono l’inserimento di una istruzione che, di fatto, dovrebbe controllare lo stato di salute del container. L’istruzione HEALTHCHECK definisce infatti un comando che Docker esegue periodicamente per determinare se il container è “sano” o “malato”. Tuttavia, c’è una tendenza diffusa a trattare questo meccanismo come se fosse un sistema di monitoraggio completo, quando in realtà non lo è.

Implementare una coda di lavoro con PostgreSQL

Quante volte, di fronte alla necessità di processare dei job asincroni in background, la risposta automatica che hai sentito è stata “aggiungiamo Redis” o “mettiamo su RabbitMQ”?

Quando si lavora con strumenti che usano i LLM, una delle assunzioni più comuni è che il modello utilizzi in modo uniforme tutte le informazioni fornite nel contesto. In realtà, esiste più di una ricerca che ha dimostrato come questa assunzione sia spesso sbagliata: è qui che entra in gioco il fenomeno noto come “Lost in the Middle”.

Se hai un IdP RBAC in produzione e stai pensando di affiancarci OpenFGA per i permessi per-risorsa, sai già che la soluzione “facile” è farli convivere. È anche la più rischiosa.