RAGFlowが日本語を中国語に変換する問題を回避するため、LlamaIndexで日英RAGを自作した話Faced with RAGFlow incorrectly converting Japanese text to Chinese, the author…

Retrieval-augmented generation (RAG) has become one of the most common ways to ground large language models in private or domain-specific documents, but the quality of a RAG system depends heavily on how well its underlying tools handle the language of those documents. A recent Zenn post describes a case where RAGFlow, a popular open-source RAG engine, reportedly converted Japanese text into Chinese during processing, prompting the author to abandon the packaged solution and build a bilingual Japanese-English pipeline from scratch using LlamaIndex.

The reported problem sits at the intersection of a well-known challenge in natural language processing: the overlap between the Chinese and Japanese writing systems. Japanese uses kanji, characters that are largely shared with Chinese hanzi, alongside hiragana and katakana. When a processing step such as language detection, text normalization, or a tokenizer is tuned primarily for Chinese, it can misidentify or transform Japanese content, sometimes substituting characters with their simplified Chinese equivalents. The author appears to have encountered exactly this kind of silent corruption, where ingested Japanese documents no longer matched their original form, undermining the accuracy of any downstream retrieval.

RAGFlow is designed as an end-to-end platform that bundles document parsing, chunking, embedding, and retrieval behind a single interface, which makes it attractive for teams that want to avoid assembling components themselves. The trade-off, as this case illustrates, is that an all-in-one system can be difficult to debug or reconfigure when one internal stage behaves unexpectedly. Rather than patch around the behavior, the author chose LlamaIndex, a data framework that gives developers explicit control over each stage of the RAG workflow.

Building a RAG pipeline manually typically involves several distinct steps. Documents are first loaded and split into chunks of a manageable size, then each chunk is passed through an embedding model that converts text into vectors. Those vectors are stored in a vector database or index, and at query time the system retrieves the most relevant chunks and feeds them, along with the user's question, into an LLM that generates the final answer. LlamaIndex provides abstractions for each of these steps while leaving room to swap in language-appropriate components, which is central to the author's approach.

For Japanese in particular, the choice of embedding model and text-splitting strategy matters a great deal. Multilingual embedding models such as the E5 and BGE families, or Japanese-focused models, are commonly used because they preserve semantic meaning across languages and handle CJK scripts more reliably than English-centric alternatives. Chunking also requires care, since naive splitting on whitespace does not work for Japanese, which does not place spaces between words. Tokenizers such as MeCab, Sudachi, or GiNZA are often introduced to segment text sensibly. The post reportedly walks through these implementation details and the lessons learned along the way.

The account fits into a broader pattern in the local LLM community, where developers increasingly favor building on modular frameworks that they can run and inspect on their own hardware. Alongside LlamaIndex, tools such as LangChain, Haystack, and vector stores like FAISS, Chroma, and Qdrant are frequently combined to create custom retrieval stacks. Running these components locally, often with open-weight models served through runtimes such as Ollama, appeals to users concerned with data privacy, cost, or the need to support languages that hosted services may handle inconsistently.

The episode is a useful reminder that multilingual support is rarely uniform across the RAG toolchain, and that behavior which is acceptable for one language can introduce subtle errors in another. For practitioners working primarily in Japanese, verifying that text survives ingestion unchanged is a sensible early check before trusting any pipeline's output. Whether a custom build or a packaged engine is the better choice will depend on the team's priorities, but the author's experience suggests that greater control over each stage can be worth the additional effort when a language-specific issue proves hard to isolate. As open-source RAG tools continue to mature, such handling of non-English text is likely to improve, though careful validation remains advisable for anyone deploying these systems in production.