Allega PDF, immagini, registrazioni audio, documenti Office, fogli di calcolo, diapositive e file di testo a qualsiasi richiesta di arricchimento, generazione di schemi, generazione di campioni, modifica di schemi con IA o playground. I file raggiungono il modello come byte nativi (per i modelli in grado di gestire PDF, immagini e audio) oppure come testo estratto dal server e inserito nel prompt — senza necessità di OCR, trascrizione, conversione o suddivisione manuali.
Ogni tipo MIME supportato ha una modalità di consegna configurata dall'amministratore. La modalità determina come il file raggiunge il modello.
I byte originali vengono passati al modello come BinaryContent. Il modello legge il file direttamente — nessuna preelaborazione lato server.
Richiede un modello con il flag di capacità corrispondente (supports_pdf_input per i PDF,supports_vision per le immagini,supports_audio_input per l'audio). Il selettore dei modelli viene filtrato automaticamente per mostrare solo i modelli compatibili.
Un estrattore lato server viene eseguito una sola volta al momento del caricamento e memorizza nella cache il testo risultante. A ogni successiva chiamata LLM il testo memorizzato viene inserito nel prompt utente.
Nessuna capacità del modello richiesta — funziona con qualsiasi modello. Il testo semplice e il Markdown saltano l'estrattore e decodificano direttamente i byte grezzi.
19 formati sono abilitati per impostazione predefinita. Gli amministratori di sistema possono alternare qualsiasi formato tra la modalità binary einline_text, modificarne l'etichetta o disabilitarlo completamente da Gestione modelli → Criteri documenti.
| Formato | Estensioni | Modalità predefinita | Funzionalità / estrattore |
|---|---|---|---|
| Documento PDF | binary | supports_pdf_input | |
| Immagine PNG | .png | binary | supports_vision |
| Immagine JPEG | .jpg, .jpeg | binary | supports_vision |
| Audio MP3 | .mp3 | binary | supports_audio_input |
| Audio WAV | .wav | binary | supports_audio_input |
| Audio M4A | .m4a | binary | supports_audio_input |
| Audio OGG | .ogg, .oga | binary | supports_audio_input |
| Audio FLAC | .flac | binary | supports_audio_input |
| Testo semplice | .txt | inline_text | decodifica raw |
| Markdown | .md, .markdown | inline_text | decodifica raw |
| Word (.doc legacy) | .doc | binary | docx2txt |
| Word (.docx) | .docx | binary | python-docx |
| Testo OpenDocument | .odt | binary | odfpy |
| Rich Text Format | .rtf | binary | striprtf |
| Ebook EPUB | .epub | binary | ebooklib |
| HTML | .html, .htm | binary | beautifulsoup |
| CSV | .csv | binary | csv (stdlib) |
| Foglio di calcolo (.xlsx) | .xlsx | binary | openpyxl |
| Presentazione (.pptx) | .pptx | binary | python-pptx |
Quando allega più di un file alla generazione del campione, la prima domanda è quale relazione abbiano tra loro — e sbagliarla produce silenziosamente un campione privo di senso. Per questo viene posta esplicitamente prima di generare qualsiasi cosa.
Un contratto e la sua appendice, una specifica e la relativa scheda tecnica: i file vengono letti insieme come un'unica entità.
Dieci fatture, dieci CV. Viene derivato il tipo più ristretto che li comprende tutti e i valori del campione provengono da un singolo documento scelto, anziché essere fusi tra tutti e dieci: un campione cucito insieme da dieci fonti non descrive nulla di reale.
Nove fatture e una foto delle vacanze: anziché tirare a indovinare, il job si mette in pausa e chiede se escludere l'elemento estraneo. I file che non hanno nulla in comune fanno fallire direttamente il job, indicandone il motivo.
Lo stesso meccanismo di pausa e richiesta copre qualsiasi altra ambiguità incontrata dal planner: il job si interrompe, espone le proprie domande e riprende con le sue risposte — nell'app sotto forma di finestra di dialogo, e tramite API e MCP come passaggio di risposta esplicito. Prevenire un presupposto errato costa meno che scoprirlo nello schema generato.
C'è una cosa da cui i documenti non esentano: uno schema generato dai propri file parte con il controllo di ambiguità attivo, esattamente come qualsiasi altro. Quel controllo verifica se il nome di una proprietà ammette più di un significato — una questione relativa al modo in cui lo schema è formulato, non alla provenienza dei valori di questa esecuzione. Il documento ha fissato i valori una volta sola; lo schema continua a essere riutilizzato su entità che non copriva affatto.
(organization_id, sha256).inline_text, l'estrattore viene eseguito al momento del caricamento e il testo risultante viene memorizzato nella cache sulla riga dell'attachment. Le chiamate LLM successive riutilizzano il testo memorizzato — senza costi di ri-estrazione. I formati binary saltano questo passaggio.DELETE /api/attachments/{id} — un comodo passaggio di pulizia post-arricchimento. L'eliminazione è limitata all'organizzazione e restituisce { success, id, filename }.Gli allegati possono essere caricati ed eliminati in modo programmatico, non solo dall'interfaccia web: il connettore n8n carica tramite multipart nativo, i connettori Make.com e MCP caricano tramite il percorso JSON base64 e qualsiasi client può usare direttamente l'API REST (DELETE /api/attachments/{id} per la pulizia).
Quando si allega un file binario con un requisito di capacità (PDF, immagine o audio), il selettore dei modelli viene filtrato per mostrare solo i modelli che dichiarano tale capacità. Se si allegano più file con requisiti diversi, vengono mostrati solo i modelli che soddisfano tutti i requisiti.
L'API applica la stessa regola: l'abbinamento di un modello incompatibile con un attachment binario restituisce 400 model_lacks_attachment_capability, così le integrazioni che aggirano l'interfaccia ricevono un chiaro errore preliminare invece di un guasto del provider a metà del processo. Gli attachment di testo inline non impongono mai alcun requisito.
| File allegati | Modelli idonei |
|---|---|
| 1 PDF | supports_pdf_input |
| 1 PNG | supports_vision |
| 1 MP3 | supports_audio_input |
| 1 PDF + 1 PNG | supports_pdf_input E supports_vision |
| 1 DOCX (modalità binaria, nessuna capacità) | Tutti i modelli — il supporto nativo per i byte è presunto quando non è impostato alcun flag di capacità |
| 1 TXT o 1 MD (modalità inline_text) | Tutti i modelli — il testo viene incorporato nel prompt |
Gli allegati vengono fatturati come token di input riportati dal provider del modello — Entity Enricher non applica una tariffa separata per documento. Il costo dipende dal tipo di file e dal modello selezionato.
Consumano token di input specifici del modello. Anthropic addebita circa 1700 token per pagina PDF; OpenAI calcola il prezzo degli input visivi in base al numero di riquadri; i modelli in grado di gestire l'audio misurano l'input audio in proporzione alla sua durata. Consulta la scheda dei prezzi del tuo modello in Modelli e prezzi.
Il testo estratto consuma token di input alla tariffa standard per il testo. I documenti di grandi dimensioni sono limitati a 500 KB di testo estratto — i contenuti più lunghi vengono troncati.