AI Memory for Chinese, Japanese & Korean — 中文・日本語・한국어

Why CJK breaks most AI memory systems

Most AI memory systems are built around two assumptions that fail completely for Chinese, Japanese, and Korean:

1. Whitespace tokenization works.CJK languages don't use spaces between words. 我喜欢机器学习 is 7 characters with no spaces — a BPE tokenizer trained on English will split it into suboptimal pieces and produce poor embeddings.
2. English embedding models generalize.They don't. OpenAI's text-embedding-3-small handles CJK passably, but cosine similarity scores for CJK semantic search are measurably lower than for English. You need a multilingual model like multilingual-e5-large or Alibaba's text-embedding-v3 for production-quality CJK semantic search.

The result: AI assistants used by teams in China, Japan, and Korea have worse memory quality than their English-speaking counterparts. They forget more, recall less accurately, and require manual workarounds like writing lessons in English even for Chinese codebases.

How Cachly's key-based memory avoids the problem

The core of Cachly's AI brain — the learn_from_attempts / recall_best_solution system — doesn't use embeddings at all.

Lessons are stored by a topic key: deploy:kubernetes, fix:chinese-encoding, debug:日本語テスト. The content can be in any language. The key is ASCII by convention but supports full Unicode — topic keys in Chinese or Korean work perfectly.

// Chinese developer workflow — 完全支持中文
learn_from_attempts(
  instance_id = "my-brain-id",
  topic       = "fix:数据库连接",          // Chinese topic key
  outcome     = "success",
  what_worked = "连接池配置: max_idle=10, max_open=50",
  what_failed = "默认配置导致连接泄漏",
  tags        = ["数据库", "连接池", "性能"],
)

// 下次会话自动召回
recall_best_solution("数据库连接池配置")
// → Returns the lesson above, no embedding needed

This works because recall_best_solution does BM25+ full-text search over topic keys and metadata — not semantic embedding similarity. BM25 handles CJK correctly with character n-gram indexing (PostgreSQL's pg_trgm extension covers CJK trigrams natively).

Semantic search for CJK: optional, provider-selectable

For smart_recall — which does use embeddings — Cachly lets you choose the embedding provider per instance:

For Chinese developers specifically, the Alibaba Dashscope provider offers the best CJK embedding quality at the lowest cost, and runs entirely on infrastructure inside China (no cross-border data transfer for Chinese compliance requirements).

For Japanese developers, Ollama with qwen2-7b-embed or multilingual-e5-large runs entirely on-premises — useful for organizations with data residency requirements.

Japanese: mixed-script handling

Japanese is uniquely complex — a single sentence may contain Hiragana (ひらがな), Katakana (カタカナ), Kanji (漢字), and Latin (ABC). Standard tokenizers either over-split or under-split.

Cachly stores the content value verbatim as a UTF-8 string. No tokenization happens at storage time. The search layer uses PostgreSQL trigrams (pg_trgm), which operate at the Unicode code point level — so a Japanese query like "認証の問題" correctly matches stored content containing "認証エラー" via shared trigrams, with no language-specific configuration.

# Japanese developer example
learn_from_attempts(
    instance_id = brain_id,
    topic       = "fix:認証エラー",
    outcome     = "success",
    what_worked = "JWT検証でHS256からRS256に変更した",
    what_failed = "HS256は環境変数の秘密鍵が共有できない",
    tags        = ["認証", "JWT", "セキュリティ"],
)

# Works without any embedding model:
recall_best_solution("認証")
# → Returns the lesson above via BM25 trigram matching

Korean: compound morphology

Korean uses agglutinative morphology — a single word can be a combination of a root, subject/object markers, tense, and honorifics. The word "개발했습니다" (developed, formal-polite) won't match "개발" (develop) without morphological analysis.

For key-value brain storage, this doesn't matter — you choose the topic key, and you can normalize it to a root form: fix:데이터베이스 not fix:데이터베이스를연결하는방법.

For semantic search, use Cohere's embed-multilingual-v3.0 — it's trained on Korean morphological patterns and handles compound forms correctly.

Practical setup for CJK teams

# .mcp.json for Chinese/Japanese/Korean teams

{
  "mcpServers": {
    "cachly": {
      "command": "npx",
      "args": ["-y", "@cachly-dev/mcp-server@latest"],
      "env": {
        "CACHLY_JWT": "your-token",
        
        // For semantic search with CJK:
        // Chinese → Alibaba Dashscope (best quality, China-hosted)
        "CACHLY_EMBED_PROVIDER": "dashscope",
        "DASHSCOPE_API_KEY": "sk-...",
        
        // OR Japanese/Korean → Cohere multilingual
        // "CACHLY_EMBED_PROVIDER": "cohere",
        // "COHERE_API_KEY": "...",
        
        // OR fully local with Ollama (any language):
        // "CACHLY_EMBED_PROVIDER": "ollama",
        // "OLLAMA_BASE_URL": "http://localhost:11434",
        // "OLLAMA_MODEL": "qwen2-7b-embed"
      }
    }
  }
}

// No embedding provider needed for learn/recall —
// those work with any language out of the box.

For teams with strict data residency requirements — no data should leave Japan, China, or Korea — the Ollama option runs all embedding generation locally. Cachly's storage is on German servers (EU), but the embedding computation happens on your machine. A fully local Cachly deployment (self-hosted tier) keeps everything on-premises.