Building Domain-Native LLM Applications

Un playbook completo per costruire applicazioni LLM verticali che integrano profonda expertise di dominio, basato sul talk di Christopher Lovejoy (Medical Doctor & AI Engineer at Anterior).

Introduzione

Christopher Lovejoy è un medico diventato AI engineer. Ha passato 8 anni a formarsi e lavorare come medico, seguiti da 7 anni a costruire sistemi AI che incorporano expertise medica. Attualmente lavora a Anterior, una company di New York che fornisce strumenti di clinical reasoning per automatizzare e accelerare l’amministrazione sanitaria e assicurativa.

Anterior serve provider assicurativi che coprono circa 50 milioni di vite negli Stati Uniti. Il loro sistema AI, chiamato Florence, processa richieste di cure mediche e deve determinare se i trattamenti sono appropriati secondo le linee guida cliniche.

Il Last Mile Problem

La sfida principale nell’applicare large language models a industrie specializzate è il last mile problem: dare al modello contesto e comprensione del workflow specifico per quel cliente, per quell’industria.

Esempio Concreto: Medical Necessity Review

Considera questo caso clinico:

• Paziente: donna di 78 anni con dolore al ginocchio destro
• Trattamento proposto: artroscopia del ginocchio
• Domanda da rispondere: “C’è documentazione di terapia conservativa non riuscita per almeno 6 settimane?”

Questa domanda apparentemente semplice nasconde molteplici livelli di complessità:

1. Conservative Therapy - Ambiguità di definizione

• Terapia conservativa = approccio non chirurgico (fisioterapia, perdita peso)
• Ma in alcuni contesti i farmaci sono “conservativi”, in altri sono “aggressivi”
• Dipende dal contesto clinico specifico

2. Unsuccessful - Interpretazione del successo

• Risoluzione completa dei sintomi?
• Miglioramento parziale significativo è sufficiente?
• Quale soglia di miglioramento definisce “successo”?

3. Documentation for 6 weeks - Evidenza vs Inferenza

• La cartella clinica dice “iniziata fisioterapia 8 settimane fa” e non ne parla più
• Possiamo assumere che sia stata fatta per 8 settimane?
• Serve documentazione esplicita di inizio, durata e completamento?

Il Plateau dei Modelli

Anterior ha investito molto tempo e sforzi nel migliorare le proprie pipeline. Hanno raggiunto un plateau intorno al 95% di accuratezza nel task principale (approvare richieste di cure).

Questo 95% era un ottimo baseline, ma non sufficiente per production in healthcare. Serviva di più.

Iterando con il sistema che descriveremo, sono passati da 95% a 99% di accuratezza - un risultato che ha valso loro il riconoscimento “Class Point of Light” alcune settimane fa.

L’Insight Chiave

I modelli ragionano molto bene e arrivano a un ottimo baseline. Ma se operi in un’industria dove devi ottimizzare quel final mile di performance, devi essere in grado di dare al modello il contesto specifico del dominio.

Adaptive Domain Intelligence Engine

Il sistema che Lovejoy presenta si chiama Adaptive Domain Intelligence Engine. Prende customer-specific domain insights e li converte in miglioramenti di performance.

Si compone di due parti principali:

1. Measurement - Come sta performando la pipeline?
2. Improvement - Come iterare e migliorare?

Parte 1: Measurement - Misurare Performance Domain-Specific

Step 1: Definire Metriche che Contano

Il primo passo è definire cosa conta davvero per i tuoi utenti. Non metriche generiche, ma quelle specifiche del dominio.

Healthcare (Medical Necessity Review):

• Metrica chiave: False Approvals (minimizzare)
• Un’approvazione falsa significa pagare per cure non necessarie
• Impatto diretto su costi e appropriatezza clinica

Altri domini - esempi:

• Legal (Contract Analysis): Minimizzare termini critici mancati
• Fraud Detection: Prevenire perdite monetarie da frode
• Education: Ottimizzare miglioramenti nei test scores

Step 2: Progettare una Failure Mode Ontology

Una failure mode ontology è una tassonomia strutturata di tutti i modi in cui la tua AI può fallire.

Esempio Anterior - Medical Necessity Review:

Tre categorie di alto livello:

1. Medical Record Extraction - errori nell’estrarre informazioni dalla cartella clinica
2. Clinical Reasoning - errori nel ragionamento clinico
3. Rules Interpretation - errori nell’interpretare le linee guida

Ogni categoria ha sottotipi specifici. Questo è un processo iterativo che richiede domain experts.

Step 3: Combinare Metriche e Failure Modes

Il vero valore emerge quando combini entrambi gli approcci.

Dashboard Interno di Anterior:

• Lato destro: Medical record del paziente + linee guida cliniche
• Lato sinistro: Output dell’AI (decisione + reasoning)
• Azioni del domain expert:
  • Marcare: corretto / non corretto
  • Se non corretto → selezionare failure mode dall’ontologia

Questo consente di costruire visualizzazioni come:

• X-axis: Numero di false approvals (metrica che conta)
• Y-axis: Diversi failure modes

Risultato: Puoi vedere quali failure modes causano più false approvals e prioritizzare di conseguenza.

Parte 2: Improvement - Iterare con Domain Context

Ready-Made Datasets da Production

Il labeling dei failure modes genera dataset pronti all’uso per iterare:

Vantaggi:

• Dati da production → rappresentativi della distribuzione reale
• Superiori ai dati sintetici per rilevanza
• Pronti per essere assegnati agli engineer

Workflow:

1. Prendi il failure mode che causa più problemi
2. Estrai i 100 casi di production con quel failure mode
3. Dai il dataset a un engineer
4. Itera e testa contro quel dataset specifico

Tracking Performance per Failure Mode

Puoi visualizzare il miglioramento nel tempo:

• X-axis: Pipeline version
• Y-axis: Performance score

Per definizione, parti molto basso su un nuovo failure mode dataset. Ma ogni versione della pipeline può migliorare significativamente un particolare failure mode, e vedere gli altri migliorare di conseguenza.

Bonus: Puoi tracciare che non stai regredendo su failure modes precedentemente risolti.

Domain Experts nel Loop di Iterazione

L’innovazione chiave: portare i domain experts direttamente nel processo di miglioramento.

Come funziona:

1. Tooling per domain experts (non tecnici)
2. Possono suggerire cambiamenti alla pipeline
3. Possono aggiungere domain knowledge che la pipeline può utilizzare
4. Domain evals testano automaticamente se le modifiche migliorano
5. Se migliorano → vanno in production

Dashboard con Domain Knowledge Addition

La stessa dashboard di review, ma con un bottone aggiuntivo: “Aggiungi Domain Knowledge”.

Workflow completo:

1. Domain expert rivede il caso
2. Marca corretto/non corretto
3. Seleziona failure mode
4. Suggerisce domain knowledge che risolverebbe il problema

Esempio concreto:

Il modello fa un errore interpretando “suspicion of a condition” quando il paziente ha già la condizione. Il domain expert può aggiungere:

• Contesto medico su come interpretare “suspicion” come termine
• Scoring systems che il modello non conosce
• Regole cliniche specifiche

Iteration Speed Incredibile

Same-day fixes:

1. Caso arriva da production (mattina)
2. Domain expert lo analizza (pomeriggio)
3. Aggiunge domain knowledge
4. Evals verificano il miglioramento
5. Va live in production (sera)

Mettendo Tutto Insieme: Il Flow Completo

Il Sistema End-to-End

1. Production Application

• Genera decisioni e output AI

2. Domain Expert Review

• Analizza output
• Genera: metriche + failure modes + suggestions

3. Domain Expert PM (al centro)

• Riceve rich information su cosa prioritizzare
• Basandosi su failure modes e metriche

4. Engineering Iteration

• PM al engineer: “Fixa questo failure mode fino a 50% performance”
• Engineer ha dataset ready-made per quel failure mode
• Tight iteration loop: cambia prompts/models/fine-tuning → run eval → vedi impatto
• Raggiunge target → ritorna al PM

5. Decision to Go Live

• PM valuta: metriche + impatto su resto del prodotto
• Decide se deployment in production

Il Ruolo del Domain Expert PM

Il PM con expertise di dominio siede al centro di questo sistema:

• Riceve insights ricchi da domain experts
• Prioritizza basandosi su data
• Guida engineer con target chiari
• Decide deployment basandosi su contesto più ampio

Questo crea un processo self-improving data-driven gestito da chi comprende profondamente il dominio.

Domande Frequenti

Come Definire un Domain Expert?

Risposta di Lovejoy: Dipende dal workflow specifico e da cosa ottimizzi.

• Healthcare (clinical reasoning): Idealmente un medico, preferibilmente con expertise nella specialità rilevante
• Workflow più semplici: Può bastare un infermiere o figura clinica junior
• Principio generale: Qualcuno con esperienza diretta nel fare quel workflow nel mondo reale

Usate Tooling Custom o di Terze Parti?

Risposta: Tooling bespoke, costruito internamente.

Rationale:

• Se questo sistema è centrale alla tua strategia
• E alimenta vari aspetti della tua piattaforma
• Meglio costruire internamente per integrazione totale
• Più controllo e flessibilità

I Domain Experts Sono Utenti o Dipendenti?

Risposta: Entrambi, dipende.

Fase iniziale:

• Assumere domain experts in-house
• Generano dati iniziali
• Permettono iterazione rapida

Fase matura:

• I clienti stessi possono voler validare la tua AI
• Il tooling diventa customer-facing
• I clienti usano la dashboard per review

Conclusione

Per costruire un’applicazione LLM domain-native, devi risolvere il last mile problem. Questo non si risolve solo usando modelli più potenti o pipeline più sofisticate.

I Pilastri Fondamentali

1. Adaptive Domain Intelligence Engine

• Sistema per convertire domain insights in performance

2. Domain Experts al Centro

• Reviewing AI outputs
• Generating metrics, failure modes, suggestions

3. Production Data come Fonte di Verità

• Dati dal contesto reale del cliente
• Nuance understanding dei customer workflows

4. Iteration Loop Continuo

• Ready-made datasets
• Fast feedback
• Data-driven decisions

Il Risultato Finale

Un processo self-improving che:

• Usa dati di production
• Incorpora expertise di dominio
• Itera continuamente
• Migliora performance verso livelli production-ready

Risorse

• Christopher Lovejoy: chrislovejoy.me
• Email: chris@anterior.com
• Careers at Anterior: anterior.com/careers

Takeaway finale: Nelle applicazioni AI verticali, il sistema vince sui modelli. Costruisci il miglior sistema per tradurre domain insights in miglioramenti continui, e avrai un vantaggio competitivo sostenibile.