RAGFlow 1.0 Tutorial: Installation, PDF-Parsing und Praxistest

Inhalt

RAGFlow ist eine Open-Source-RAG-Engine (Apache 2.0), die Dokumente in eine durchsuchbare Wissensbasis verwandelt und Fragen dazu mit Quellenangaben beantwortet. Der Schwerpunkt liegt auf dem schwierigen Teil von RAG: sauberen Text, Tabellen und Layout aus PDFs und Office-Dateien zu holen, bevor überhaupt etwas eingebettet wird. Version 1.0.0 ist am 6. November 2026 erschienen; das Backend wurde dafür in Go neu geschrieben.

Wir haben RAGFlow 1.0 mit dem offiziellen Docker-Compose-Setup installiert, OpenAI-Modelle angebunden und ein echtes Dokument mit vielen Tabellen geladen: den 147 Seiten starken Bericht "Austria. Data. Figures. Facts 2025/26" von Statistik Austria (englische Ausgabe). Kurz gesagt: Die Installation geht schnell, der Chat antwortet mit Quellenangaben bis auf die Seite und sagt ehrlich, wenn er nichts findet. Der eingebaute Parser DeepDoc hat aus genau diesem PDF aber größtenteils Buchstabensalat gemacht. Mit einem Vision-Modell (gpt-4.1-mini) als Parser war das Problem gelöst, und von fünf Testfragen wurden statt zwei alle fünf richtig beantwortet. Dieser Beitrag zeigt Einrichtung, Konfiguration, unsere Messwerte und worauf Sie achten sollten.

Was RAGFlow ist und wann es mehr bringt als ein einfacher Vektorspeicher

Eine minimale RAG-Pipeline (Grundlagen zu RAG, auf Englisch) extrahiert Text aus Dokumenten, teilt ihn in Chunks, legt deren Embeddings in einem Vektorspeicher ab und gibt die besten Treffer an ein Sprachmodell. Bei sauberem Fließtext funktioniert das gut. Steckt das Wissen aber in Tabellen, mehrspaltigen Layouts, gescannten Seiten oder Diagrammen, bringt die Textextraktion Spalten durcheinander, verliert den Bezug zwischen einer Zahl und ihrer Zeilenbeschriftung oder liefert gar nichts.

RAGFlow steckt den Großteil seines Aufwands in diesen ersten Schritt und liefert den Rest als fertige Anwendung mit:

• Parsing mit DeepDoc, einem eigenen Modell-Stack für OCR, Layoutanalyse und Tabellenerkennung. Alternativ lassen sich andere Parser oder ein Vision-LLM einbinden.
• Chunking-Vorlagen für verschiedene Dokumentarten (allgemeiner Text, Tabellen, wissenschaftliche Artikel, Bücher, Gesetze, Frage-Antwort-Paare, Handbücher, Präsentationen).
• Hybride Suche aus Vektor- und Schlagwortsuche, optional mit Reranker.
• Eine Chat-Oberfläche mit Quellenangaben, eine Suchoberfläche, einen visuellen Agenten-Baukasten, eine HTTP-API und einen MCP-Server.
• Eine Chunk-Ansicht, in der Sie neben dem Original sehen, was der Parser aus jeder Seite gemacht hat, und einzelne Chunks abschalten können.

Gegenüber ein paar Dutzend Zeilen LangChain- oder LlamaIndex-Code auf einer Vektordatenbank bekommen Sie ein komplettes System mit einer Oberfläche, die auch Fachabteilungen bedienen können, und jeder Parsing-Schritt lässt sich nachprüfen. Der Preis dafür ist ein größerer Stack (standardmäßig sechs Container) und weniger Kontrolle über Details. RAGFlow passt gut, wenn Sie einem Team rasch ein Frage-Antwort-System für eigene Dokumente auf eigener Infrastruktur bereitstellen wollen und die Dokumente strukturierte PDFs oder Office-Dateien sind. Für ein paar saubere Markdown-Dateien ist es mehr, als Sie brauchen.

So funktioniert RAGFlow

So funktioniert RAGFlow 1.0: Ingestion-Pipeline, Weg einer Frage und die Container des Standard-Stacks

Beim Hochladen schickt der Ingestor-Dienst das Dokument durch eine Pipeline: Der Parser extrahiert Text, Tabellen und Bilder, der Chunker teilt das Ergebnis nach der gewählten Vorlage, ein optionaler Extractor lässt ein Sprachmodell Schlagwörter, Fragen oder Zusammenfassungen ergänzen, und der Indexer schreibt Embeddings und Volltext in die Dokument-Engine (standardmäßig Elasticsearch). Stellt jemand eine Frage, durchsucht der API-Dienst diese Chunks hybrid, gibt die besten an das Sprachmodell und liefert die Antwort mit Verweisen auf die Quell-Chunks und Seiten.

Seit 1.0 läuft all das in einem einzigen Go-Programm im Container ragflow-cpu (API, Admin, Ingestor und Syncer). NATS ist die Aufgabenwarteschlange, Kvrocks der Cache, MySQL speichert Benutzer und Einstellungen, MinIO die hochgeladenen Dateien.

Was sich seit RAGFlow 0.19 geändert hat

Die erste Fassung dieses Beitrags beruhte auf RAGFlow 0.19 vom Mai 2025. Die wichtigsten Änderungen seither laut den offiziellen Release Notes:

Falls Sie eine ältere Version betreiben: Laut Release Notes migriert der 1.0-Container Daten aus v0.27.2 beim Start automatisch, und diese Migration lässt sich nicht rückgängig machen. Ältere Versionen müssen zuerst auf 0.27.2. Sichern Sie vor dem Upgrade.

RAGFlow mit Docker Compose installieren

Das README empfiehlt als Ausgangskonfiguration 4 CPU-Kerne, 16 GB RAM und 50 GB freien Speicherplatz, dazu Docker ab 24.0.0 und Docker Compose ab v2.26.1. Das Go-Backend läuft unter Linux (x86-64 und arm64); macOS wird derzeit nicht unterstützt.

Wenn Sie bei der Standard-Engine Elasticsearch bleiben, prüfen Sie zuerst vm.max_map_count auf dem Docker-Host. Liegt der Wert unter 262144, erhöhen Sie ihn. Die Befehle aus dem README:

1sysctl vm.max_map_count

1# In this case, we set it to 262144:
2sudo sysctl -w vm.max_map_count=262144

Die Änderung mit sysctl -w geht beim Neustart verloren. Damit sie bleibt, tragen Sie vm.max_map_count=262144 in /etc/sysctl.conf ein.

Dann klonen Sie das Repository, wechseln auf das Release-Tag und starten den Stack, ebenfalls laut README:

1git clone https://github.com/infiniflow/ragflow.git
2cd ragflow/docker
3git checkout v1.0.0
4docker compose -f docker-compose.yml up -d

Die Images sind überschaubar: infiniflow/ragflow:v1.0.0 hat 1,16 GB, Elasticsearch 8.11.3 weitere 2,1 GB. Mit bereits geladenen Images meldete unser Stack 17 Sekunden nach up Bereitschaft. Der Health-Check aus dem README:

1curl -f http://localhost/api/v1/system/healthz

1{"db":"ok","redis":"ok","doc_engine":"ok","storage":"ok","message_queue":"ok","status":"ok"}

Danach öffnen Sie http://localhost (oder die IP Ihres Servers), klicken auf "Sign up", legen das erste Konto an und melden sich an.

Diese Standardwerte sollten Sie vorher ändern

Die Standardkonfiguration ist für einen schnellen lokalen Start gedacht. Drei Dinge sollten Sie in docker/.env vor dem ersten Start anpassen, sobald andere den Server erreichen können:

• Passwörter. Die .env beginnt selbst mit "SECURITY WARNING: DO NOT DEPLOY WITH DEFAULT PASSWORDS". Das betrifft ELASTIC_PASSWORD, MYSQL_PASSWORD, MINIO_PASSWORD, REDIS_PASSWORD und ADMIN_DEFAULT_PASSWORD (Standard: admin). Das Admin-Passwort gilt nur beim Anlegen des ersten Superusers; eine spätere Änderung wirkt nicht mehr.

• Ports. Compose veröffentlicht die Weboberfläche (80, 443), die API (9380), den Admin-Dienst (9381) und alle Abhängigkeiten (Elasticsearch, MySQL, MinIO, Kvrocks, NATS) auf allen Netzwerkschnittstellen. Stellen Sie eine Firewall oder einen Reverse Proxy davor, oder binden Sie die Ports mit einer Compose-Override-Datei an 127.0.0.1. So sah unsere Override-Datei aus (die Host-Ports wählen Sie selbst):

  1services:
  2  ragflow-cpu:
  3    ports: !override
  4      - "127.0.0.1:13180:80"
  5      - "127.0.0.1:13181:9380"
  6      - "127.0.0.1:13182:9381"
  7  es01:
  8    ports: !reset []
  9  mysql:
  10    ports: !reset []
  11  minio:
  12    ports: !reset []
  13  kvrocks:
  14    ports: !reset []
  15  nats:
  16    ports: !reset []
  

• Zeitzone. TZ steht standardmäßig auf Asia/Shanghai, daher liegen die Startzeiten in Logs und Dateiliste sieben Stunden vor der Wiener Zeit. Setzen Sie TZ=Europe/Vienna (oder Ihre Zone).

Elasticsearch oder Infinity als Dokument-Engine

Die Dokument-Engine speichert Chunks, Vektoren und den Volltextindex. Standard ist Elasticsearch; als Alternativen nennt die .env Infinity (die eigene Datenbank von InfiniFlow), OpenSearch, OceanBase, seekDB, GaussDB und Vastbase. Elasticsearch ist ausgereift und vielen bekannt. Infinity ist deutlich sparsamer: Im Leerlauf brauchte unser Standard-Stack 5,8 GiB RAM, davon 4,4 GiB allein für Elasticsearch. Mit Infinity kam der ganze Stack auf etwa 1,5 GiB, der Infinity-Container auf 210 MiB.

Gemessen mit docker stats --no-stream alle drei Sekunden. Die Spitze ist die Summe aller Container; beim Parsen mit DeepDoc wuchs allein der RAGFlow-Container auf 4,0 GiB.

Für den Wechsel sagt die FAQ: Stack stoppen, Engine in docker/.env setzen, neu starten (im Wurzelverzeichnis des Repositorys):

1docker compose --env-file docker/.env -f docker/docker-compose.yml down

1DOC_ENGINE=infinity

1docker compose --env-file docker/.env -f docker/docker-compose.yml up -d

Vorhandene Indizes werden nicht übernommen; Sie müssen Ihre Dokumente neu parsen. Entscheiden Sie also, bevor Sie viele Daten laden. Laut README ist es mit Infinity meist nicht nötig, vm.max_map_count zu erhöhen.

OpenAI-Modelle anbinden

RAGFlow bringt keine Modelle mit. Klicken Sie auf Ihren Avatar (oben rechts), dann auf "Model providers", wählen Sie OpenAI, vergeben Sie einen Namen für die Instanz und fügen Sie Ihren API-Schlüssel ein. Nach dem Speichern holt RAGFlow die Modellliste von der API.

OpenAI als Modellanbieter in RAGFlow 1.0; der API-Schlüssel ist verdeckt

Anschließend klicken Sie auf "Set default models". Sie brauchen mindestens ein Sprachmodell für den Chat und ein Embedding-Modell. Wir haben gpt-4.1-mini und text-embedding-3-small verwendet. Die übrigen Felder sind optional: VLM (Vision-Modell für Bilder und, wie sich zeigen wird, für das PDF-Parsing), ASR, Rerank, TTS und das "Decision model", mit dem 1.0 im Agentic mode beurteilt, ob die gefundenen Belege ausreichen.

Standardmodelle: gpt-4.1-mini als Sprachmodell und text-embedding-3-small für Embeddings

Das Standard-Embedding-Modell gilt für neue Datasets. Wer es später wechselt, muss alle Chunks neu einbetten. Wählen Sie also vor dem Hochladen.

Ein Dataset anlegen und die Chunking-Vorlage wählen

Unter "Dataset" klicken Sie auf das Pluszeichen und vergeben einen Namen. Der Dialog fragt außerdem nach dem Embedding-Modell und dem Parsing-Modus: einer der eingebauten Vorlagen oder einer selbst gebauten Ingestion-Pipeline.

Ein Dataset anlegen, mit der Liste der eingebauten Chunking-Vorlagen

Die Vorlagen unterscheiden sich darin, wie sie ein Dokument aufteilen:

Die Konfigurationsseite hat vier Reiter, die der Pipeline entsprechen. "Parser" legt den Parser je Dateityp fest, "General Chunker" die Chunk-Größe (Standard 512 Token, keine Überlappung) und die Trennzeichen, "Extractor" die optionalen LLM-Schritte für Schlagwörter, Fragen, Tags und Zusammenfassungen, und "Indexer", welche Felder durchsucht werden.

Dataset-Konfiguration mit den Reitern Parser, General Chunker, Extractor und Indexer

Den PDF-Parser sollten Sie sich genauer ansehen. Neben DeepDoc bietet das Auswahlfeld Naive (nur die Textebene, kein OCR), Docling, OpenDataLoader, TCADP Parser, MonkeyOCRv2 und jedes eingerichtete Vision-Modell, markiert als "Experimental". Mehrere der externen Parser brauchen einen zusätzlichen Dienst oder ein Cloud-Konto.

Optionen für den PDF-Parser: DeepDOC, Naive, Docling, OpenDataLoader, TCADP Parser, MonkeyOCRv2 und die Vision-Modelle von OpenAI

Lassen Sie die Extractor-Optionen anfangs ausgeschaltet. Jede bedeutet einen zusätzlichen LLM-Aufruf pro Chunk und vervielfacht Indexierungszeit und Kosten. Schalten Sie sie erst ein, wenn Retrieval-Tests zeigen, dass sie ein konkretes Problem lösen.

Wie DeepDoc einen 147-seitigen Statistikbericht geparst hat

Unser Testdokument hat alles, woran PDF-Extraktion scheitert: zweispaltigen Text, über hundert Tabellen, Diagramme, Karten, Fotos und senkrechte Beschriftungen am Rand. Statistik Austria erlaubt die Weiterverwendung mit Quellenangabe, und jede Zahl lässt sich am Original prüfen.

Wir haben es mit den Standardeinstellungen hochgeladen (Vorlage General, Parser DeepDoc) und "Parse on creation" eingeschaltet. Das Log zeigt jeden Schritt:

Parse-Log des Dokuments: 9 Minuten 10 Sekunden insgesamt, fast alles davon im Parser

Das sind etwa 3,6 Sekunden pro Seite. Heraus kamen 510 Chunks: 302 Text-Chunks, 162 Bild-Chunks und 46 Tabellen-Chunks. Beim Parsen nutzte der RAGFlow-Container höchstens etwa 1,8 CPU-Kerne, obwohl der Host 32 Threads hatte. Mehr Kerne haben ein einzelnes Dokument also nicht schneller gemacht.

Einiges hat DeepDoc gut gemacht. Es hat Layoutblöcke und Tabellenbereiche gefunden und Text in Bildern gelesen, etwa die Karte der Bundesländer mit allen Namen, Flächen und Einwohnerzahlen:

Chunk-Ansicht von DeepDoc: die Karte der Bundesländer als Bild-Chunk mit den erkannten Beschriftungen und Zahlen

Das Problem waren der Fließtext und die meisten Tabellen. Auf dem Großteil der Seiten lieferte DeepDoc Buchstabensalat: einzelne Zeichen aus verschiedenen Zeilen und Spalten durcheinander, Wörter ohne Leerzeichen zusammengeschrieben. Im nächsten Screenshot ist der Tabellenbereich "Tyrol at a glance" richtig erkannt (links markiert), der Zellinhalt rechts aber unbrauchbar:

Chunk-Ansicht von DeepDoc: Die Tabelle "Tyrol at a glance" ist erkannt, ihr Text aber verstümmelt

Das liegt am Dokument, nicht an DeepDoc im Allgemeinen. Fünf Seiten einer Eurostat-Publikation kamen in derselben Installation als lesbarer Text heraus, samt Diagrammbeschriftungen. Das PDF von Statistik Austria hat eine gültige Textebene (pdftotext liest sie sauber aus), kleine quadratische Seiten, schmale Schriften und gedrehte Beschriftungen am Rand. Welcher dieser Punkte DeepDoc aus dem Tritt bringt, haben wir nicht herausgefunden. Die Option "Detect multi-column layout" hat am Ergebnis nichts geändert.

Naive und ein Vision-LLM als Alternativen

Drei typische Seiten haben wir mit den beiden anderen Parsern erneut verarbeitet, die keinen zusätzlichen Dienst brauchen:

Danach haben wir das ganze Dokument mit gpt-4.1-mini als PDF-Parser verarbeitet. Das dauerte 11 Minuten 9 Sekunden und ergab 110 Chunks mit 57.203 Token Text, gegenüber 510 Chunks und 145.734 Token bei DeepDoc. Der Größenunterschied ist vor allem das Rauschen, das DeepDoc erzeugt hat. Das Vision-Modell liefert jede Seite als Markdown, Tabellen bleiben also Tabellen:

Chunk aus dem gpt-4.1-mini-Parser: "Vorarlberg at a glance" als Markdown-Tabelle neben der Originalseite

Ein Vision-Modell kostet einen API-Aufruf pro Seite plus die Bild-Token, und die Option ist als experimentell markiert. Für einige hundert Seiten ist das günstig; bei Hunderttausenden Seiten rechnen Sie vorher nach. Wie derselbe Ansatz ohne RAGFlow funktioniert, zeigt unser Beitrag zur Dokumentenextraktion mit LLMs.

Ein Chat-Assistent mit Quellenangaben

Unter "Chat" legen Sie eine Chat-App an, öffnen deren Einstellungen (Zahnradsymbol oben rechts) und wählen das Dataset. Für den Anfang passen die Standardwerte: das Standard-Sprachmodell, "Show citations" eingeschaltet und der Modus-Schalter im Eingabefeld auf "Naive" (klassisch: suchen, dann antworten). Mit "Agentic" sucht das Modell in mehreren Schritten.

Wir haben pro Dataset einen Chat angelegt und dieselben fünf Fragen gestellt, jede in einer neuen Unterhaltung. Die Antworten haben wir am PDF geprüft (die Fragen waren englisch, wie das Dokument):

Mit dem DeepDoc-Dataset hat der Chat 2 von 5 Fragen beantwortet. Beide Antworten stammen aus der Bevölkerungstabelle auf Seite 13, einer der wenigen Tabellen, die DeepDoc richtig gelesen hat. Auf die anderen drei kam "The answer you are looking for is not found in the dataset!", ohne dass das Modell etwas erfunden hätte. Mit dem gpt-4.1-mini-Dataset waren alle fünf Antworten richtig; zwei hat das Sprachmodell gerundet, in den geparsten Tabellen stehen die genauen Werte.

Jede Antwort trägt nummerierte Quellenangaben. Fahren Sie mit der Maus darüber, zeigt RAGFlow den Chunk und eine Vorschau der Quellseite:

Chat-Antwort mit Quellenangabe: Beim Überfahren von [1] erscheint der Quell-Chunk "Vorarlberg at a glance"

Jede Antwort dauerte 1,4 bis 2,8 Sekunden und verbrauchte etwa 4.500 bis 9.400 Eingabe-Token; RAGFlow 1.0 zeigt beides unter jeder Antwort an. Fünf Fragen sind eine Stichprobe, keine Evaluation. Wie Sie Retrieval und Antwortqualität systematisch prüfen, zeigt unser Beitrag RAG-Qualität messen mit Ragas.

Agenten, MCP und die API

Der Chat ist nur ein Weg, ein Dataset zu nutzen. Der Agenten-Baukasten bietet Vorlagen wie einen Dataset-Chatbot, einen Deep-Research-Agenten und einen Assistenten für Aktienrecherche, und Agenten können externe MCP-Server als Werkzeuge aufrufen.

RAGFlow ist auch selbst ein MCP-Server: Die API stellt POST /api/v1/mcp mit den Werkzeugen ragflow_retrieval, ragflow_list_datasets und ragflow_list_chats bereit, abgesichert mit einem RAGFlow-API-Schlüssel (Avatar, "API", "API Key"). Das Beispiel aus der Dokumentation, das die Werkzeuge auflistet:

1curl -sS http://127.0.0.1:9380/api/v1/mcp \
2  -H 'Authorization: Bearer <RAGFLOW_API_KEY>' \
3  -H 'Content-Type: application/json' \
4  -H 'Accept: application/json, text/event-stream' \
5  -d '{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}'

In unserer Installation kamen genau diese drei Werkzeuge zurück, und ein Aufruf von ragflow_retrieval mit Frage und Dataset-ID lieferte die passenden Chunks als JSON. So nutzen Sie ein RAGFlow-Dataset aus Claude, einem IDE-Agenten oder Ihrem eigenen Agenten-Framework, ohne die RAGFlow-Oberfläche anzufassen. Den Rest deckt die HTTP-API ab (Datasets, Upload, Parsing, Chunks, Chats). Version 1.0 hat veraltete API-Aliase entfernt; prüfen Sie ältere Skripte deshalb gegen die API-Referenz.

Grenzen und Stolpersteine

• Die Parsing-Qualität hängt vom Dokument ab. DeepDoc ist an unserem Bericht gescheitert und hat bei einem anderen funktioniert. Laden Sie fünf typische Seiten jeder Dokumentart hoch, öffnen Sie die Chunk-Ansicht und lesen Sie die Chunks, bevor Sie alles laden.
• DeepDoc läuft in der Open-Source-Version 1.0 nur auf der CPU und nutzte in unserem Test weniger als zwei Kerne pro Dokument. Rechnen Sie mit einigen Sekunden pro Seite; große Archive brauchen Stunden. Ein Vision-Modell als Parser ist pro Dokument nicht schneller (11 Minuten für 147 Seiten), verlagert die Last aber auf die API.
• Ressourcen: Planen Sie mit Elasticsearch 6 bis 10 GiB RAM ein, oder nehmen Sie Infinity. MEM_LIMIT in der .env begrenzt jeden einzelnen Container (Standard etwa 7,5 GiB), nicht den ganzen Stack.
• Sechs Container und viele Einstellungen. RAGFlow versteckt vieles davon hinter der Oberfläche, aber Updates, Backups (MySQL, MinIO und die Dokument-Engine) und Migrationen bleiben beim Selbstbetrieb Ihre Aufgabe.
• Upgrades von 0.x gehen nur in eine Richtung. Sichern Sie vorher.

Unsere Einschätzung

RAGFlow 1.0 ist eine vollständige RAG-Anwendung, die Sie in weniger als einer Stunde auf dem eigenen Server betreiben: Upload, Parsing, hybride Suche, ein Chat mit verlässlichen Quellenangaben, Agenten, HTTP-API und MCP. Durch die Neuentwicklung in Go ist der Stack spürbar schlanker geworden, besonders mit Infinity. Im Alltag ist die Chunk-Ansicht die nützlichste Funktion, weil sie sofort zeigt, ob ein Dokument verstanden wurde.

Unser Test zeigt aber auch: "Deep document understanding" ist keine Garantie. Der Standard-Parser kann an einem ganz normalen PDF scheitern, und RAGFlow indexiert den Datenmüll ohne Warnung. Der Chat antwortet dann "nicht gefunden", was ehrlich ist, aber nicht weiterhilft. Wenn Ihre Dokumente unterschiedlich aufgebaut sind, planen Sie Zeit ein, um Parser je Dokumentart zu testen, und ziehen Sie für die schwierigen ein Vision-Modell in Betracht.

Wenn Sie statt eines selbst betriebenen Stacks eine verwaltete Lösung in Azure suchen, beschreibt unser Beitrag zu RAG mit Azure AI Search diesen Weg. Und wenn Sie vor allem eine Chat-Oberfläche für Ihre Modelle brauchen, lohnt ein Blick auf Open WebUI.

Wir unterstützen Unternehmen dabei, RAG-Systeme für ihre eigenen Dokumente auszuwählen und aufzubauen, vom Parser-Test bis zum produktiven Betrieb. Wenn Sie RAGFlow oder eine eigene Lösung prüfen, sprechen Sie mit unserer KI-Beratung in Vorarlberg.

Testdokument: Statistik Austria, "Austria. Data. Figures. Facts 2025/26" (Wien, 2026). Die Screenshots zeigen Ausschnitte des Dokuments, wie RAGFlow sie darstellt.

Sie möchten zuverlässige KI-Agenten-Systeme bauen?

Wir haben auf Basis aktueller Forschung einen ausführlichen Leitfaden (auf Englisch) erstellt, wie Sie robuste KI-Agenten-Systeme bauen, die auch im produktiven Betrieb funktionieren. Der Leitfaden behandelt:

• die 14 systematischen Fehlerquellen in Multi-Agenten-Systemen
• belegte Best Practices für das Design von Agenten
• strukturierte Kommunikationsprotokolle und Prüfmechanismen

Über den Autor

Andreas Nigg

Mitgründer, Pondhouse Data

Andreas entwickelt seit mehr als acht Jahren Datenanwendungen. Bei Pondhouse Data konzipiert und baut er KI-Systeme und integriert sie in komplexe, gewachsene Unternehmensumgebungen.

Sprechen Sie mit Andreas über Ihr ProjektAuf LinkedIn folgen