001JAPANESE TEXTILE COMPANY · 2025–2026
RAG knowledge agent for Japanese and Thai: 0.9 out of 1.0 in the self-test
0.9
OUT OF 1.0 IN THE SELF-TEST
A textile company based in Osaka with factories in Thailand wanted to ask one question and get an answer it could check, whether the source was written in Japanese, English or Thai. Kuroko Labs built a knowledge agent for that: a planner broke each question down, seven retrieval channels ran in parallel, one ranking merged them, and a language model wrote the answer with its source. Simple questions came back in under four seconds, analyses across several documents in under 35. In a self-test over 100 scenarios the system scored 0.9 out of 1.0. The phase ran from 2025 to June 2026. After that the client moved its focus to meetings and certification.
5
AI Providers
Anthropic, OpenAI, Cohere, Mistral, Unstructured.io
7
Retrieval Channels
Vector, Full-Text, Tabular, Email, Graph, Entity, Kanban
4
Answer Tiers
Flash under 4 s to Deep under 35 s
2
Languages
Japanese and Thai
0.9
Self-Test Score
100 scenarios, 83 without duplicates, against the live system
01 · THE CHALLENGE
Everything was documented. Nobody could find it.
The client sews for fashion brands in Thailand and runs the business from Osaka. Specifications arrive in Japanese, reports from the factory in Thai or English. In between sit SharePoint, mailboxes and Excel workbooks with dozens of sheets.
People still searched by asking around. Whoever needed the unit price of an item asked three colleagues and ended up with an outdated file. SharePoint search was little help, because Japanese has no spaces: type 生産 and you will not find 生産管理, although it is the same topic.
The language line ran straight through the company. Osaka could not read the Thai inspection reports, the factory could not read the Japanese specifications.
Nobody wanted a chatbot. They wanted an answer with its source, in the language of the question, drawn from all three languages in the archive.
∞
Scattered filing
SharePoint, mailboxes, meeting transcripts, Excel workbooks with dozens of sheets
2
Language Barrier
Japanese and Thai without a shared index, Japanese without spaces
!
Search by asking around
An hour of Slack back and forth, then the wrong file version
0
Company Memory
Two countries, two working languages, no shared store
02 · THE SOLUTION
How do you search company knowledge in Japanese and Thai?
A plain vector search would not have been enough. Kuroko Labs built a three-stage RAG pipeline: a planner broke the question down, up to seven retrieval channels ran in parallel and were merged into one ranking, and four answer tiers decided how deep and how expensive an answer was allowed to be.
The first stage was the Query Planner, a small model (gpt-4o-mini) with a run time of about 300 milliseconds. It knew brand codes, product types, partner names and the usual names of the Excel sheets. From every question it made a plan: a query in the original language for the vector search, keyword chains in Japanese, English and Thai for the full-text search, detected product codes as hard filters, plus a rating of how hard the question was. Names such as "mori-san" it resolved through the employee directory into their kanji spelling. Repeated questions were answered by a Redis cache in under 30 milliseconds.
Second stage: seven channels at once. pgvector for meaning, PGroonga for the exact wording in Japanese, LightRAG for relationships between suppliers, products and reports, and depending on the question a search across table rows, mailboxes, people and task cards. The total time was that of the slowest channel, not the sum. Reciprocal Rank Fusion merged the lists, with at most three hits per document so no single file could dominate. Cohere Rerank made the final pick. A dictionary of more than 40 term groups translated between Japanese and English, so a Japanese question also found English documents.
The hardest part was Japanese full-text search. PGroonga splits text into overlapping two-character fragments. A search for "品質管理" therefore also hit "品質管理報告書", with no dictionary and no morphology. A function in Supabase turned Japanese particles into OR conditions. Experienced Japanese users were surprised by what the search found.
The index was fed from four sources: SharePoint through a delta sync with Microsoft Graph, permissions included, so everyone saw only what they were allowed to see in SharePoint. Mailboxes through a two-stage relevance filter. Meeting transcripts by webhook. And upload in the browser. Mistral OCR read PDFs up to 35 MB, scans included. Japanese text was cut into pieces of 800 characters, Latin script into 1,200, with the cut at the Japanese full stop. A SHA-256 check made sure the same file was never processed twice.
PGROONGA TOKENBIGRAM
How Japanese text without word boundaries becomes searchable
01
Document text
02
Bigram index Overlapping 2-character fragments (not words)
03
Search query
03 · ARCHITECTURE
Six building blocks, from the planner to the self-test
01QUERY PLANNER
One plan per question
The planner (gpt-4o-mini, temperature 0) turned every question into a JSON plan: a query in the original language, keywords in Japanese, English and Thai, product codes as filters, a predicted Excel sheet and the answer tier. Names in the question it resolved into kanji. Repeats came from the Redis cache in under 30 milliseconds.
300
MS planning latency (Redis cache: <30 ms)
02PARALLEL DISCOVERY
Seven retrieval channels, one ranking
pgvector with an HNSW index for meaning, PGroonga TokenBigram for the exact wording without MeCab, LightRAG for relationships from the knowledge graph, plus tables, mailboxes, people and task cards depending on the question. Reciprocal Rank Fusion (k=60) merged the lists, at most three chunks per document, and Cohere Rerank v3.5 made the selection. HyDE and the synonym dictionary pulled in hits across the language line.
7
Parallel retrieval channels
03TABLES
Excel rows with context
Every Excel row was stored twice: as tab-separated plain text for PGroonga and as an HTML table for the model. On a hit, the system fetched the header rows and neighbouring rows of the same block, so the model saw the whole table rather than a single cell. The context budget grew with the answer tier from 15,000 to 130,000 characters.
130K
Characters of context in the Deep tier
04SYNTHESIS
Four answer tiers
Not every question needed the most expensive model. Flash under 4 seconds for simple facts, Fast and Standard with Claude Haiku 4.5, Deep under 35 seconds with Claude Sonnet 4.6 for analyses across several documents. Output budget and context window grew with each tier. The first words arrived by streaming at once, follow-up questions did not repeat passages already shown, and a filter blocked salaries and personnel decisions.
4
Answer tiers, under 4 to under 35 s
05INGESTION
Four sources, one index
SharePoint by delta sync through Microsoft Graph, with mirrored permissions. Mailboxes after a two-stage relevance filter. Meeting transcripts by webhook. Upload in the browser. Mistral OCR for PDFs up to 35 MB, ExcelJS and Unstructured.io for XLSX, DOCX and PPTX. Pieces of 800 characters for Japanese and 1,200 for Latin script, duplicates caught by SHA-256.
4
Source connectors
06FEEDBACK LOOP
A learning company profile
Corrections from user feedback were extracted, checked against prompt injection and fed into all later answers. That is how the agent learned without new training. A self-test with 100 questions ran as a real user against the live system and measured score, source coverage and response time per category. Circuit breakers, retries and cost budgets per provider kept operations steady.
100
Scenarios in the self-test
Excel was the hardest part. A question like "What does item X currently cost per unit?" points at one cell in a workbook with dozens of sheets and headers nobody ever standardised. So every row sat twice in the index, and a hit brought its header and neighbouring rows along.
Before the answer, the tables were converted into compact Markdown, about 30 percent fewer tokens. Three complete documents rather than ten truncated ones. The answer ended with the source: "[Cost Calculation Q1.xlsx] as of 2025-03-15".
Where vector and full-text search stopped at single documents, the knowledge graph began. During import LightRAG pulled out sites, suppliers, product lines and reports, and the relationships between them: who supplies what, who inspects what. For questions spanning several documents it gave the answer a short path through the graph.
The graphic below shows a simplified manufacturing domain. The lines are what the graph learned from the documents themselves.
Five providers in play was a decision, not an accident: OpenAI for embeddings and the planner, Mistral for OCR, Cohere for the rerank, Unstructured.io for Office files, Anthropic for the answer. Circuit breakers, retries that respected rate limits, and cost budgets per provider, per hour and per day, kept operations within bounds.
LIGHTRAG KNOWLEDGE GRAPH · MANUFACTURING EXAMPLE
QUERY
品質管理 → 海外工場の検品報告
3 entities, 2 relations, path resolved in under a second
04 · RESULTS
0.9 out of 1.0 in the self-test, measured on the live system
5
AI providers in use
7
Retrieval channels in parallel
2
Languages in the index
0.9
Self-test, 1.0 at most
METRIKBEFOREAFTER
Knowledge searchClick through SharePoint, ask three colleaguesOne question, one answer with its source
Language barrierTranslate by hand or skip itJapanese and Thai in the same index
Excel researchScroll through the sheets one by oneHits with header and neighbouring rows
Meeting knowledgeGone after the meetingTranscripts land in the index automatically
Source trustNo traceabilityEvery answer with a link and the passage
Synthesis costThe most expensive model for every questionFour tiers, Sonnet only when needed
Instead of impressions there was a self-test: 100 scenarios, 83 after removing duplicates, in eight categories from the simple factual question through meeting summaries and mail lookups to analyses across several brands. It ran as a real user against the live system. Result: 0.9 out of 1.0, with a source given in almost every answer. And when the archive did not hold an answer, the agent said so instead of making one up.
Response time followed the question. Recurring factual questions came from the cache in under two seconds, simple lookups in under four, analyses across several documents with Claude Sonnet 4.6 in under 35. The first words appeared at once, the rest followed.
Quality was not an acceptance test but a loop. The self-test exposed weak categories before users noticed them. Corrections from feedback flowed into later answers. Every answer stayed linked to its source documents.
The phase ran from 2025 to June 2026. After that the client moved its focus to meeting analysis and to preparing a certification, and the knowledge agent was taken out of the live dashboard. The figures above are from the time it ran.
“
AI is the enabler we needed: our staff in Japan ask a question in Japanese and receive an answer in seconds that draws on English or Thai documents. This has fundamentally improved communication between our Thai and Japanese teams.CEO, JAPANESE MANUFACTURING COMPANY
TECH STACK
Claude Haiku 4.5
Answers in the Flash, Fast and Standard tiers
Claude Sonnet 4.6
Answers in the Deep tier
gpt-4o-mini
Planner and extraction of corrections
OpenAI Embeddings
text-embedding-3-small (1536-D)
Cohere Rerank v3.5
Final re-ranking
Mistral OCR
PDF parsing incl. scans (up to 35 MB)
Unstructured.io
DOCX and PPTX extraction
Supabase + pgvector
Semantic search, HNSW index
PGroonga
Japanese full-text search, TokenBigram
LightRAG
Knowledge graph, entities and relations
Microsoft Graph
SharePoint delta sync, email, permissions
Meeting transcripts
from Teams and Notta, processed in house
Node.js + Express
Backend, PM2 cluster, SSE streaming
Redis
Planner and answer cache, rate limiting
SSE
Real-time token streaming
OUTLOOK
Meeting transcripts and mailboxes, still open in the first build stage, became productive sources during the phase. The plan after that was cost per query, a finer rating of questions and a denser graph. It went differently: the client needed meeting analysis first and then a tracker for the GOTS certification. The kanji correction learning and the synonym dictionary from this phase keep running there.
NEXT STEP
A similar project?
GET IN TOUCH ALL CASE STUDIESQuestions about this case study
What is a RAG knowledge agent?+
A search system that looks through your own documents first and only then lets a language model write the answer from the passages it found. The source comes before the answer, so every statement can be checked. In this project the passages came from SharePoint, mailboxes and meeting transcripts.
How does full-text search work in Japanese without spaces?+
PGroonga splits the text into overlapping two-character fragments. A search for 品質管理 then also finds 品質管理報告書, without a dictionary that knows where words end. A vector search for meaning ran alongside, and both lists were merged into one ranking.
Why seven retrieval channels instead of one vector search?+
Because every question is different. A product code needs the exact wording, a question about relationships needs the graph, a unit price needs the table row with its header. The channels ran in parallel, the slowest one set the time, and one ranking brought everything together.
How was quality measured?+
With a self-test of 100 scenarios in eight categories, 83 after removing duplicates, run as a real user against the live system. The overall score was 0.9 out of 1.0. Corrections from user feedback flowed into later answers.
Did the data stay in house?+
Index and search lived in Supabase on EU servers, and the SharePoint permissions were mirrored per user. The language models were called through provider APIs. If that is not acceptable, the same architecture now runs with a local language model.
Is the system still running?+
The phase ended in June 2026. The client moved its focus to meeting analysis and to preparing a GOTS certification, and the knowledge agent was taken out of the dashboard. The building blocks for Japanese search and kanji correction are still in use there.
Can Kuroko Labs build a system like this for our company?+
Yes. The building blocks are interchangeable, only the sources differ from company to company. The first call and the assessment cost nothing, after that there is a fixed price. More on the RAG systems page.