Case Study

DataPizza AI

Un framework Python GenAI per agenti e pipeline RAG pronti per la produzione, con astrazione minima.

Progetto OSS attivo Python GenAI RAG Agents OpenTelemetry
Logo del progetto DataPizza AI

Anatomia del sistema

  1. Input

    • LLM provider keys
    • PDF / DOCX / image docs
    • Natural-language prompts
    • Tool / function definitions
  2. Core

    • Multi-provider LLM client
    • Tool-calling agent loop
    • Document ingestion + chunking
    • Qdrant vector search
  3. Output

    • Agent responses + tool results
    • RAG-grounded answers
    • Persistent conversation state
    • OpenTelemetry traces
Vincoli
  • Vendor-agnostic by design
  • No hidden abstraction
  • Provider swap without logic rewrite
  • Observable throughout

Perché esiste

La maggior parte dei framework GenAI esagera con la magia: grandi astrazioni che crollano quando hai bisogno di capire cosa sta succedendo davvero tra la chiamata al modello e il risultato. DataPizza AI parte dalla direzione opposta — tieni la superficie piccola, tieni i provider intercambiabili, e rendi il tracing abbastanza esplicito da permettere a un team di fare debug su una pipeline RAG che fallisce senza dover leggere gli interni del framework.

Centro tecnico

Il framework stratifica un layer di client LLM multi-provider (OpenAI, Gemini, Anthropic, Mistral, Azure) sotto agenti con tool-calling, poi sopra una pipeline di ingestion e chunking documentale (Docling, Azure Document Intelligence) che alimenta una ricerca vettoriale su Qdrant con embedder Cohere o FastEmbed e reranking opzionale. Redis caching e tracciamento OpenTelemetry girano su tutti i layer. La disciplina architetturale è che lo switch di provider, la composizione degli agenti e il cablaggio della pipeline avvengono tutti in modo dichiarativo senza riscrivere la business logic.

Prove correnti

Cinque PR unite coprono i layer in cui il mandato di meno astrazione del framework crea più attrito nella pratica. La PR #55 ha aggiunto il supporto Bedrock async (a_invoke e a_stream_invoke via aioboto3) per sbloccare i pattern applicativi async-first. La PR #67 ha corretto IngestionPipeline.run() per accettare effettivamente una lista di file path come prometteva la sua stessa firma documentata. La PR #77 ha aggiunto un parametro metadata ad AzureParser e DoclingParser con validazione del tipo a runtime, così le pipeline possono passare contesto attraverso il layer di ingestion senza incorrere in un TypeError. La PR #97 ha introdotto un async context manager su MCPClient per sessioni persistenti, fondamentale per i server MCP stateful che mantengono connessioni database o stato di autenticazione tra le chiamate agli strumenti. La PR #106 ha rifattorizzato FastEmbedder per usare il batch processing nativo di fastembed e asyncio.to_thread() — eliminando logica duplicata e correggendo il percorso async in modo che l'I/O bloccante non giri più sull'event loop.