Document Intelligence + AI Search Indexer: RAG ohne Custom-Code

Pexon Consulting | 11 Min. Lesezeit | 15.06.2026

TL;DR

Document Intelligence plus AI Search Indexer ersetzt 4-6 Monate Custom-Python-Code durch eine deklarative Skillset-Pipeline. Pexon Consulting baut diese Azure-native RAG-Pipelines in 3 Wochen als Festpreis-Sprint zwischen 24 und 42k EUR mit SharePoint-Anbindung und Entra-ID-Permission-Integration. Code-Volumen unter 500 LOC statt 4.000-8.000 LOC im Eigenbau.

Was die Azure-native Pipeline strukturell anders macht

Wir sehen in CIO-Erstgesprächen ein wiederkehrendes Muster: Das Engineering-Team hat 4 Monate in eine RAG-Pipeline mit LangChain, PyPDF, Unstructured.io und einer Vector-DB investiert — und produziert beim nächsten Vertragsformat trotzdem Parse-Fehler. Der Custom-Code-Pfad funktioniert, ist aber pflege-intensiv. Bei den meisten Mittelständlern überfordert er das Engineering-Team.

Die Azure-native Alternative seit 2024 produktionsreif: Document Intelligence (früher Form Recognizer) als Parser-Layer, AI Search Indexer mit Skillset als Pipeline-Orchestrator. Beide Services laufen managed, lesen direkt aus Storage-Accounts, schreiben in einen Search-Index. Embeddings via integrierte Vectorization. Custom-Code bleibt minimal.

Die Architektur in einem Diagramm.

Bei jedem neuen Dokument im Storage-Account triggert der Indexer automatisch: Parse durch Document Intelligence, Chunking, Embedding, Index-Schreibvorgang. Inkrementell, mit Change-Detection. Bei 25.000 Dokumenten dauert der Initial-Lauf typisch 3-8 Stunden, die kontinuierliche Verarbeitung im Sekunden-Bereich pro neuem File.

Die Document Intelligence-Modelle im Überblick

Welches Modell für welchen Use-Case.

Layout-Modell. Das Allzweck-Pferd. Erkennt Strukturen wie Überschriften, Tabellen, Listen, Schlüssel-Wert-Paare in beliebigen Dokumenten. Funktioniert bei PDFs, Word-Dokumenten, Bildern (OCR integriert). Für 70-80% der RAG-Anwendungsfälle ist das Layout-Modell die richtige Wahl.

Read-Modell. Reines OCR. Schneller und günstiger als Layout, aber ohne Struktur-Erkennung. Geeignet wenn Dokumente ohnehin reiner Text sind und ihr nur das OCR braucht. Für RAG selten optimal.

Prebuilt-Modelle. Vortrainierte Modelle für Rechnungen, Quittungen, Ausweise, Verträge, Kontoauszüge. Wenn euer Use-Case eines dieser Standard-Dokumente ist, ist Prebuilt der schnellste Pfad — Setup typisch 1 Tag, Genauigkeit produktionsreif. Mehr zur Pexon-Document-Intelligence-Praxis im Vergleich zu Custom-Pipelines.

Custom-Modelle. Eigene Trainings für domain-spezifische Dokumente. Für 80% der speziellen Anforderungen (Lastenhefte, Werkstoff-Datenblätter, Sicherheitsdatenblätter) sinnvoll. Training-Aufwand 5-15 Trainings-Dokumente plus 1-2 Tage Engineering. Wir bauen das oft als Erweiterung der initialen Pipeline.

Wichtige Faustregel: Beim ersten RAG-Setup mit Layout-Modell starten. Custom-Modelle nur bauen, wenn das Layout-Modell konkret nicht ausreicht — nicht prophylaktisch.

Das Skillset im Detail

Wo die Magie passiert. Skillset ist die deklarative Pipeline-Definition in AI Search — JSON-Konfiguration, kein Code.

{
  "name": "rag-pipeline-skillset",
  "skills": [
    {
      "@odata.type": "#Microsoft.Skills.Util.DocumentIntelligenceLayoutSkill",
      "outputMode": "oneToMany",
      "inputs": [{"name": "file_data", "source": "/document/file_data"}],
      "outputs": [
        {"name": "markdown_document", "targetName": "markdown_document"}
      ]
    },
    {
      "@odata.type": "#Microsoft.Skills.Text.SplitSkill",
      "textSplitMode": "pages",
      "maximumPageLength": 2000,
      "pageOverlapLength": 200,
      "inputs": [{"name": "text", "source": "/document/markdown_document/content"}],
      "outputs": [{"name": "textItems", "targetName": "chunks"}]
    },
    {
      "@odata.type": "#Microsoft.Skills.Text.AzureOpenAIEmbeddingSkill",
      "resourceUri": "https://your-aoai.openai.azure.com",
      "deploymentId": "text-embedding-3-large",
      "modelName": "text-embedding-3-large",
      "dimensions": 1536,
      "inputs": [{"name": "text", "source": "/document/chunks/*"}],
      "outputs": [{"name": "embedding", "targetName": "vector"}]
    }
  ]
}

Was das konkret leistet. Document Intelligence Layout-Skill liest das Original-Dokument und produziert strukturiertes Markdown. Split-Skill chunked auf 2.000-Token-Stücke mit 200-Token-Overlap. Azure OpenAI Embedding-Skill erzeugt 1536-dimensionale Vektoren. Alles ohne eine einzige Zeile Custom-Code — die Konfiguration ist die Pipeline.

Output im Search-Index. Jeder Chunk landet als eigener Index-Eintrag mit: Originaltext, Vektor, Source-Document-ID, Page-Number, Layout-Metadata (z.B. ist-Tabelle, ist-Überschrift). Damit ist die Treffer-Erklärung in der RAG-Antwort einfach: „Antwort basiert auf Seite 47 des Dokuments XY“.

Wann der No-Code-Pfad reicht — und wann nicht

Ehrlicher Blick auf die Grenzen.

Pfad reicht klar: PDF-, Word-, Excel-Dokumente in Standard-Formaten. Verträge, Berichte, Handbücher, Wikis, FAQs. Bilder mit Text (OCR via Layout-Modell). Bei einem Industrie-Kunden haben wir die Pipeline für 12.000 technische Handbücher (PDF) aufgesetzt — 8 Tage Engineering, danach lief die Pipeline kontinuierlich.

Pfad reicht mit Custom-Skill: Wenn ihr im Pipeline-Lauf domain-spezifische Logik braucht (z.B. PII-Maskierung, Glossar-Annotation, Kategorisierung). Custom-Skills sind eigene Azure Functions, die das Skillset aufruft. Code-Volumen typisch 100-400 LOC pro Custom-Skill.

Pfad reicht NICHT, Custom-Code besser: Wenn euer Dokumenten-Bestand sehr inhomogen ist (zu wenige Trainings-Daten pro Custom-Modell), wenn ihr extreme Performance-Anforderungen habt (>1.000 Anfragen pro Sekunde), wenn ihr außerhalb der Azure-Welt persistieren wollt (z.B. on-prem Vector-DB). Mehr zur Vector-DB-Wahl zwischen Azure AI Search und pgvector.

Pfad reicht NICHT, andere Stack-Wahl besser: Bei harten Datenresidenz-Anforderungen außerhalb der Azure-Cloud (z.B. KRITIS-Tier-1 mit on-prem Zwang) ist Document Intelligence in der Cloud-Variante schwierig — dann braucht ihr on-prem Document AI. Wir bauen das mit Custom-Modellen auf eigenen GPU-Servern.

Die Kosten transparent

Ein Punkt, der bei der Architektur-Entscheidung oft zu spät kommt.

Document Intelligence Layout-Modell: 30 USD pro 1.000 Seiten (Stand 2026, USA-Region; EU-West leicht teurer). Bei 25.000 Dokumenten mit Ø 15 Seiten = 11.250 USD Einmal-Verarbeitungskosten. Inkrementelle Verarbeitung danach typisch < 50 USD pro Monat.

Azure OpenAI Embeddings (text-embedding-3-large): 0,13 USD pro Million Tokens. Bei 25.000 Dokumenten Ø 8.000 Tokens = 200M Tokens = 26 USD Einmal-Kosten.

Azure AI Search Standard S1: 250 USD pro Monat für bis zu 25 GB Index plus Skillset-Ausführung. Reicht für ~5M Chunks.

Skillset-Ausführung: Sub-Skill-Kosten (z.B. Layout-Skill-Calls aus dem Skillset) zählen wie direkte API-Calls. In den Verarbeitungs-Kosten oben enthalten.

Custom-Skill Azure Functions: Marginal — wenige USD pro Monat bei Standard-Volumen.

Gesamtbild für 25.000 Dokumente Ø 15 Seiten:

• Initial-Setup-Verarbeitung: ~11.300 USD einmalig
• Laufende Cloud-Kosten: 300-450 USD pro Monat (Search S1 plus Inkrementell)
• Pexon-Sprint-Engineering: 24-42k EUR

Ein typischer Mittelständler bewegt sich für eine produktive RAG-Pipeline mit 5.000-30.000 Dokumenten zwischen 30k-55k EUR All-in im ersten Jahr.

Pexon-Sprint im Detail

Wochen 1: Discovery (Dokumenten-Inventur, Format-Analyse, Quellen-System-Anbindung), Architektur-Workshop, Skillset-Design.

Wochen 2: Initial-Setup von Document Intelligence, AI Search Index, Skillset-Definition, Initial-Verarbeitungs-Lauf. Erstes RAG-Demo-Frontend lauffähig.

Wochen 3: Permission-Layer-Integration (siehe Entra-ID-Permission-Pattern), Audit-Trail-Pipeline, Übergabe-Workshop für Engineering-Team.

Investment 24-42k EUR Festpreis je nach Komplexität. Bei sehr inhomogenen Dokumenten-Beständen (Custom-Modell-Training erforderlich) eher am oberen Ende.

Häufig gestellte Fragen

Was bei nicht-Microsoft-Stack — gibt es vergleichbare Optionen auf AWS?

Ja. AWS hat Textract als DI-Äquivalent und Kendra als Search-Service. Funktional ähnlich, aber das Skillset-Konzept ist Azure-spezifisch — auf AWS baut ihr die Pipeline-Orchestrierung manuell mit Step Functions oder Lambda. Engineering-Aufwand auf AWS typisch 30-50% höher als der Azure-No-Code-Pfad. Wir setzen auf beiden Clouds um, empfehlen für No-Code-Fokus klar Azure.

Kann ich Document Intelligence on-prem betreiben?

Bedingt ja, über Azure Arc oder Document Intelligence Containers. Setup deutlich komplexer als Cloud-Variante, weniger Modell-Vielfalt. Bei harten On-Prem-Anforderungen empfehlen wir oft Custom-Modelle auf eigenen GPU-Servern — siehe Compute-Strategie Cloud vs On-Prem.

Wie verhält sich die Pipeline bei sehr großen Dokumenten?

Document Intelligence verarbeitet PDFs bis 500 MB. Bei extrem langen Dokumenten (>2.000 Seiten) lohnt sich eine Pre-Processing-Stufe, die das Dokument in Kapitel-PDFs splittet. Damit bleibt die DI-Verarbeitung im stabilen Bereich.

Was mit handgeschriebenen Notizen oder schlecht gescannten Dokumenten?

Layout-Modell hat OCR mit Handwriting-Support, funktioniert auf gut leserlichen Notizen. Bei sehr unsauberen Scans (Fax-Qualität, Rauschen) sinkt die Erkennung — typisch unter 85% Genauigkeit. Wir empfehlen in solchen Fällen Pre-Processing-Stufen (Bild-Bereinigung, Deskewing).

Wie verhält sich das zur RAG-Qualität im Vergleich zu Custom-Pipelines?

In unseren produktiven Setups sehen wir Antwort-Genauigkeit (Faithfulness) im gleichen Bereich wie bei Custom-Pipelines mit LangChain plus pgvector — wenn die Document-Intelligence-Modellwahl passt. Die Pipeline ist das Tool, nicht die Antwort-Qualität. Treffer-Relevanz hängt primär an Embedding-Wahl, Chunk-Strategie und Re-Ranking — alles in beiden Pfaden konfigurierbar.

Nächster Schritt

Wenn dein Engineering-Team gerade in einer RAG-Pipeline mit LangChain steckt und überlegt, ob der Azure-Native-Pfad schneller wäre: Wir machen einen 60-Minuten-Architektur-Call mit dir und idealerweise dem Engineering-Lead. Du beschreibst den Dokumenten-Bestand und die aktuellen Pain-Points, wir skizzieren den 3-Wochen-Sprint mit Festpreis.

Verwandte Themen