Riepilogo Tecnico: Mitigazione degli Errori nelle Invocazioni di Web API Generate da LLM

Problema

L'integrazione di web API è fondamentale nello sviluppo software moderno, tuttavia scrivere codice di invocazione corretto rimane una sfida significativa a causa delle specifiche complesse ed in evoluzione definite nei documenti OpenAPI. Sebbene i Large Language Models (LLM) mostrino potenziale nella generazione di codice, studi empirici (nello specifico il lavoro precedente degli autori, WAPIIBench) hanno dimostrato che essi generano frequentemente invocazioni di web API errate. Questi errori variano dalla selezione di endpoint sbagliati o metodi HTTP errati, fino all'allucinazione di argomenti illegali o l'omissione di parametri richiesti.

Le tecniche di mitigazione esistenti come la Retrieval-Augmented Generation (RAG) e la Constrained Decoding (CD) hanno mostrato successo in altri domini, ma rimangono insufficientemente comprese per le sfide specifiche delle invocazioni di web API. A differenza delle chiamate a funzioni locali, le invocazioni di web API richiedono la costruzione di richieste HTTP esplicite (URL, metodo, header, body) basate su specifiche esterne che evolvono indipendentemente dal codice client. Questo articolo affronta la questione aperta di come mitigare efficacemente questi specifici tipi di errore utilizzando RAG e CD.

Metodologia

Gli autori propongono e valutano sistematicamente due approcci complementari per migliorare il codice di invocazione di web API generato da LLM:

1. Retrieval-Augmented Generation (RAG)

• Design del Retriever: Gli autori hanno progettato un retriever che elabora le specifiche OpenAPI. A differenza della suddivisione standard dei documenti (chunking), hanno suddiviso le specifiche per endpoint, garantendo che ogni chunk contenga la documentazione completa per un singolo endpoint (inclusi riferimenti inline, schemi di sicurezza e parametri del percorso) per mantenere il contesto.
• Embedding e Storage: I chunk vengono trasformati in vettori tramite il modello all-MiniLM-L6-v2 e memorizzati in un database vettoriale Chroma. Per migliorare i tassi di successo del recupero, ogni endpoint è memorizzato con fino a cinque diverse varianti di embedding (ad esempio, variando l'inclusione di liste di parametri o schemi di risposta).
• Iniezione nel Prompt: La documentazione dell'endpoint recuperata viene formattata in una rappresentazione compatta, ispirata a TypeScript (Listing 2), e iniettata nel prompt del modello. Un meccanismo di troncamento gestisce i limiti della lunghezza del contesto.

2. Constrained Decoding (CD)

• Generazione dei Vincoli: Gli autori hanno sviluppato un traduttore automatico che converte le specifiche OpenAPI in vincoli basati su espressioni regolari (regex). Questi vincoli sono progettati per imporre una stretta conformità alla specifica dell'API durante la generazione dei token.
• Struttura Gerarchica: I vincoli sono organizzati gerarchicamente:
  1. Metodo HTTP: Restringe la generazione ai metodi supportati.
  2. URL: Limita i percorsi validi a quelli definiti per il metodo selezionato.
  3. Parametri: Una volta identificato un endpoint, i vincoli limitano i parametri a quelli definiti per quell'endpoint, gestendo l'opzionalità, l'ordine e i tipi di dati.
• Implementazione: Un motore di completamento personalizzato filtra dinamicamente la distribuzione di probabilità del token successivo del modello, impostando a zero la probabilità dei token che violano i vincoli. Ciò garantisce che URL, metodi HTTP e argomenti generati siano sempre conformi alle specifiche.

3. Framework di Valutazione

Lo studio utilizza due dataset:

• Dataset Sintetico: Derivato da WAPIIBench, copre 395 task su quattro API (Asana, Google Calendar, Google Sheets, Slack) con una ground truth precisa.
• Dataset del Mondo Reale: Un nuovo dataset costruito tramite il mining di repository GitHub per file JavaScript basati su Axios. Include 28 task su 11 API, riflettendo pattern di utilizzo comuni e il contesto del codice a livello di file.

La valutazione misura la Correttezza (codice eseguibile che corrisponde alla ground truth), le Allucinazioni (endpoint o argomenti illegali) e l'Eseguibilità. Gli esperimenti sono stati condotti su 24 LLM open-source (inclusi CodeLlama, StarCoder, Qwen, DeepSeek) e due modelli commerciali (GPT-4o, GPT-4o mini) attraverso due configurazioni: Full Completion (il modello seleziona endpoint e argomenti) e Argument Completion (l'endpoint è fornito, il modello seleziona gli argomenti).

Contributi Chiave

1. RAG Specializzata per API: Un metodo di recupero che elabora le specifiche OpenAPI in chunk autosufficienti a livello di endpoint, formattati specificamente per l'efficienza dei token e la comprensione degli LLM.
2. Generazione Automatica dei Vincoli: Un sistema che traduce le specifiche OpenAPI in vincoli basati su regex, garantendo che il codice generato sia strettamente conforme alle definizioni delle API.
3. Dataset del Mondo Reale: Un nuovo dataset derivato da repository GitHub per completare i benchmark sintetici, offrendo scenari di utilizzo diversi e realistici.
4. Valutazione Empirica Sistematica: Uno studio completo di RAG, CD e della loro combinazione su 24 modelli e due dataset distinti.

Risultati

Retrieval-Augmented Generation (RAG)

• Riduzione delle Allucinazioni: RAG riduce costantemente gli endpoint e gli argomenti allucinati in entrambi i dataset.
• Impatto sulla Correttezza: L'effetto sulla correttezza complessiva è ambivalente.
  • Nella configurazione Full Completion, RAG migliora significativamente la correttezza (ad esempio, +113% sul dataset sintetico) aiutando i modelli a selezionare l'endpoint corretto.
  • Nella configurazione Argument Completion, RAG spesso diminuisce la correttezza (ad esempio, -3% sul sintetico) perché i modelli tendono a includere eccessivamente parametri opzionali presenti nel contesto recuperato, anche quando non sono richiesti per il compito specifico.
• Dipendenza dal Modello: L'utilità di RAG dipende fortemente dal modello; alcuni modelli sfruttano il contesto efficacemente, mentre altri soffrono di "overuse dei parametri".

Constrained Decoding (CD)

• Zero Allucinazioni: CD riduce in modo affidabile gli URL, i metodi HTTP e gli argomenti illegali a zero in tutti i modelli e dataset.
• Miglioramento della Correttezza: CD migliora sostanzialmente la correttezza complessiva. Sul dataset sintetico, ha prodotto guadagni medi del +209% (Full Completion) e del +143% (Argument Completion).
• Eseguibilità: CD consente ai modelli che precedentemente fallivano nel generare codice sintatticamente valido di produrre implementazioni eseguibili, sebbene aumenti leggermente il tasso di codice non eseguibile in alcuni casi a causa della distorsione della distribuzione di probabilità.
• Consistenza: A differenza di RAG, CD fornisce miglioramenti costanti in quasi tutti i modelli.

Combinazione (RAG + CD)

• Prestazioni di Picco: La combinazione raggiunge i punteggi di correttezza assoluta più elevati (ad esempio, 73% sul dataset sintetico per Argument Completion).
• Compromessi: Pur mantenendo la garanzia di zero allucinazioni di CD, la combinazione è meno consistente rispetto a CD da sola. Per l'Argument Completion, il problema dell' "overuse dei parametri" di RAG persiste, portando a guadagni medi inferiori rispetto a CD da sola in questo specifico setup.

Significato e Rivendicazioni

Il paper sostiene che il Constrained Decoding sia la tecnica più robusta e affidabile per i compiti di invocazione di web API, offrendo garanzie rigide contro le violazioni delle specifiche e le allucinazioni. Argomenta che CD dovrebbe essere raccomandato incondizionatamente per questo scenario.

Sebbene RAG sia efficace nel ridurre le allucinazioni e nell'aiutare la selezione dell'endpoint, la sua tendenza a indurre l'uso eccessivo di parametri rende il suo beneficio netto altamente dipendente dal modello e dal compito specifico. Gli autori concludono che CD da solo sia la scelta più sicura, a meno che la priorità assoluta non sia la massima correttezza e il comportamento del modello con il contesto recuperato non sia stato validato.

Il lavoro sottolinea la necessità di integrare tecniche di controllo qualità (come CD) nei flussi di lavoro di generazione di codice guidati dall'IA per raggiungere una affidabilità pratica, in particolare per compiti che coinvolgono specifiche esterne ed in evoluzione come le web API. Gli autori posizionano il loro benchmark e la loro metodologia come base per la ricerca futura su altri criteri di qualità (ad esempio, la sicurezza) e diversi ecosistemi di programmazione.