Abbiamo avuto alcune domande interne sulla gestione delle immagini nei contesti dell’IA, quindi ho voluto affrontare alcune delle considerazioni in un problema pubblico.
Il problema
Gli LLM di oggi supportano più modalità. Tutti i principali fornitori supportano ora l’input come immagini, alcuni fornitori (in particolare Google) supportano l’output come immagini.
Ciò lascia a Discourse AI un piccolo problema: come presentiamo le “immagini” agli LLM.
Nello specifico, se abbiamo questo esempio di post:
Ciao, ecco una foto di me:
E qui ce n'è un'altra
Fine
Come lo presentiamo all’LLM:
Opzione 1: Markdown Mantenuto, Immagini Aggiunte
Approccio: Mantenere tutto il testo insieme, aggiungere le immagini alla fine.
[
"Ciao, ecco una foto di me: \n\n\n\nE qui ce n'è un'altra\n\n\n\nFine",
image1,
image2
]
Opzione 2: Markdown Mantenuto, Immagini Integrate Inline
Approccio: Intercalare testo e immagini per preservare il contesto e l’ordine.
[
"Ciao, ecco una foto di me: \n\n",
image1,
"E qui ce n'è un'altra\n\n",
image2,
"Fine"
]
Opzione 3: Markdown Rimosso, Immagini Aggiunte
Approccio: Rimuovere completamente la sintassi markdown delle immagini, aggiungere le immagini effettive alla fine.
[
"Ciao, ecco una foto di me: \n\nE qui ce n'è un'altra\n\nFine",
image1,
image2
]
Opzione 4: Descrizioni Mantenute, Markdown Semplificato
Approccio: Rimuovere la formattazione specifica di Discourse ma mantenere le descrizioni delle immagini per il contesto.
[
"Ciao, ecco una foto di me: \n\nE qui ce n'è un'altra\nSam standing next to a window\n\nFine",
image1,
image2
]
Opzione 5: Descrizioni Inline, Immagini Integrate
Approccio: Sostituire il markdown con le descrizioni inline, quindi integrare le immagini corrispondenti.
[
"Ciao, ecco una foto di me:",
image1,
"E qui ce n'è un'altra\nSam standing next to a window",
image2,
"Fine"
]
Al momento la nostra implementazione è (1), parte della risposta del perché i vecchi modelli “legacy” non ci permettevano di posizionare le immagini, l’altra è che spesso le persone usano Discourse per riformattare un post, se rimuoviamo i marcatori di caricamento l’LLM penserà che abbiamo detto qualcos’altro e non sarà in grado di riformattare un post con immagini.
Inoltre, le raccomandazioni dei fornitori di LLM come Anthropic sono di posizionare sempre le immagini alla fine. Mantiene le cose più semplici da interpretare per l’LLM.
Questo approccio è però molto problematico per un LLM come Nano Banana: Image editing in Google Gemini gets a major upgrade.
Quando ci ho provato, l’LLM ha iniziato a creare marcatori di caricamento invece di renderizzare le immagini.
Ha senso retrospettivamente.
Se diciamo a un LLM che ha appena detto: upload://xd5Pv36uPIVKBqya8N5BzZGsJrN.png, non sorprenderti se dice di nuovo qualcosa di strano.
Sono combattuto sullo spostarci verso (2) e sembra che (3) sia l’unico modo sensato per “ripetere ciò che l’LLM ha appena detto, per evitare allucinazioni”… Quindi la nostra soluzione a questo problema spinoso è in qualche modo mista.
Mentre lavoravo a questo, ho esplorato se potevo creare una soluzione ancora migliore in cui output e input sono trattati allo stesso modo, ma non credo che sia pratico. (Ho anche provato a preservare le descrizioni di caricamento quando sono abbastanza lunghe e così via)
Per ora però
(1) per gli input nell’LLM
(3) per gli output dall’LLM
A lungo termine:
(2) per gli input vale la pena esplorarlo
e rimuovere ma mantenere la posizione contestuale sugli output vale anche la pena esplorarlo.
È un peccato che nessun fornitore di LLM permetta ora di fornire metadati aggiuntivi per un’immagine con l’immagine.