alfaplus/tegami-27B-qw38

Tegami-27B · Japanese Business-Email LoRA

手紙 (tegami) — a letter. A QLoRA adapter for Qwen/Qwen3.8-27B that writes Japanese business email the way a Japanese office actually writes it: correct keigo (敬語), a proper address block (宛名), the internal-vs-external register split, ~30-full-width-character line wrapping, and a real signature (署名) — and it does not turn into a keigo firehose when you only wanted a casual message.

You can prompt it in English or Japanese; the output is Japanese business correspondence.

What makes this release different: it ships with the mechanical evaluation harness that produced every number below — no LLM judge, no vibes. Three axes, one script, regex/parse-level 0/1 checks (double-keigo, address form, register mismatch, line width, markdown contamination). Point it at the base model and reproduce the delta yourself.

---

TL;DR

Two held-out test sets, greedy decoding, scored by eval/jp_bizmail_check.py.

Axis	What it checks	Base Qwen3.8-27B	+ Tegami LoRA
Positive — in-distribution	keigo + email format correct	0.0%	95.3%
Positive — novel scenarios	same, on held-out scenes it never saw	0.0%	88.2%
Negative (veto)	a casual message is not over-formalized	80–100%	100%
Preservation	general Q&A / reasoning still works	100%	100%

In-distribution = eval_probes (70), eval_disjoint: scenes and identity pools disjoint from training. Novel scenarios = wild2_probes (24), a second held-out set disjoint from training, eval, and the first held-out set. The base model writes fluent Japanese — it just doesn't write it as email (markdown, preamble, missing 件名/宛名/署名, mixed register), which is exactly the gap this adapter closes. Proofreading (M-rev), the hardest sub-task, goes from 0/8 to 8/8 in-distribution.

---

Why the "Negative" axis is the headline

Most style LoRAs quietly fail here. If you train a model to love keigo, it starts sprinkling 「お世話になっております」 onto a text to your friend. Tegami is trained against that with a dedicated negative axis — a casual message that comes back over-formalized is a failure, not a success — and it holds at 100%. Measuring this at all is the differentiator.

---

English-prompt demos (base vs. + LoRA)

Same English instruction, same greedy decoding. Left is the raw base; right is with the adapter.

Prompt (English): Write a business email in Japanese. We delivered sensor units to a client but shipped the wrong quantity. Apologize, explain the correct shipment will arrive on October 15th, and ask for their understanding.

Base Qwen3.8-27B

+ Tegami LoRA

件名：【重要】センサーユニットの納品数量に関するお詫びと修正出荷のご連絡 株式会社[クライアント名] [部署名] [担当者名] 様 いつも大変お世話になっております。 [自社名]の[自分の名前]です。 この度は、先日納品いたしましたセンサーユニットにつきまして、出荷数量に誤りがございましたことを、深くお詫び申し上げます。 本来納品すべき数量と異なる数量でお届けしてしまい、貴社のご業務に多大なるご迷惑をおかけしましたこと、重ねてお詫び申し上げます。 現在、正しい数量の製品を再出荷の手続きを進めております。 修正後の製品は、10月15日（水）に貴社へ到着する予定です。 つきましては、到着まで暫定的な対応をお願いする等、ご不便をおかけいたしますが、何卒ご理解とご協力を賜りますようお願い申し上げます。 ご不明な点やご質問がございましたら、下記連絡先までお気軽にお問い合わせください。 今後とも、より一層の品質管理に努めてまいりますので、変わらぬご愛顧を賜りますようお願い申し上げます。 [自社名] [部署名] [自分の名前] TEL: [電話番号] Email: [メールアドレス] --------------------------------------------------

件名：センサー部品 納品数量誤りのお詫びとご対応について 株式会社大和物流 購買部 田中様 いつもお世話になっております。 明和システム株式会社の藤井でございます。 このたびはセンサー部品の納品数量に誤りが ございましたこと、誠に申し訳ございません。 確認いたしましたところ、弊社側の検品ミスにより、 注文数量より5本少ない状態でお届けして おりました。 正しい数量の製品は10月15日にご到着の予定です。 到着後、速やかに弊社にて検品いたします。 ご迷惑をおかけし、誠に申し訳ございません。 何卒よろしくお願い申し上げます。 明和システム株式会社 総務部 藤井 TEL: 03-XXXX-XXXX Mail: xxx@example.co.jp ------------------------------

---

Prompt (English): Write a Japanese internal email to my manager reporting that a client requested moving up a delivery deadline, and asking for a decision.

Base Qwen3.8-27B

+ Tegami LoRA

件名：【ご相談】○○様向け納期前倒しの可否について ○○部長 お疲れ様です。△△です。 この度は、○○様より納期前倒しのご依頼をいただき、ご相談させてください。 現在進行中の「プロジェクト名」について、○○様側で社内スケジュールの都合により、当初予定の【202X年X月X日】から【202X年X月X日】へ前倒しのご希望をいただいております。 つきましては、以下の点についてご判断いただきたく、ご連絡いたしました。 対応可否：現在の進捗状況およびリソースを考慮した場合、前倒し対応が可能か 追加コスト/工数：対応に伴う追加費用や、他案件への影響について お客様への回答方針：可能であれば前倒しで対応、困難であれば現状維持で交渉する、など 詳細なスケジュール案や影響範囲については、別途資料を共有いたします。 ご多忙のところ恐れ入りますが、ご判断いただけますと幸いです。 よろしくお願いいたします。 △△ 太郎 部署名 電話番号

件名：【ご相談】株式会社サンライズ食品からの納期前倒しの要請について 岡本部長 お疲れ様です。開発部の藤井です。 株式会社サンライズ食品より、10月1日納品予定の業務用センサー AX-200について、 納期を9月17日へ前倒ししたいとの要請がありました。 受ける場合、製造ラインの残業が週あたり10時間程度増える見込みです。 受ける／断るの判断をお願いできますでしょうか。 回答期限は9月17日です。 よろしくお願いします。 開発部 藤井

---

Prompt (English): The following Japanese email to a client has keigo mistakes. Point them out and give a corrected version.

いつもお世話になっております。 ご送付いただいた資料を拝見させていただきました。 お伺いさせていただきたいことがございます。

Base Qwen3.8-27B

+ Tegami LoRA

This email contains a common but significant error in Japanese business etiquette (keigo) regarding the use of **double honorifics (二重敬語, niju keigo)**. The Mistake Problem: The phrase "お伺いさせていただきたい" is a double honorific. 伺う (ukagau) is already a humble form (kenjōgo) of "to ask" or "to inquire." It means "to ask (you, the superior) something." させていただく (sasete itadaku) is a humble expression meaning "to be allowed to do something" or "to do something with your permission." Combining them ("to be allowed to ask you") is redundant and considered grammatically incorrect and overly obsequious in standard business Japanese. It’s like saying "I would like to be allowed to ask you" when "I would like to ask you" is sufficient and polite. Why it’s wrong In Japanese keigo, you should not stack two humble forms for the same action. Since ukagau is already humble, you don’t need sasete itadaku to make it more polite. In fact, using double honorifics can sometimes come across as unnatural or even slightly awkward to native speakers. Corrected Version Here are two natural and correct ways to phrase the last sentence, depending on the nuance you want: Option 1: Most Common & Natural (Recommended) > いつもお世話になっております。 > ご送付いただいた資料を拝見いたしました。 > お伺いしたいことがございます。 Explanation: "I have something I would like to ask you." This is clean, polite, and standard. Note: I also changed "拝見させていただきました" to "拝見いたしました" for consistency and conciseness, though your original was not strictly wrong. "拝見いたしました" is slightly more direct and common in modern business emails. Option 2: Slightly More Formal/Soft > いつもお世話になっております。 > ご送付いただいた資料を拝見いたしました。 > ご質問がございますので、お伺いしたく存じます。 Explanation: "I have a question, and I would like to inquire about it." This uses "存じます" (a humble form of "think") to soften the request. Option 3: If you want to keep the "permission" nuance (but correctly) > いつもお世話になっております。 …(truncated)

## 誤りの指摘 「拝見させていただきました」→ 二重敬語 　「拝見する」がすでに謙譲語です。「させていただく」を重ねると二重敬語になります。「拝見しました」で十分です。 「お伺いさせていただきたい」→ 二重敬語 　「お伺いする」も謙譲語です。同じく「させていただく」を重ねてはいけません。「お伺いしたい」に直します。 修正後 いつもお世話になっております。 株式会社サクラテックの池田でございます。 ご送付いただいた資料を拝見しました。 お伺いしたいことがございます。

---

⚠️ Read this before downloading a GGUF

The adapter's delta is small (r=16). Baking it into bf16 weights and then quantizing to 4-bit washes out the most memory-intensive formats first. Measured honestly on the sibling v1 adapter (identical r=16 and pipeline; the effect is general and applies to this release too):

Serving path	Positive	M-rev (proofreading — the hardest task)
transformers (NF4 + adapter)	91.9%	6 / 7
merged → bf16 → transformers	91.9%	4 / 7
merged → GGUF IQ4_XS	81.1%	1 / 7
merged → GGUF Q4_K_M	64.9%	0 / 7

The merge step is lossless; the 4-bit GGUF quantization is what costs you. If you serve via llama.cpp, use a higher-bit quant (Q6_K / Q8_0) or an imatrix quant calibrated on business-mail text — the calibration corpus and the build script are in quant/. Do not judge the adapter by a Q4_K_M GGUF; that is the worst-case path.

---

Usage

from peft import PeftModel
from transformers import AutoModelForCausalLM, AutoTokenizer
import torch

base = "Qwen/Qwen3.8-27B"
tok = AutoTokenizer.from_pretrained(base)
model = AutoModelForCausalLM.from_pretrained(base, torch_dtype=torch.bfloat16, device_map="auto")
model = PeftModel.from_pretrained(model, "<this-repo>")

msg = [{"role": "user", "content":
        "Write a Japanese business email to Mr. Tanaka at Aoki Trading, "
        "proposing three candidate dates for a meeting about the new inventory system."}]
ids = tok.apply_chat_template(msg, add_generation_prompt=True, return_tensors="pt").to(model.device)
out = model.generate(ids, max_new_tokens=700, do_sample=False)
print(tok.decode(out[0, ids.shape[1]:], skip_special_tokens=True))

Loading note: the base is a multimodal-capable architecture. Loading it with plain AutoModelForCausalLM can silently drop the text decoder on some builds; verify the adapter actually changes logits (max|Δlogit| > 0) before trusting an evaluation. The eval script in eval/ does this check for you.

---

What it handles

• 尊敬語 / 謙譲語 / 丁寧語 distinctions; detects and avoids double keigo (二重敬語, e.g. 「お伺いさせていただく」).
• Internal (お疲れ様です) vs. external (お世話になっております) greeting register.
• Address forms: 「様」 for individuals, 「御中」 for organizations, 「各位」 for groups, and a job title as its own honorific (「田中部長」, not 「田中部長様」).
• Structure: 件名 → 宛名 → greeting → body → closing → signature; ~30-zenkaku line wrap; no markdown in the mail body.
• Proofreading (添削): quotes the wrong form, explains why, gives the corrected version.

Fixed in this release: when the prompt does not supply the recipient's name, the v1 adapter dropped the address line instead of falling back to 「ご担当者様」/「各位」. Adding seeds for exactly that case raised the held-out positive score from 58.8% → 88.2% (see notes/ for the full before/after). The residual failures are a handful of missing address lines in the hardest name-absent cases — the direction is right, the coverage isn't yet complete.

---

How it was built, and why it's synthetic

There is no license-clean corpus of real Japanese business email, and structurally there never will be — real business mail is confidential. So the data is generated from a spec:

1. Hand-written seeds carry the pragmatics (語用).
2. A generator separates the reusable skeleton from surface identity — companies, names, dates are placeholders drawn from disjoint pools for train vs. eval.
3. A curated phrasebook supplies idiomatic set-phrases.
4. A mechanical checker gates every generated sample.

No machine-translated Japanese — translationese is the exact failure mode this project avoids. The seeds, generator, phrasebook, and checker are all in this repo (corpus/, eval/), so you can inspect, audit, and extend the data — not just consume it.

Method	QLoRA (4-bit NF4), loss masked to assistant turns only
Rank	r = 16 / alpha = 32 — deliberately small; style/format transfer is low-complexity, and low-data + high-rank memorizes templates
Targets	all attention + MLP linears (auto), verified no adapter on vision/audio towers
Selection	by the mechanical gate, not eval_loss (eval_loss rose while the gate stayed high)
Hardware	single RTX 3090 Ti (24 GB)

---

Reproduce it

# Self-check the seed corpus (expect 0 high-severity findings)
python eval/jp_bizmail_check.py --ds-dir corpus

# Base vs. adapter, one base load, adapters swapped on top
python eval/eval_jpmail_hf.py --base Qwen/Qwen3.8-27B \
    --adapters base=NONE tegami=<this-repo> \
    --probes corpus/wild2_probes.jsonl --max-new-tokens 700

Repository layout

adapter_config.json, adapter_model.safetensors   the LoRA
corpus/     seeds, generator, phrasebook, keigo-NG table, held-out probes
eval/       jp_bizmail_check.py (the checker) + eval / rescore / compare scripts
quant/      imatrix calibration corpus + build script for domain-calibrated GGUF
notes/      design note + full run log (the numbers, and how they were isolated)
demos/      showcase.html — visual before/after

License

Apache-2.0, matching the base Qwen/Qwen3.8-27B. The adapter, corpus, generator, and evaluation harness are released together.

Not affiliated with the Qwen team; "Tegami" is a nickname for this adapter, not a product of the base-model authors.