Text Link
黒
衣
黒
衣
1/5

Gewünschte Leistung

AUFTRAGSDETAILS

2/5

INVESTITIONSRAHMEN

3/5

ZEITRAHMEN

4/5

KONTAKTDATEN

Ihre Angaben verwenden wir ausschließlich zur Bearbeitung Ihrer Anfrage. Einzelheiten in unserer Datenschutzerklärung.

5/5

VIELEN DANK

                    Unser AI-Agent war schnell: Die Antwort auf Ihren Erstkontakt liegt bereits in Ihrem Postfach.

FEHLER

VIELEN DANK!

                    Wir werden uns in Kürze bei Ihnen melden.

001JAPANISCHES TEXTILUNTERNEHMEN · 2025–2026

RAG-Wissensagent für Japanisch und Thai: 0,9 von 1,0 im Selbsttest

0,9
VON 1,0 IM SELBSTTEST
Ein Textilunternehmen mit Sitz in Osaka und Werken in Thailand wollte eine Frage stellen und eine belegte Antwort bekommen, egal ob die Quelle auf Japanisch, Englisch oder Thai vorlag. Kuroko Labs baute dafür einen Wissensagenten: Ein Planer zerlegte jede Frage, sieben Suchkanäle liefen parallel, eine Rangliste führte sie zusammen, und ein Sprachmodell formulierte die Antwort mit Fundstelle. Einfache Fragen kamen in unter vier Sekunden zurück, Analysen über mehrere Dokumente in unter 35. Im Selbsttest über 100 Szenarien erreichte das System 0,9 von 1,0. Die Phase lief von 2025 bis Juni 2026, danach verlagerte der Kunde den Schwerpunkt auf Meetings und Zertifizierung.
KUNDE
Japanisches Textilunternehmen
JAHR
2025–2026
BRANCHE
Textilfertigung
STANDORT
Japan · Thailand
5
KI-Provider
Anthropic, OpenAI, Cohere, Mistral, Unstructured.io
7
Retrieval-Kanäle
Vektor, Volltext, Tabular, E-Mail, Graph, Entity, Kanban
4
Antwort-Tiers
Flash unter 4 s bis Deep unter 35 s
2
Sprachen
Japanisch und Thai
0,9
Self-Test-Score
100 Szenarien, 83 ohne Dubletten, gegen das laufende System
ALLE CASE STUDIES
01 · AUSGANGSLAGE

Alles war dokumentiert. Gefunden hat es niemand.

Der Kunde fertigt in Thailand für Modemarken und steuert das Geschäft aus Osaka. Vorgaben kommen auf Japanisch, Berichte aus dem Werk auf Thai oder Englisch. Dazwischen liegen SharePoint, Postfächer und Excel-Mappen mit dutzenden Blättern.
Gesucht wurde trotzdem per Zuruf. Wer den Stückpreis eines Artikels brauchte, fragte drei Kollegen und bekam am Ende eine veraltete Datei. Die Suche in SharePoint half wenig, weil Japanisch keine Leerzeichen kennt: Wer 生産 eingibt, findet 生産管理 nicht, obwohl es dasselbe Thema ist.
Die Sprachgrenze verlief mitten durch die Firma. Osaka konnte die thailändischen Prüfberichte nicht lesen, das Werk nicht die japanischen Vorgaben.
Gewünscht war kein Chatbot. Gewünscht war eine Antwort mit Fundstelle, in der Sprache der Frage, aus allen drei Sprachen des Bestands.
∞
Verstreute Ablage
SharePoint, Postfächer, Meeting-Transkripte, Excel-Mappen mit dutzenden Blättern
2
Sprachbarriere
Japanisch und Thai ohne gemeinsamen Index, Japanisch ohne Leerzeichen
!
Suche per Zuruf
Eine Stunde Slack hin und her, am Ende die falsche Dateiversion
0
Firmengedächtnis
Zwei Länder, zwei Arbeitssprachen, kein gemeinsamer Speicher
02 · LÖSUNG

Wie durchsucht man Unternehmenswissen auf Japanisch und Thai?

Eine einfache Vektorsuche hätte nicht gereicht. Kuroko Labs baute eine dreistufige RAG-Pipeline: Ein Planer zerlegte die Frage, bis zu sieben Suchkanäle liefen parallel und wurden zu einer Rangliste verschmolzen, und vier Antwortstufen legten fest, wie tief und wie teuer eine Antwort werden durfte.
Erste Stufe war der Query Planner, ein kleines Modell (gpt-4o-mini) mit rund 300 Millisekunden Laufzeit. Er kannte Markencodes, Produkttypen, Partnernamen und die üblichen Namen der Excel-Blätter. Aus jeder Frage machte er einen Plan: eine Suchanfrage in der Originalsprache für die Vektorsuche, Stichwortketten auf Japanisch, Englisch und Thai für die Volltextsuche, erkannte Produktcodes als harte Filter, dazu eine Einstufung der Schwierigkeit. Namen wie „mori-san“ löste er über das Mitarbeiterverzeichnis in die Kanji-Schreibweise auf. Wiederholte Fragen beantwortete ein Redis-Cache in unter 30 Millisekunden.
Zweite Stufe: sieben Kanäle gleichzeitig. pgvector für die Bedeutung, PGroonga für den exakten Wortlaut im Japanischen, LightRAG für Beziehungen zwischen Lieferanten, Produkten und Berichten, dazu je nach Frage die Suche in Tabellenzeilen, Postfächern, Personen und Aufgabenkarten. Die Gesamtzeit war die des langsamsten Kanals, nicht die Summe. Reciprocal Rank Fusion führte die Listen zusammen, mit höchstens drei Treffern je Dokument, damit keine einzelne Datei alles dominierte. Cohere Rerank traf die letzte Auswahl. Ein Wörterbuch mit über 40 Begriffsgruppen übersetzte zwischen Japanisch und Englisch, damit eine japanische Frage auch englische Dokumente fand.
Der schwierigste Teil war die japanische Volltextsuche. PGroonga zerlegt Text in überlappende Zweizeichen-Fragmente. Eine Suche nach „品質管理“ traf so auch „品質管理報告書“, ohne Wörterbuch und ohne Morphologie. Eine Funktion in Supabase löste japanische Partikel zu Oder-Verknüpfungen auf. Erfahrene japanische Nutzer waren überrascht, was die Suche fand.
Gefüttert wurde der Index aus vier Quellen: SharePoint über einen Delta-Abgleich mit Microsoft Graph, inklusive der Berechtigungen, so dass jeder nur sah, was er auch in SharePoint sehen durfte. Postfächer über einen zweistufigen Relevanzfilter. Meeting-Transkripte per Webhook. Und der Upload im Browser. Mistral OCR las PDFs bis 35 MB, auch gescannte. Japanischer Text wurde in Stücke von 800 Zeichen geschnitten, lateinischer in 1.200, mit Schnitt am japanischen Satzpunkt. Ein SHA-256-Abgleich verhinderte, dass dieselbe Datei zweimal verarbeitet wurde.
PGROONGA TOKENBIGRAM
Wie japanischer Text ohne Wortgrenzen durchsuchbar wird
01
Dokument-Text
02
Bigram-Index Überlappende 2-Zeichen-Fragmente (keine Wörter)
03
Suchanfrage
03 · ARCHITEKTUR

Sechs Bausteine, vom Planer bis zum Selbsttest

01QUERY PLANNER

Ein Plan je Frage

Der Planer (gpt-4o-mini, Temperatur 0) machte aus jeder Frage einen JSON-Plan: Suchanfrage in der Originalsprache, Stichwörter auf Japanisch, Englisch und Thai, Produktcodes als Filter, ein vorhergesagtes Excel-Blatt und die Antwortstufe. Namen aus der Frage löste er in Kanji auf. Wiederholungen kamen aus dem Redis-Cache in unter 30 Millisekunden.
300
MS Planungslatenz (Redis-Cache: <30 ms)
02PARALLEL DISCOVERY

Sieben Retrieval-Kanäle, eine Rangliste

pgvector mit HNSW-Index für die Bedeutung, PGroonga TokenBigram für den exakten Wortlaut ohne MeCab, LightRAG für Beziehungen aus dem Wissensgraphen, dazu je nach Frage Tabellen, Postfächer, Personen und Aufgabenkarten. Reciprocal Rank Fusion (k=60) führte die Listen zusammen, höchstens drei Stücke je Dokument, Cohere Rerank v3.5 wählte aus. HyDE und das Synonymwörterbuch holten Treffer über die Sprachgrenze.
7
Parallele Retrieval-Kanäle
03TABELLEN

Excel-Zeilen mit Kontext

Jede Excel-Zeile lag doppelt vor: als Klartext mit Tabulatoren für PGroonga und als HTML-Tabelle für das Modell. Bei einem Treffer holte das System Kopfzeilen und Nachbarzeilen desselben Blocks dazu, damit das Modell die ganze Tabelle sah und nicht eine einzelne Zelle. Das Kontextbudget wuchs mit der Antwortstufe von 15.000 auf 130.000 Zeichen.
130K
Zeichen Kontext in der Stufe Deep
04SYNTHESE

Vier Antwortstufen

Nicht jede Frage brauchte das teuerste Modell. Flash unter 4 Sekunden für einfache Fakten, Fast und Standard mit Claude Haiku 4.5, Deep unter 35 Sekunden mit Claude Sonnet 4.6 für Analysen über mehrere Dokumente. Ausgabebudget und Kontextfenster wuchsen mit jeder Stufe. Die ersten Wörter kamen per Streaming sofort, Folgefragen wiederholten keine schon gezeigten Stellen, und Gehälter oder Personalentscheidungen blockierte ein Filter.
4
Antwortstufen, unter 4 bis unter 35 s
05INGESTION

Vier Quellen, ein Index

SharePoint per Delta-Abgleich über Microsoft Graph, mit gespiegelten Berechtigungen. Postfächer nach zweistufigem Relevanzfilter. Meeting-Transkripte per Webhook. Upload im Browser. Mistral OCR für PDFs bis 35 MB, ExcelJS und Unstructured.io für XLSX, DOCX und PPTX. Stücke von 800 Zeichen für Japanisch und 1.200 für lateinische Schrift, Dubletten per SHA-256 erkannt.
4
Quellen-Konnektoren
06FEEDBACK-LOOP

Lernendes Unternehmensprofil

Korrekturen aus dem Nutzerfeedback wurden extrahiert, gegen Prompt-Injection geprüft und in alle späteren Antworten eingespeist. So lernte der Agent ohne neues Training. Ein Selbsttest mit 100 Fragen lief als echter Nutzer gegen das laufende System und maß Score, Quellenabdeckung und Antwortzeit je Kategorie. Circuit Breaker, Wiederholversuche und Kostenbudgets je Anbieter hielten den Betrieb stabil.
100
Szenarien im Selbsttest
Excel war der härteste Brocken. Eine Frage wie „Was kostet Artikel X derzeit pro Stück?“ zielt auf eine Zelle in einer Mappe mit dutzenden Blättern und Kopfzeilen, die niemand vereinheitlicht hat. Deshalb lag jede Zeile doppelt im Index, und ein Treffer brachte Kopf- und Nachbarzeilen mit.
Vor der Antwort wurden die Tabellen in kompaktes Markdown gewandelt, rund 30 Prozent weniger Tokens. Lieber drei vollständige Dokumente als zehn abgeschnittene. Die Antwort nannte am Ende die Fundstelle: „[Kostenkalkulation Q1.xlsx] Stand 2025-03-15“.
Wo Vektor- und Volltextsuche bei einzelnen Dokumenten endeten, begann der Wissensgraph. LightRAG zog beim Import Standorte, Lieferanten, Produktlinien und Berichte heraus und die Beziehungen dazwischen: wer liefert was, wer prüft was. Bei Fragen über mehrere Dokumente gab er der Antwort einen kurzen Pfad durch den Graph mit.
Die Grafik darunter zeigt eine vereinfachte Fertigungsdomäne. Die Linien hat der Graph aus den Dokumenten selbst gelernt.
Fünf Anbieter im Einsatz waren eine Entscheidung, kein Zufall: OpenAI für Einbettungen und den Planer, Mistral für OCR, Cohere für das Rerank, Unstructured.io für Office-Dateien, Anthropic für die Antwort. Circuit Breaker, Wiederholversuche mit Rücksicht auf Rate-Limits und Kostenbudgets je Anbieter, pro Stunde und pro Tag, hielten den Betrieb im Rahmen.
LIGHTRAG WISSENSGRAPH · BEISPIEL FERTIGUNG
本社 HEADQUARTERS 品質管理 QUALITY CTRL 生産計画 PRODUCTION 海外工場 OVERSEAS PLANT 原材料 RAW MATERIALS 検品報告 INSPECTION 管轄 策定 運営 調達 監査 準拠 実施 使用
QUERY 品質管理 → 海外工場の検品報告 3 Entitäten, 2 Relationen, Pfad in unter einer Sekunde aufgelöst
04 · ERGEBNISSE

0,9 von 1,0 im Selbsttest, gemessen am laufenden System

5
KI-Anbieter im Einsatz
7
Retrieval-Kanäle parallel
2
Sprachen im Index
0,9
Selbsttest, höchstens 1,0
METRIKVORHERNACHHER
WissenssucheSharePoint durchklicken, drei Kollegen fragenEine Frage, eine Antwort mit Fundstelle
SprachbarriereSelbst übersetzen oder weglassenJapanisch und Thai im selben Index
Excel-RechercheBlatt für Blatt durchscrollenTreffer mit Kopf- und Nachbarzeilen
Meeting-WissenNach dem Termin wegTranskripte automatisch im Index
QuellenvertrauenKeine RückverfolgungJede Antwort mit Link und Textstelle
Synthese-KostenTeuerstes Modell für jede FrageVier Stufen, Sonnet nur wenn nötig
Statt Eindrücken gab es einen Selbsttest: 100 Szenarien, 83 nach Abzug der Dubletten, in acht Kategorien von der einfachen Faktenfrage über Meeting-Zusammenfassungen und Mail-Suche bis zur Analyse über mehrere Marken. Er lief als echter Nutzer gegen das laufende System. Ergebnis: 0,9 von 1,0, mit Quellenangabe in fast jeder Antwort. Und wenn der Bestand eine Frage nicht hergab, sagte der Agent das, statt etwas zu erfinden.
Die Antwortzeit richtete sich nach der Frage. Wiederkehrende Faktenfragen kamen aus dem Cache in unter zwei Sekunden, einfache Nachschlagefragen in unter vier, Analysen über mehrere Dokumente mit Claude Sonnet 4.6 in unter 35. Die ersten Wörter erschienen sofort, der Rest lief nach.
Qualität war kein Abnahmetest, sondern ein Regelkreis. Der Selbsttest deckte schwache Kategorien auf, bevor Nutzer sie bemerkten. Korrekturen aus dem Feedback flossen in spätere Antworten ein. Jede Antwort blieb mit ihren Quelldokumenten verknüpft.
Die Phase lief von 2025 bis Juni 2026. Danach verlagerte der Kunde den Schwerpunkt auf die Meeting-Auswertung und die Vorbereitung einer Zertifizierung, und der Wissensagent wurde aus dem laufenden Dashboard herausgelöst. Die Messwerte oben stammen aus der Zeit, in der er lief.
“
Die KI ist der Enabler, den wir brauchten: Unsere Mitarbeiter in Japan stellen eine Frage auf Japanisch und erhalten in Sekunden eine Antwort, die auf englischen oder thailändischen Dokumenten basiert. Das hat die Kommunikation zwischen unserem thailändischen und japanischen Team grundlegend optimiert.
CEO, JAPANISCHES PRODUKTIONSUNTERNEHMEN
TECH STACK
Claude Haiku 4.5
Antwort in den Stufen Flash, Fast und Standard
Claude Sonnet 4.6
Antwort in der Stufe Deep
gpt-4o-mini
Planer und Extraktion der Korrekturen
OpenAI Embeddings
text-embedding-3-small (1536-D)
Cohere Rerank v3.5
Finales Re-Ranking
Mistral OCR
PDF-Parsing inkl. Scans (bis 35 MB)
Unstructured.io
DOCX- und PPTX-Extraktion
Supabase + pgvector
Semantische Suche, HNSW-Index
PGroonga
Japanische Volltextsuche, TokenBigram
LightRAG
Wissensgraph, Entitäten und Beziehungen
Microsoft Graph
SharePoint-Delta-Sync, E-Mail, Berechtigungen
Meeting-Transkripte
aus Teams und Notta, im Haus verarbeitet
Node.js + Express
Backend, PM2-Cluster, SSE-Streaming
Redis
Planer- und Antwort-Cache, Rate-Limit
SSE
Echtzeit-Token-Streaming
AUSBLICK
Meeting-Transkripte und Postfächer, in der ersten Ausbaustufe noch offen, wurden im Lauf der Phase produktive Quellen. Geplant waren danach Kosten je Abfrage, eine feinere Einstufung der Fragen und ein dichterer Graph. Gekommen ist es anders: Der Kunde brauchte zuerst die Meeting-Auswertung und danach einen Tracker für die GOTS-Zertifizierung. Das Kanji-Korrekturlernen und das Synonymwörterbuch aus dieser Phase laufen dort weiter.
KI-AgentenRAGWissensmanagementNLPHybrid-SearchKnowledge-GraphpgvectorPGroongaSupabase
NÄCHSTER SCHRITT

Ähnliches Projekt?

KONTAKTIEREN SIE UNS KI-AGENTUR MÜNCHENALLE CASE STUDIES
Häufige Fragen zur Fallstudie
Was ist ein RAG-Wissensagent?+
Ein Suchsystem, das zuerst in den eigenen Unterlagen sucht und ein Sprachmodell die Antwort erst danach aus den gefundenen Stellen formulieren lässt. Die Fundstelle steht vor der Antwort, deshalb lässt sich jede Aussage belegen. In diesem Projekt kamen die Stellen aus SharePoint, Postfächern und Meeting-Transkripten.
Wie funktioniert Volltextsuche auf Japanisch ohne Leerzeichen?+
PGroonga zerlegt den Text in überlappende Zweizeichen-Fragmente. Eine Suche nach 品質管理 findet so auch 品質管理報告書, ohne dass ein Wörterbuch die Wortgrenzen kennen muss. Daneben lief eine Vektorsuche für die Bedeutung, und beide Listen wurden zu einer Rangliste verschmolzen.
Warum sieben Suchkanäle statt einer Vektorsuche?+
Weil jede Frage anders ist. Ein Produktcode braucht den exakten Wortlaut, eine Frage nach Zusammenhängen den Graphen, ein Stückpreis die Tabellenzeile samt Kopfzeile. Die Kanäle liefen parallel, der langsamste bestimmte die Zeit, und eine Rangliste führte alles zusammen.
Wie wurde die Qualität gemessen?+
Mit einem Selbsttest aus 100 Szenarien in acht Kategorien, 83 nach Abzug der Dubletten, der als echter Nutzer gegen das laufende System lief. Der Gesamtwert lag bei 0,9 von 1,0. Korrekturen aus dem Nutzerfeedback flossen in spätere Antworten ein.
Blieben die Daten im Haus?+
Index und Suche lagen in Supabase auf EU-Servern, die Berechtigungen aus SharePoint wurden je Nutzer gespiegelt. Für die Sprachmodelle kamen Anbieter-APIs zum Einsatz. Wer das nicht will, bekommt dieselbe Architektur heute mit einem lokalen Sprachmodell.
Läuft das System noch?+
Die Phase endete im Juni 2026. Der Kunde verlagerte den Schwerpunkt auf die Meeting-Auswertung und die Vorbereitung einer GOTS-Zertifizierung, der Wissensagent wurde aus dem Dashboard herausgelöst. Die Bausteine für japanische Suche und Kanji-Korrektur werden dort weiter genutzt.
Kann Kuroko Labs so ein System für unser Unternehmen bauen?+
Ja. Die Bausteine sind austauschbar, nur die Quellen ändern sich von Firma zu Firma. Erstgespräch und Potenzialanalyse kosten nichts, danach gibt es einen Festpreis. Mehr dazu auf der Seite zu RAG-Systemen.
Eingesetzte Technik
Die Suche kombiniert pgvector, PGroonga, LightRAG und Cohere. Alle Bestandteile sind öffentlich dokumentiert und nachprüfbar; wir bauen keine geschlossenen Verfahren, die niemand nachvollziehen kann.
Die Verweise führen auf die Dokumentation der jeweiligen Bestandteile.
DEJPEN