4,4 millisecondi. È il tempo mediano che AnyDoc impiega per convertire un documento Office in Markdown. Per dare un contesto: un battito di ciglia dura circa 300ms.
Firecrawl ha rilasciato AnyDoc, un parser open source scritto in Rust che converte 14 formati di documenti in Markdown pulito, pronto per pipeline LLM e RAG.
Il progetto è MIT-licensed, ha binding per Node.js, Python e WebAssembly, e alimenta già l’endpoint /parse di Firecrawl.
In un ecosistema dove la maggior parte dei tool di document parsing per agenti AI richiede GPU, modelli ML o conversioni lente via LibreOffice, AnyDoc punta su una scommessa diversa: Rust puro, zero dipendenze pesanti, velocità estrema. Ma quanto regge nella pratica?
Come funziona AnyDoc: architettura e formati supportati
La pipeline di conversione è lineare: i byte del documento entrano, il formato viene rilevato dal contenuto (non dall’estensione del file), un parser specifico estrae la struttura, e un serializzatore GFM produce il Markdown finale.
Per i PDF, AnyDoc utilizza pdf-inspector, un motore separato sempre di Firecrawl.
I 14 formati supportati coprono praticamente tutto quello che circola in un ufficio: DOCX, DOC, DOCM, PPTX, PPT, PPTM, PPSX, PPSM, XLSX, XLS, XLSM, XLSB, ODT, ODS, ODP, RTF, EPUB, CSV e PDF. La struttura del documento viene preservata: heading con anchor, grassetto, corsivo, strikethrough, code block, link, liste numerate, puntate, annidate e task list. Le immagini embedded vengono estratte come byte grezzi con media type, e rese come alt text nel Markdown.
La pipeline di AnyDoc: dal file grezzo al Markdown in un singolo passaggio deterministico
Benchmark: AnyDoc contro le alternative nel 2026
I numeri sono il punto forte di AnyDoc, e meritano un’analisi onesta. Firecrawl ha testato il parser su 100 documenti reali, confrontandolo con sei tool concorrenti. I risultati mostrano un vantaggio netto sulla velocità, ma con sfumature importanti sulla qualità.
| Tool | Formati | Velocità mediana | Qualità (0-100) |
|---|---|---|---|
| AnyDoc (Rust) | 14/14 | 4,4ms | 81 |
| LibreOffice | 12/14 | 1.129ms | 87 |
| Docling (IBM) | Varia | ~500ms | 63 |
| Marker | PDF only | ~572ms | Varia |
| PyMuPDF4LLM | PDF only | ~52ms | Varia |
AnyDoc è circa 250 volte più veloce di LibreOffice e copre più formati di qualsiasi alternativa testata. Ma LibreOffice ottiene un punteggio di qualità di 87 contro l’81 di AnyDoc. Sei punti di differenza che, su documenti con formattazione complessa, possono tradursi in heading mancanti o tabelle mal renderizzate.
Il punto è che velocità e qualità servono cose diverse. Se il tuo agente AI deve processare 500 contratti DOCX per estrarre clausole specifiche, 4,4ms per file significa finire in meno di 3 secondi. Se deve interpretare un report PDF con grafici e tabelle annidate, forse Docling o Marker con OCR restano scelte migliori.
Perché Rust cambia le regole del document parsing per agenti AI
La scelta di Rust non è estetica. Nella maggior parte degli stack di parsing documenti per LLM, la conversione passa per LibreOffice (spawn di un processo esterno, 1+ secondo per file) o per modelli ML in Python (GPU richiesta, setup complesso). Rust elimina entrambi i colli di bottiglia: nessun garbage collector, nessuna dipendenza runtime pesante, compilazione nativa.
Per un agente AI che opera in produzione, la differenza è concreta. Un agente che deve leggere 200 documenti da una cartella condivisa prima di rispondere a una domanda passa da 4 minuti di attesa (con LibreOffice) a meno di 1 secondo (con AnyDoc). È la differenza tra un workflow che l’utente abbandona e uno che sembra istantaneo.
AnyDoc funziona anche come Agent Skill: un singolo comando che permette a Claude Code, Cursor o qualsiasi agente compatibile di leggere file Office senza configurazione aggiuntiva.
L’installazione è un npm install o un pip install, e c’è persino un modulo WebAssembly per il browser.
Le migliori alternative ad AnyDoc nel 2026: quando scegliere cosa
AnyDoc non è l’unico giocatore sul campo, e in diversi scenari non è nemmeno il migliore. Ecco una mappa orientativa per scegliere il tool giusto in base al caso d’uso.
La scelta dipende dal tipo di documento, non dal marketing del tool
Docling, il parser open source di IBM con oltre 61.000 stelle su GitHub, è probabilmente la scelta più robusta per PDF complessi. Mantiene struttura, tabelle e ordine di lettura meglio di qualsiasi alternativa, e si integra nativamente con LangChain, LlamaIndex e Haystack. Il trade-off è la velocità: ordini di grandezza più lento di AnyDoc.
Marker, con 18.000+ stelle, eccelle sui PDF accademici e libri strutturati.
Il flag —use_llm aggiunge un layer LLM per i layout complessi, ottenendo qualità quasi perfetta a costo di tempo e token.
MinerU è la scelta per documenti multilingue, con OCR per 84 lingue e riconoscimento formule.
PyMuPDF4LLM è il più veloce sui PDF nativi (circa 52ms), ma gestisce solo PDF.
Il punto critico: AnyDoc non ha OCR.
Sui PDF scannati, contratti fotografati o documenti con immagini di testo, non funziona.
L’endpoint hosted /parse di Firecrawl aggiunge OCR tramite GPU, ma è un servizio a pagamento, non il parser open source.
Per chi lavora con documenti scannati, la scelta resta tra Docling, Marker e MinerU.
Cosa significa per chi costruisce pipeline RAG e agenti AI
Il document parsing è uno dei colli di bottiglia più sottovalutati nelle pipeline AI aziendali. Nella nostra esperienza con i clienti, il 60-70% dei documenti che un agente deve leggere sono file Office con testo nativo: presentazioni commerciali, report interni, contratti Word, fogli Excel. Per questa classe di documenti, AnyDoc è probabilmente lo strumento più veloce disponibile oggi.
Ma il mondo reale è disordinato.
Un archivio aziendale tipico contiene PDF scannati degli anni 2000, documenti con watermark, fogli di calcolo con macro VBA, e presentazioni con grafici rasterizzati.
Per questi, un singolo parser non basta: serve uno stack che instradi ogni documento al tool giusto, esattamente come fa l’endpoint /parse di Firecrawl con il suo sistema di intelligent routing tra estrazione nativa e OCR.
L’aspetto più interessante di AnyDoc, alla fine, non è la velocità in sé. È il segnale che il parsing documenti per agenti AI sta diventando un’infrastruttura commodity: open source, veloce, integrabile con un singolo comando. Quando leggere un DOCX costa meno di 5ms e zero dipendenze esterne, la barriera non è più tecnica. La domanda diventa: cosa fa il tuo agente con quei dati una volta estratti?
È una domanda che vale la pena porsi prima di ottimizzare la pipeline di ingestione. Il parsing più veloce del mondo non compensa un prompt mal progettato o un’architettura RAG che recupera i chunk sbagliati. Nella nostra formazione aziendale è uno dei punti su cui insistiamo di più: l’infrastruttura è importante, ma il valore si crea nello strato sopra.