vijaym commited on
Commit
2c5223b
ยท
verified ยท
1 Parent(s): c14f0b4

Upload README.md with huggingface_hub

Browse files
Files changed (1) hide show
  1. README.md +47 -6
README.md CHANGED
@@ -19,7 +19,8 @@ pipeline_tag: token-classification
19
 
20
  Korean fine-tune of [OpenAI Privacy Filter](https://huggingface.co/openai/privacy-filter)
21
  for span-level PII detection. Adapted via **LoRA** on attention projections only โ€”
22
- the base's sparse-MoE backbone (1.5B / 50M active params) is kept frozen.
 
23
 
24
  **[Open Test Notebook](https://huggingface.co/FrameByFrame/privacy-filter-korean/blob/main/test_privacy_filter_ko.ipynb)** โ€” load the model and run all examples interactively.
25
 
@@ -56,19 +57,27 @@ Held-out KDPII Korean PII test set, span-level F1:
56
 
57
  ### Install
58
 
59
- The `openai_privacy_filter` architecture is in `transformers` HEAD but not yet in
60
- a stable PyPI release, so install from source:
 
 
61
 
62
  ```bash
63
- pip install "git+https://github.com/huggingface/transformers.git" peft torch safetensors accelerate
64
  ```
65
 
66
- If you already have a stable transformers installed, force the upgrade:
 
 
 
 
67
 
68
  ```bash
69
- pip uninstall -y transformers && pip install "git+https://github.com/huggingface/transformers.git"
70
  ```
71
 
 
 
72
  ### Load Model
73
 
74
  ```python
@@ -240,6 +249,38 @@ Each detected entity is one dict:
240
  | **Hardware** | 2ร— NVIDIA RTX A5000 (24 GB each) |
241
  | **Final eval span F1** | 0.848 (validation) |
242
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
243
 
244
  ## Serving with vLLM
245
 
 
19
 
20
  Korean fine-tune of [OpenAI Privacy Filter](https://huggingface.co/openai/privacy-filter)
21
  for span-level PII detection. Adapted via **LoRA** on attention projections only โ€”
22
+ the base's sparse-MoE backbone (1.5B / 50M active params) is kept frozen, with
23
+ just **~614k trainable parameters** (~0.04% of the model).
24
 
25
  **[Open Test Notebook](https://huggingface.co/FrameByFrame/privacy-filter-korean/blob/main/test_privacy_filter_ko.ipynb)** โ€” load the model and run all examples interactively.
26
 
 
57
 
58
  ### Install
59
 
60
+ > โš ๏ธ **Requires `transformers` 5.x (currently dev / from source).** The
61
+ > `openai_privacy_filter` architecture is *not* in any stable 4.x PyPI release.
62
+ > If you `pip install transformers` and load this model, you'll see
63
+ > `KeyError: 'openai_privacy_filter'`.
64
 
65
  ```bash
66
+ pip install --upgrade "git+https://github.com/huggingface/transformers.git" peft torch safetensors accelerate
67
  ```
68
 
69
+ The `--upgrade` flag is critical โ€” without it, `pip install` is silently
70
+ no-op when an older transformers is already present.
71
+
72
+ After installing, **restart your Python runtime / kernel** so the new
73
+ transformers replaces any version pre-loaded into the process. Sanity-check:
74
 
75
  ```bash
76
+ python -c "from transformers.models.auto.configuration_auto import CONFIG_MAPPING_NAMES; assert 'openai_privacy_filter' in CONFIG_MAPPING_NAMES, 'openai_privacy_filter missing โ€” re-install transformers from source and restart runtime'"
77
  ```
78
 
79
+ If you're using Colab, the test notebook handles this automatically (auto-restart).
80
+
81
  ### Load Model
82
 
83
  ```python
 
249
  | **Hardware** | 2ร— NVIDIA RTX A5000 (24 GB each) |
250
  | **Final eval span F1** | 0.848 (validation) |
251
 
252
+ For full reproduction details, see [`TRAINING.md`](./TRAINING.md).
253
+
254
+ ## Why MoE + LoRA
255
+
256
+ Full fine-tuning the privacy-filter base on KDPII consistently *hurt* the
257
+ weakest labels (`private_person` and `private_address` stuck at F1 โ‰ˆ 0.13โ€“0.20).
258
+ With 128 experts and top-4 routing, Korean tokens hit a small expert subset;
259
+ across 5โ€“10 epochs each expert receives sparse gradient updates relative to
260
+ its parameter count, and the optimizer drags those experts away from their
261
+ pretrained representations faster than it teaches the new task. Net effect:
262
+ the base's pretrained Korean capability gets corrupted before the new task is
263
+ learned.
264
+
265
+ LoRA on attention only (this model) avoids this entirely โ€” experts, FFN,
266
+ embeddings, and router stay exactly as the base shipped them; only attention
267
+ re-routing and the classifier head adapt. Result: F1 0.69 / 0.78 on the
268
+ previously-stuck labels, with every other label at or above ceiling.
269
+
270
+ ## Known Limitations
271
+
272
+ - **`private_person` residual error** is dominated by KDPII's `PS_NICKNAME`
273
+ policy. ~40% of remaining person errors are online-handle-style strings
274
+ (e.g., `ํƒ•๋น„์‹ค๋งฅ์‹ฌํ‚น`, `ํผํ„ฐ์š”์ •`) that KDPII labels as `PS_NICKNAME โ†’
275
+ private_person`. Downstream redaction is unaffected; classification systems
276
+ may want to post-classify handles separately.
277
+ - **Foreign names** (Western, Japanese, Arabic transliterations) detected at
278
+ lower rates due to limited training exposure.
279
+ - **`private_address` boundaries** follow KDPII's split convention (each
280
+ toponym component is a separate span). Production redactors typically
281
+ concatenate adjacent address spans during post-processing.
282
+ - Raw model output may have leading/trailing whitespace in span offsets;
283
+ the `extract_pii` helper above strips them via `text.strip()` on the slice.
284
 
285
  ## Serving with vLLM
286