RAG-Pipeline für Medtech: Interne Wissenssuche mit pgvector in 8 Wochen

Das Problem der fragmentierten Wissensbasis im Medtech

In der österreichischen Medtech-Branche stagniert die operative Effizienz oft bei der Informationsbeschaffung. Mitarbeiter in HR und Recruiting verbringen bis zu 30 Prozent ihrer Arbeitszeit damit, relevante Informationen aus verstreuten Quellen wie Google Drive, Confluence oder alten E-Mail-Threads zu extrahieren. Bei einer Unternehmensgröße von 201 bis 500 Mitarbeitern fehlt häufig die Skalierung, um diese manuelle Recherche durch zusätzliche Headcount zu kompensieren, ohne die Kostenstruktur zu sprengen.

Der Kern des Problems ist nicht das Fehlen von Daten, sondern die fehlende semantische Verknüpfung. Dokumente liegen in siloartigen Strukturen vor, und die Suche basiert auf exakten Schlüsselwort-Treffern. Ein RAG-System (Retrieval-Augmented Generation) löst dieses Problem, indem es die semantische Ähnlichkeit zwischen einer natürlichen Sprachfrage und dem Dokumentenkorpus berechnet. Der folgende Abschnitt beschreibt die technische Architektur, die es ermöglicht, diese Suche in einem 8-Wochen-Piloten produktiv zu betreiben, ohne bestehende Systeme zu ersetzen.

Technische Mechanik: RAG-Pipeline mit pgvector

Die Architektur basiert auf einer drei-schichtigen Pipeline: Ingestion, Retrieval und Generation. Bei der Ingestion werden Dokumente aus Google Workspace (Docs, Sheets, Mail) über die Google Workspace API abgerufen. Die Texte werden in Chunks von 512 Token aufgeteilt und mit einem Multilingual-Embedding-Modell (z. B. BGE-M3) in 1024-dimensionale Vektoren transformiert. Diese Vektoren werden in einer PostgreSQL-Instanz mit dem pgvector-Extension gespeichert.

[Query] -> [Embedding] -> [pgvector Search] -> [Top-K Chunks] -> [LLM Prompt] -> [Answer]

Das Retrieval nutzt den HNSW-Index (Hierarchical Navigable Small World) in pgvector für eine Suche in unter 50 ms bei 100.000 Vektoren. Die Top-5-Chunks werden zusammen mit der User-Frage an ein LLM (z. B. GPT-4o oder ein lokales Llama-3-8B) übergeben. Das Modell generiert die Antwort und zitiert die Quellen. Für die Dokumentenextraktion aus PDFs wird ein OCR-Pipeline mit Tesseract und einem Layout-Analyse-Modell eingesetzt, um Tabellen und Metadaten strukturiert zu extrahieren.

Trade-offs: Cloud-APIs versus On-Premise-Modelle

Die zentrale architektonische Entscheidung ist die Modell-Agnostik. Für die Generierung von Antworten auf interne HR-Fragen, die keine sensiblen Gesundheitsdaten enthalten, ist die Nutzung von OpenAI- oder Anthropic-APIs wirtschaftlich sinnvoll, da die Latenz unter 200 ms liegt und die Qualität hoch ist. Sobald jedoch Patientendaten oder vertrauliche Medtech-Spezifikationen verarbeitet werden, muss das System auf Open-Weight-Modelle (z. B. Mistral-7B oder Llama-3) auf eigener Hardware umschalten, um die Datenhoheit zu wahren.

Ein weiterer Trade-off betrifft die Chunk-Größe. Kleine Chunks (256 Token) liefern präzisere Treffer, erhöhen aber die Wahrscheinlichkeit, dass Kontext verloren geht. Große Chunks (1024 Token) erhalten mehr Kontext, führen aber zu verrauschten Retrieval-Ergebnissen. In der Praxis hat sich eine hybride Strategie bewährt: 512 Token mit 50 Token Overlap. Die Kosten für die Vektorisierung liegen bei ca. 0,001 EUR pro 1.000 Token, was für einen Korpus von 10.000 Dokumenten eine einmalige Kosten von ca. 50 EUR ergibt.

Empfehlung: Gestaffelter Rollout für den 8-Wochen-Piloten

Für Unternehmen in der beschriebenen Konstellation empfiehlt sich ein gestaffelter Ansatz. Der 8-Wochen-Pilot sollte sich auf die interne Wissenssuche beschränken, da dieser Use Case die geringste Compliance-Hürde hat und den schnellsten ROI liefert. Die Integration in Google Workspace erfolgt über eine Chrome-Extension oder ein Sidebar-Plugin, das die Frage direkt im Browser beantwortet, ohne den Workflow zu unterbrechen.

Die Messung des Erfolgs basiert auf zwei Metriken: der Reduktion der Suchzeit (Baseline: 12 Minuten pro Anfrage, Ziel: unter 2 Minuten) und der Fehlerquote bei der Dokumentenextraktion (Baseline: 8 %, Ziel: unter 2 %). Nach dem Piloten wird das System in den Managed-Service überführt, der für Updates der Embeddings, Monitoring der Latenz und Anpassung der Prompts verantwortlich ist. Dieser Ansatz ermöglicht es, die operativen Skalierungseffekte zu nutzen, ohne neue Headcount in der IT zu schaffen.