Quando un team finanziario usa un LLM per costruire knowledge graph dai documenti 10-K, la sfida non è soltanto estrarre triplette corrette. È capire quali regole sono state toccate quando un prompt viene aggiornato, e dimostrare che il sistema non ha riscritto in modo opaco vincoli condivisi sulla tipizzazione o sulla temporalità. FinEvolveKG affronta questo punto con un vincolo meccanico: separa i blocchi riutilizzabili generali dalle policy legate a una persona e confina l'ottimizzatore di prompt all'interno del blocco designato.

I metodi attuali oscillano tra due estremi. Il prompt scritto a mano e il fine-tuning aggiungono costi di manutenzione e riaddestramento. L'ottimizzazione senza aggiornamento dei pesi è più leggera, ma far evolvere un prompt monolitico può modificare insieme regole condivise e indicazioni persona, rendendo opaco il cambiamento e complicando la revisione. FinEvolveKG usa GEPA, un ottimizzatore riflessivo, ma lo rende attribuibile: durante l'adattamento a una persona, il blocco generale approvato resta byte-stable e ogni modifica viene localizzata in una policy persona versionata separatamente. Un doppio obiettivo bilancia la qualità temporale del knowledge graph generico e i fatti, i motivi e la connettività multi-hop rilevanti per la persona.

Nei test su split di 10-K separati per ticker, con tre seed per i bracci condizionati da persona (v3-v5) su tre persone, il flusso v4 a due stadi con vincolo di blocco migliora rispetto al prompt congelato (v1) del 19,4–30,9% e rispetto al flusso con prompt completo non vincolato (v5) del 2,2–6,4%. v4 supera v5 su entrambe le componenti dell'obiettivo e vince tutti e nove i confronti paired-seed con la varianza più bassa in ogni persona. Senza ulteriore ottimizzazione, v4 supera v5 anche in tutti gli spostamenti out-of-distribution valutati. Un audit SME sostiene l'uso delle triplette generate come ground truth; un audit in cieco con due SME favorisce v4 rispetto a v5 nel 70,1% dei giudizi arricchiti da contrasto.

La tesi che emerge non è "il prompt vincolato funziona meglio". I margini su v5 sono contenuti e gli autori non attribuiscono causalmente i guadagni al confine. Il punto è che la separazione meccanica sposta il costo della revisione: invece di rileggere un intero prompt dopo ogni ciclo, chi valida può concentrarsi su un diff locale e su una policy versionata. In un contesto finanziario, dove l'audit conta quanto l'accuratezza, questo cambia l'incentivo ad adottare la prompt optimization. Non si tratta più di scegliere tra performance e governabilità: la seconda diventa una proprietà strutturale dell'ottimizzazione.

Per i team che gestiscono pipeline di estrazione su documenti normativi, il vantaggio di secondo ordine è la riusabilità del blocco generale. Se il blocco condiviso resta congelato, i test di regressione sulle regole comuni non vanno rieseguiti per ogni nuova persona: si valida la policy. Diminuisce anche la pressione a ricorrere al fine-tuning, perché l'ottimizzazione dei prompt può coprire parte della personalizzazione senza toccare i pesi del modello. Il terzo ordine riguarda il ciclo dei dati: se le triplette generate superano audit SME e vengono usate come ground truth, l'output dell'estrazione diventa un riferimento per addestrare o valutare altri modelli, con un circuito di fiducia che poggia sulla tracciabilità delle modifiche.

La fonte non specifica se il sistema giri su cloud o su infrastruttura locale. Tuttavia, l'enfasi su blocchi byte-stable, versionamento separato e auditabilità si allinea bene con i requisiti tipici di ambienti self-hosted nel settore finanziario: dati che non escono dal perimetro, validazioni interne ripetibili e necessità di dimostrare alle funzioni di controllo che un aggiornamento non ha alterato le regole condivise. Per chi valuta deployment on-premise, esistono trade-off tra controllo, costi operativi e velocità di iterazione; AI-RADAR offre framework analitici su /llm-onpremise per valutarli. Qui non c'è una scheda video da analizzare: il collo di bottiglia è la governance del testo che guida il modello, non soltanto la potenza di calcolo.

Resta aperta la domanda se il confine meccanico paghi anche su task diverse dai 10-K. Ma per chi costruisce knowledge graph finanziari, la possibilità di mostrare un diff locale a un revisore vale più di qualche punto percentuale.