Japanese NLP
Named entity recognition, relation extraction, intent and topic classification, sentiment, natural language inference and segmentation — annotated with the tokenizer your pipeline actually uses.
Japanese has no spaces between words. Every span annotation therefore depends on a boundary decision that somebody has to make, and that decision has to match the tokenizer downstream or the labels will not align.
In English, "Toyota Motor Corporation" has three obvious tokens and the only question is where the entity starts and stops. In Japanese, 株式会社トヨタ自動車 is an unbroken string, and at least four defensible annotations exist: with or without 株式会社, with or without 自動車, treating the whole thing as one entity, or nesting a shorter one inside a longer one.
Every one of those is a legitimate choice. What matters is that the same choice is made every time, that it is written down, and that it survives contact with the tokenizer your model uses — because a span boundary that falls in the middle of a token cannot be represented in BIO tagging without silently moving.
That is why we fix the tokenizer and the boundary rules before annotation starts, and why we annotate character offsets underneath whatever tag format you want, so the data can be re-tokenised later without being re-annotated.
At a glance
Task types
Span tasks and document tasks have different failure modes, so they get different review criteria.
Entity spans against a taxonomy defined for your domain, including nested and overlapping entities where you need them.
How entities connect — who did what to whom, which value belongs to which field, which clause modifies which term.
Intent, topic, routing category or policy label at utterance or document level, single or multi-label.
Polarity and emotion at document, sentence or aspect level — the last of which is where Japanese business text actually needs it.
Entailment, paraphrase and semantic similarity pairs, plus the hard negatives that make an evaluation set discriminate.
Japanese specifics
These four questions come up in the first hour of every Japanese span-annotation project.
Japanese is written without spaces, so a span boundary is a judgment call rather than a lookup. Different morphological analyzers segment the same sentence differently, and labels aligned to one will not align to another.
How we handle it The analyzer and dictionary are fixed at kickoff, spans are stored as character offsets so they survive re-tokenisation, and boundary conventions are stated with worked examples.
株式会社 can precede or follow a company name, appear abbreviated as (株), or be omitted entirely. Whether it is inside the entity span changes every downstream string match.
How we handle it A single rule covers legal-form prefixes and suffixes, abbreviated forms and parenthetical variants, and a canonical form is recorded alongside the surface span.
Japanese chains nouns without separators — 個人情報保護管理者 is one string containing at least three meaningful units. Where the entity stops is a decision, not a fact.
How we handle it The guideline sets a maximal-span or minimal-span policy per entity type, with nesting where both are genuinely needed, rather than leaving each annotator to choose.
Verbs and adjectives inflect, and particles attach directly to the words they mark. Including or excluding them shifts span boundaries by one or two characters throughout a corpus.
How we handle it Inflectional endings and attached particles are explicitly in or out of the span by rule, and an automated check flags spans that end inside a token.
Process
Most of the value is created before annotation starts, in the taxonomy and the boundary rules.
We agree the label set, the analyzer and dictionary, and how spans will be represented, so the annotation matches the pipeline it is destined for.
A small sample is annotated to surface the genuinely ambiguous constructions in your domain. These become the worked examples in the guideline.
Annotators label the same set independently. Agreement is measured on boundaries and labels separately, because they fail for different reasons.
Production annotation with a review pass, and written adjudication for disagreements that feeds straight back into the guideline.
Data ships with character offsets and your chosen tag format, the taxonomy version, per-label counts and the QA report.
Delivery
Character offsets are always included, whatever surface format you take, so the data can be re-tokenised without being re-annotated.
| Task | Default output | Also available |
|---|---|---|
| Named entities | JSONL with character offsets | CoNLL-U, BIO / BILOU, brat standoff |
| Relations and events | JSONL with span references | brat standoff, custom graph JSON |
| Classification | JSONL or CSV | one-hot or multi-label matrices |
| Sentiment | JSONL with aspect spans | CSV, per-sentence labels |
| NLI and similarity | JSONL pairs | CSV, TSV in benchmark layout |
Quality
A span dataset can have excellent label accuracy and unusable boundaries. We measure both.
FAQ
The questions that come up when a Japanese span-annotation project is being scoped.
Whichever one your pipeline uses — MeCab with IPAdic or UniDic, Sudachi, Juman++ or a subword tokenizer from your own model. We fix it at kickoff because span boundaries only align to one segmentation, and we store character offsets underneath so a later change of analyzer is a re-export rather than a re-annotation.
Yes, and we would rather adopt yours than impose ours. What we will do is stress-test it on a sample first: existing taxonomies usually have two or three categories that turn out to overlap in practice, and finding that during a pilot is much cheaper than finding it after fifty thousand items.
It depends entirely on the task. Clear-cut entity types on clean text reach high agreement quickly; aspect-based sentiment and fine-grained intent taxonomies do not, and a project claiming otherwise is usually measuring something easier than what it delivers. We report the actual figure per label from the pilot, and if a category cannot reach usable agreement we will say so and propose changing the category.
Yes, where the taxonomy genuinely needs them — Japanese compound nouns and organisation names are the usual reason. Nesting rules are written into the guideline and validated automatically, because nesting that is allowed but not specified is a reliable source of inconsistency.
Yes. Correcting model output is efficient for high-volume work, with the same caveat as everywhere else: correction passes tend to inherit the model’s blind spots. We measure the correction pass against a from-scratch sample so you know what it is actually catching, and for evaluation sets we annotate from scratch.
Text & NLP
Send a label set and a sample of real Japanese text. We annotate a pilot, report boundary and label agreement, and tell you which categories will not hold up at volume.
NDA before you share any data. Pilot scoping is free.