Remove vLLM section and Why MoE+LoRA section

README.md

@@ -251,22 +251,6 @@ Each detected entity is one dict:
 
 For full reproduction details, see [`TRAINING.md`](./TRAINING.md).
 
-## Why MoE + LoRA
-
-Full fine-tuning the privacy-filter base on KDPII consistently *hurt* the
-weakest labels (`private_person` and `private_address` stuck at F1 ≈ 0.13–0.20).
-With 128 experts and top-4 routing, Korean tokens hit a small expert subset;
-across 5–10 epochs each expert receives sparse gradient updates relative to
-its parameter count, and the optimizer drags those experts away from their
-pretrained representations faster than it teaches the new task. Net effect:
-the base's pretrained Korean capability gets corrupted before the new task is
-learned.
-
-LoRA on attention only (this model) avoids this entirely — experts, FFN,
-embeddings, and router stay exactly as the base shipped them; only attention
-re-routing and the classifier head adapt. Result: F1 0.69 / 0.78 on the
-previously-stuck labels, with every other label at or above ceiling.
-
 ## Known Limitations
 
 - **`private_person` residual error** is dominated by KDPII's `PS_NICKNAME`
@@ -282,18 +266,6 @@ previously-stuck labels, with every other label at or above ceiling.
 - Raw model output may have leading/trailing whitespace in span offsets;
   the `extract_pii` helper above strips them via `text.strip()` on the slice.
 
-## Serving with vLLM
-
-For batched, low-latency inference:
-
-```bash
-vllm serve FrameByFrame/privacy-filter-korean \
-  --task token-classification \
-  --max-model-len 512 \
-  --dtype bfloat16 \
-  --trust-remote-code
-```
-
 ## License
 
 Apache 2.0 (inherited from base