new change
Browse filesThis view is limited to 50 files because it contains too many changes. See raw diff
- comprehensive_methodology.md +663 -0
- critical_analysis_report.md +245 -0
- idea_analysis_from_discussion.md +542 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/agnews/dev.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/agnews/labels.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/agnews/test.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/agnews/train.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/amazon/dev.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/amazon/labels.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/amazon/test.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/amazon/train.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/boolq/dev.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/boolq/labels.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/boolq/test.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/boolq/train.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/cb/dev.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/cb/labels.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/cb/test.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/cb/train.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/copa/dev.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/copa/labels.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/copa/test.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/copa/train.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/dbpedia/dev.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/dbpedia/labels.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/dbpedia/test.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/dbpedia/train.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/imdb/dev.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/imdb/labels.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/imdb/test.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/imdb/train.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/mnli/dev.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/mnli/labels.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/mnli/test.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/mnli/train.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/multirc/dev.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/multirc/labels.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/multirc/test.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/multirc/train.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/qqp/dev.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/qqp/labels.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/qqp/test.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/qqp/train.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/rte/dev.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/rte/labels.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/rte/test.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/rte/train.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/sst2/dev.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/sst2/labels.json +0 -0
- {gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/sst2/test.json +0 -0
comprehensive_methodology.md
ADDED
|
@@ -0,0 +1,663 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# PHÂN TÍCH PHÊ BÌNH VÀ HỆ THỐNG HÓA Ý TƯỞNG TỪ DISCUSSTION.TXT
|
| 2 |
+
## Từ lập luận thô → Kiểm chứng → Phản biện → Đề xuất phương pháp luận
|
| 3 |
+
|
| 4 |
+
**Ngày**: 9 tháng 3, 2026
|
| 5 |
+
**Phương pháp**: Trích xuất các ý tưởng của người nghiên cứu từ nửa sau discusstion.txt → tách khỏi flattery AI → kiểm chứng từng ý bằng toán + literature → phản biện → hệ thống hóa thành methodology
|
| 6 |
+
|
| 7 |
+
**Nguyên tắc**: Tài liệu này *không* re-explain SpecRoute hay GainLoRA. Tài liệu này tập trung vào **các ý tưởng gốc của bạn** — phân tích cái đúng, cái sai, cái bị AI overstate, và xây dựng methodology từ phần solid.
|
| 8 |
+
|
| 9 |
+
---
|
| 10 |
+
|
| 11 |
+
## I. PROBLEM DEFINITION — Không Phải "Improve Routing", Mà Là "What Is The Right Problem?"
|
| 12 |
+
|
| 13 |
+
### 1.1 Setting chính thức
|
| 14 |
+
|
| 15 |
+
Cho:
|
| 16 |
+
- Pre-trained backbone $W_0 \in \mathbb{R}^{d_{out} \times d_{in}}$ (frozen)
|
| 17 |
+
- Chuỗi $T$ tasks đến tuần tự: $\mathcal{T}_1, \mathcal{T}_2, ..., \mathcal{T}_T$
|
| 18 |
+
- Mỗi task $\mathcal{T}_t$ có dataset $\mathcal{D}_t = \{(x_i^{(t)}, y_i^{(t)})\}$ chỉ available trong giai đoạn train task $t$
|
| 19 |
+
|
| 20 |
+
Constraints:
|
| 21 |
+
- **Zero-replay**: Khi train task $t$, không có $\mathcal{D}_{t'}, t' < t$
|
| 22 |
+
- **No task-ID at inference**: Tại test time, không biết $x$ thuộc task nào
|
| 23 |
+
- **Expandable LoRA**: Mỗi task $t$ thêm LoRA branch $\Delta W_t = B_t A_t$ (rank $r$), freeze sau khi train xong
|
| 24 |
+
|
| 25 |
+
Sau $T$ tasks, forward pass cho input $h$:
|
| 26 |
+
|
| 27 |
+
$$\text{output}(h) = W_0 h + \sum_{t=1}^{T} w_t(h) \cdot B_t A_t h$$
|
| 28 |
+
|
| 29 |
+
trong đó $w_t(h) \in [0,1]$ là routing weight.
|
| 30 |
+
|
| 31 |
+
### 1.2 Ba sub-problems không thể tách rời
|
| 32 |
+
|
| 33 |
+
Bất kỳ phương pháp nào trong setting này đều phải giải **đồng thời** 3 bài toán:
|
| 34 |
+
|
| 35 |
+
| Sub-problem | Đầu vào | Đầu ra | Constraint |
|
| 36 |
+
|-------------|---------|--------|------------|
|
| 37 |
+
| **R: Routing** | Input $h$, expert set $\{\Delta W_t\}$ | Weights $w(h) \in \mathbb{R}^T$ | No task-ID, computable from $h$ alone |
|
| 38 |
+
| **P: Protection** | New task gradient $\nabla_{\theta} \mathcal{L}_T$ | Projected gradient $\tilde{\nabla}$ | Old experts' functionality preserved |
|
| 39 |
+
| **A: Allocation** | Available subspace $M^{\perp}$, new task demand | How much of $M^{\perp}$ to use | Fair capacity across tasks |
|
| 40 |
+
|
| 41 |
+
**Tại sao không thể tách rời?**
|
| 42 |
+
|
| 43 |
+
Routing quality phụ thuộc vào expert isolation (P), vì nếu new task can thiệp old expert → routing signal bị corrupt. Expert isolation phụ thuộc vào subspace budget (A), vì tight orthogonal constraint → good isolation nhưng limited capacity. Capacity limitation ảnh hưởng chất lượng expert → ảnh hưởng routing relevance.
|
| 44 |
+
|
| 45 |
+
Vòng tròn: **R ← P ← A ← R**.
|
| 46 |
+
|
| 47 |
+
### 1.3 Tại sao đây KHÔNG phải bài toán MoE
|
| 48 |
+
|
| 49 |
+
Mixture of Experts (trong LLM) và expandable LoRA CL trông giống nhau (nhiều expert, cần routing) nhưng khác biệt bản chất:
|
| 50 |
+
|
| 51 |
+
| Aspect | MoE (LLM) | Expandable LoRA CL |
|
| 52 |
+
|--------|-----------|---------------------|
|
| 53 |
+
| Expert creation | Đồng thời (jointly trained) | Tuần tự (each expert only sees its task) |
|
| 54 |
+
| Routing | Learned gating, optimized end-to-end | Cannot learn across tasks (forgetting risk) |
|
| 55 |
+
| Load balancing | Desirable (use all experts equally) | NOT desirable (want SELECTIVE activation) |
|
| 56 |
+
| Expert overlap | Expected, managed by auxiliary losses | Constrained by orthogonal projection |
|
| 57 |
+
| Data at routing time | All data available | Zero-replay → only current data |
|
| 58 |
+
|
| 59 |
+
Hệ quả: **Mọi technique của MoE routing (OT balancing, learned gating, regularization) đều không directly applicable.** Cần routing mechanism riêng cho CL setting.
|
| 60 |
+
|
| 61 |
+
---
|
| 62 |
+
|
| 63 |
+
## II. INFORMATION LANDSCAPE — Cái Gì Hợp Lệ, Cái Gì Vi Phạm?
|
| 64 |
+
|
| 65 |
+
### 2.1 Taxonomy of available information
|
| 66 |
+
|
| 67 |
+
Sau khi train xong task $t$, trước khi quên $\mathcal{D}_t$, ta có thể extract và lưu:
|
| 68 |
+
|
| 69 |
+
| Loại thông tin | Ví dụ | Hợp lệ? | Lý do |
|
| 70 |
+
|---------------|-------|---------|-------|
|
| 71 |
+
| **Model parameters** | Frozen $A_t, B_t$, GPM bases $U_t$ | ✅ | Là artifact của quá trình train, không phải data |
|
| 72 |
+
| **Derived quantities from parameters** | SVD of $\Delta W_t = U_t \Sigma_t V_t^T$ | ✅ | Computed from model params alone |
|
| 73 |
+
| **Data statistics** | Mean features $\mu_t$, covariance $\Sigma_t$ | ❌ | Summary of $\mathcal{D}_t$ → violates zero-replay |
|
| 74 |
+
| **Distribution parameters** | vMF $(\mu_t, \kappa_t)$ | ❌ | Fitted on $\mathcal{D}_t$ → violates zero-replay |
|
| 75 |
+
| **Auxiliary learned params** | Prompt keys, trans_input MLPs | ⚠️ Hợp lệ nhưng có forgetting risk | Phải train → gradient update có thể corrupt old |
|
| 76 |
+
|
| 77 |
+
### 2.2 Phân biệt tinh tế: GPM bases vs data statistics
|
| 78 |
+
|
| 79 |
+
GPM computation:
|
| 80 |
+
1. Forward pass data qua LoRA → collect input covariance matrix $C_t \in \mathbb{R}^{d \times d}$
|
| 81 |
+
2. SVD: $C_t = U_t S_t V_t^T$ → lấy principal directions $U_t[:, :k]$
|
| 82 |
+
3. Lưu $U_t[:, :k]$ (directions), BỎ $S_t$ (magnitudes)
|
| 83 |
+
|
| 84 |
+
Tại sao h��p lệ? Vì GPM bases encode **hướng (directions)** mà LoRA input hoạt động — đây là property của model + data combination mà cần forward pass để extract. Tuy nhiên, chỉ giữ lại **subspace** (span of directions), không giữ **distribution** (how data distributes within subspace).
|
| 85 |
+
|
| 86 |
+
**Lằn ranh đỏ**: Nếu một method lưu mean feature vector $\mu_t = \frac{1}{N}\sum_i f(x_i^{(t)})$ → đây là data statistic, vi phạm zero-replay. Feature Distributions paper (ICML 2025) làm chính xác điều này — cần position rõ ràng.
|
| 87 |
+
|
| 88 |
+
### 2.3 Hệ quả cho routing design
|
| 89 |
+
|
| 90 |
+
Từ Section 2.1, routing mechanism chỉ được sử dụng:
|
| 91 |
+
1. **Frozen model parameters**: $\{A_t, B_t\}_{t=1}^{T}$, frozen backbone $W_0$
|
| 92 |
+
2. **Quantities derived from frozen parameters**: SVD, norms, angles, etc.
|
| 93 |
+
3. **Current input** $h$ tại inference time
|
| 94 |
+
|
| 95 |
+
Routing **KHÔNG ĐƯỢC** sử dụng:
|
| 96 |
+
1. Learned parameters (prompt keys, gating networks) → forgetting risk
|
| 97 |
+
2. Data statistics từ old tasks (means, distributions) → zero-replay violation
|
| 98 |
+
3. Task labels → no task-ID
|
| 99 |
+
|
| 100 |
+
**Proposition 1**: *Trong zero-replay expandable LoRA CL, routing mechanism parameter-free (derived entirely from frozen expert weights + current input) là thỏa mãn tất cả constraints.*
|
| 101 |
+
|
| 102 |
+
*Lưu ý*: Đây không có nghĩa learned routing "sai" — GainLoRA dùng learned params + GPM protection cho routing params → hợp lệ nhưng cần thêm mechanism (GPM for trans_input, per-step projection). Parameter-free routing loại bỏ nhu cầu các mechanism phụ này.
|
| 103 |
+
|
| 104 |
+
---
|
| 105 |
+
|
| 106 |
+
## III. EXPERT CHARACTERIZATION — Từ Frozen Weights Đến Task Identity
|
| 107 |
+
|
| 108 |
+
### 3.1 Fundamental question: "Expert này LÀM GÌ?"
|
| 109 |
+
|
| 110 |
+
Mỗi frozen expert $\Delta W_t = B_t A_t \in \mathbb{R}^{d_{out} \times d_{in}}$ thực hiện:
|
| 111 |
+
|
| 112 |
+
$$h \mapsto \Delta W_t h = B_t (A_t h)$$
|
| 113 |
+
|
| 114 |
+
Từ SVD: $\Delta W_t = U_t \Sigma_t V_t^T$, decompose thành:
|
| 115 |
+
- $V_t^T h$: **Project input** lên principal input directions (WHAT the expert "looks at")
|
| 116 |
+
- $\Sigma_t$: **Scale** each projected component (HOW MUCH the expert cares)
|
| 117 |
+
- $U_t$: **Map to output** space (WHERE the expert "writes")
|
| 118 |
+
|
| 119 |
+
### 3.2 Spectral Signature: định nghĩa chính thức
|
| 120 |
+
|
| 121 |
+
**Definition**: *Spectral signature* của expert $t$ là cặp:
|
| 122 |
+
$$\mathcal{S}_t = \{(v_{t,i}, \sigma_{t,i})\}_{i=1}^{r}$$
|
| 123 |
+
|
| 124 |
+
trong đó $v_{t,i}$ là right singular vector thứ $i$ (input direction), $\sigma_{t,i}$ là singular value tương ứng.
|
| 125 |
+
|
| 126 |
+
**Tại sao dùng right singular vectors (V) chứ không phải left (U)?**
|
| 127 |
+
|
| 128 |
+
Routing quyết định từ **input** $h$ → cần so sánh $h$ với **input directions** mà expert listens to. Right singular vectors $V_t$ chính là "input space receptors" của expert. Left singular vectors $U_t$ encode output space — relevant cho aggregation, không phải routing.
|
| 129 |
+
|
| 130 |
+
### 3.3 Projection Fit: đo lường "expert $t$ relevant tới input $h$ bao nhiêu?"
|
| 131 |
+
|
| 132 |
+
**Definition**: *Weighted Projection Fit* của expert $t$ cho input $h$:
|
| 133 |
+
|
| 134 |
+
$$\text{fit}_t(h) = \frac{\sum_{i=1}^{r} \sigma_{t,i}^2 (v_{t,i}^T h)^2}{\sum_{i=1}^{r} \sigma_{t,i}^2 \cdot \|h\|^2}$$
|
| 135 |
+
|
| 136 |
+
**Giải thích từng thành phần**:
|
| 137 |
+
- $(v_{t,i}^T h)^2$: bao nhiêu "năng lượng" của $h$ nằm theo hướng $v_{t,i}$
|
| 138 |
+
- $\sigma_{t,i}^2$: expert coi trọng hướng $v_{t,i}$ bao nhiêu (singular values lớn = modification mạnh)
|
| 139 |
+
- $\|h\|^2$: chuẩn hóa
|
| 140 |
+
- Tử số: tổng weighted projection energy
|
| 141 |
+
- Mẫu số: maximum possible (khi $h$ nằm hoàn toàn trong span($V_t$))
|
| 142 |
+
|
| 143 |
+
**Tính chất toán học**:
|
| 144 |
+
- $\text{fit}_t(h) \in [0, 1]$
|
| 145 |
+
- $\text{fit}_t(h) = 1 \iff h \in \text{span}(V_t)$ và $h$ aligned với dominant singular vectors
|
| 146 |
+
- $\text{fit}_t(h) = 0 \iff h \perp \text{span}(V_t)$ (expert hoàn toàn không "thấy" input)
|
| 147 |
+
|
| 148 |
+
**Liên hệ với Rayleigh Quotient**:
|
| 149 |
+
|
| 150 |
+
Nếu ta define $M_t = V_t \text{diag}(\sigma_t^2) V_t^T$ (PSD matrix), thì:
|
| 151 |
+
|
| 152 |
+
$$\text{fit}_t(h) = \frac{h^T M_t h}{\text{tr}(M_t) \cdot h^T h}$$
|
| 153 |
+
|
| 154 |
+
Đây chính là **normalized Rayleigh quotient** — công cụ chuẩn trong spectral theory, KHÔNG phải construction ad hoc.
|
| 155 |
+
|
| 156 |
+
### 3.4 Tại sao projection fit là "đúng" cho bài toán này? (Và tại sao nó có thể "sai")
|
| 157 |
+
|
| 158 |
+
**Tại sao đúng (theoretical argument)**:
|
| 159 |
+
|
| 160 |
+
1. **Respect expert structure**: fit_t(h) được derive trực tiếp từ SVD of expert weights — encode what the expert WAS TRAINED to do.
|
| 161 |
+
|
| 162 |
+
2. **Per-input**: Mỗi $h$ khác nhau cho projection fit khác nhau → supports mixed-task batches (crucial for real inference).
|
| 163 |
+
|
| 164 |
+
3. **Parameter-free**: Computed from frozen quantities + current input → no forgetting risk.
|
| 165 |
+
|
| 166 |
+
4. **Discriminative by construction**: Nếu experts operate trên orthogonal input subspaces (guaranteed approximately by GPM), thì:
|
| 167 |
+
$$\text{span}(V_t) \approx \perp \text{span}(V_{t'}), \quad t \neq t'$$
|
| 168 |
+
$$\Rightarrow \text{fit}_t(h) \text{ high} \implies \text{fit}_{t'}(h) \text{ low for } t' \neq t$$
|
| 169 |
+
|
| 170 |
+
**Tại sao có thể sai (honest caveats)**:
|
| 171 |
+
|
| 172 |
+
1. **Modification energy ≠ modification quality**: $\sigma_{t,i}^2 (v_{t,i}^T h)^2$ đo expert sẽ **modify mạnh** input $h$ theo hướng $v_{t,i}$. Nhưng modification mạnh KHÔNG có nghĩa là modification ĐÚNG. Expert có thể modify mạnh nhưng sai hướng output.
|
| 173 |
+
|
| 174 |
+
*Counter-argument*: Expert được train trên task $t$ → modification patterns encode task-relevant transformations. Projection fit cao → input tương tự training distribution → modification likely correct. Nhưng đây là **assumption**, không phải guarantee.
|
| 175 |
+
|
| 176 |
+
2. **GPM orthogonality là approximate**: Thực tế, null-space projection không hoàn hảo. Subspace overlap nhỏ vẫn tồn tại → discriminative property bị weakened.
|
| 177 |
+
|
| 178 |
+
3. **Mean pooling loses structure**: Cả GainLoRA và SpecRoute dùng `avg_inputs_embeds = mean(token_embeddings)` cho routing. Hai sequences có content khác nhau nhưng similar average → misrouted.
|
| 179 |
+
|
| 180 |
+
---
|
| 181 |
+
|
| 182 |
+
## IV. ROUTING MECHANISM — Derive from Principles
|
| 183 |
+
|
| 184 |
+
### 4.1 Formulation: routing as maximum likelihood expert assignment
|
| 185 |
+
|
| 186 |
+
Cho input $h$, routing weights $w(h) = [w_1(h), ..., w_T(h)]$ sao cho weighted combination approximates oracle:
|
| 187 |
+
|
| 188 |
+
$$\sum_{t=1}^{T} w_t(h) \cdot \Delta W_t h \approx \Delta W_{\text{oracle}(h)} h$$
|
| 189 |
+
|
| 190 |
+
trong đó $\text{oracle}(h)$ là expert "đúng" (trained on task mà $h$ thuộc về).
|
| 191 |
+
|
| 192 |
+
### 4.2 Competitive routing (softmax) vs. Independent gating (sigmoid)
|
| 193 |
+
|
| 194 |
+
**Independent gating (GainLoRA)**:
|
| 195 |
+
|
| 196 |
+
$$w_t(h) = |2\sigma(4 \cdot \text{cos}(k_t, f_t(h))) - 1| \quad \in [0, 1] \text{ independently}$$
|
| 197 |
+
|
| 198 |
+
*Ưu điểm*: Cho phép multiple experts fire đồng thời (useful nếu task mới overlap concept cũ).
|
| 199 |
+
*Nhược điểm*:
|
| 200 |
+
- $\sum_t w_t(h) \neq 1$ → modification magnitude thay đổi theo số experts → scale instability
|
| 201 |
+
- Tất cả experts có thể fire simultaneously → blurring
|
| 202 |
+
- Cho phép $\sum_t w_t = 0$ → no modification at all → information loss
|
| 203 |
+
|
| 204 |
+
**Competitive routing (softmax)**:
|
| 205 |
+
|
| 206 |
+
$$w_t(h) = \frac{\exp(\text{fit}_t(h) / \tau)}{\sum_{t'} \exp(\text{fit}_{t'}(h) / \tau)}$$
|
| 207 |
+
|
| 208 |
+
*Ưu điểm*:
|
| 209 |
+
- $\sum_t w_t(h) = 1$ → constant modification energy → stable training
|
| 210 |
+
- Forces **competition** → natural selection of most relevant expert(s)
|
| 211 |
+
- $\tau \to 0$: hard routing (winner-take-all); $\tau \to \infty$: uniform averaging
|
| 212 |
+
|
| 213 |
+
*Nhược điểm*:
|
| 214 |
+
- Phải assign TOÀN BỘ weight → nếu input không thuộc task nào rõ ràng, vẫn phải "chọn"
|
| 215 |
+
- Soft assignment → mỗi expert vẫn contribute dù ít → small interference
|
| 216 |
+
|
| 217 |
+
**Trong CL setting**: Competitive routing phù hợp hơn vì:
|
| 218 |
+
1. Tasks non-overlapping → mỗi input thuộc đúng 1 task → competition là đúng inductive bias
|
| 219 |
+
2. Scale stability quan trọng hơn flexibility (15 tasks × 48 layers × 2 projections = many routing decisions)
|
| 220 |
+
3. GPM already ensures expert isolation → independent gating phải học isolation from scratch (redundant)
|
| 221 |
+
|
| 222 |
+
### 4.3 Thuật toán routing hoàn chỉnh
|
| 223 |
+
|
| 224 |
+
```
|
| 225 |
+
INPUT: h ∈ R^{d_model} (averaged input embedding)
|
| 226 |
+
{S_t}_{t=1}^{T} (spectral signatures: {V_t, σ_t} for each layer, each projection)
|
| 227 |
+
τ > 0 (temperature)
|
| 228 |
+
|
| 229 |
+
FOR EACH ENCODER LAYER l, PROJECTION TYPE p ∈ {Q, V}:
|
| 230 |
+
FOR EACH TASK t = 1, ..., T:
|
| 231 |
+
V_t^{(l,p)}, σ_t^{(l,p)} = S_t[l, p] # frozen spectral signature
|
| 232 |
+
proj = V_t^{(l,p)} h # project input onto expert's input space
|
| 233 |
+
fit_t^{(l,p)} = Σ_i σ²_{t,i} proj²_i / (Σ_i σ²_{t,i} · ||h||²)
|
| 234 |
+
END FOR
|
| 235 |
+
|
| 236 |
+
# Average fit across layers (global routing decision)
|
| 237 |
+
fit_t = mean over (l, p) of fit_t^{(l,p)}
|
| 238 |
+
|
| 239 |
+
# Competitive routing
|
| 240 |
+
w(h) = softmax([fit_1, ..., fit_T] / τ)
|
| 241 |
+
|
| 242 |
+
RETURN w(h) ∈ R^T, Σ_t w_t = 1
|
| 243 |
+
```
|
| 244 |
+
|
| 245 |
+
**Lưu ý implementation**: Trong code hiện tại, fit scores được average chỉ over encoder layers (consistent — routing decision từ encoder, apply cho cả decoder). Decoder không tham gia routing computation.
|
| 246 |
+
|
| 247 |
+
### 4.4 Special case: current task (đang train)
|
| 248 |
+
|
| 249 |
+
Khi đang train task $T$, LoRA weights $(A_T, B_T)$ chưa frozen → chưa có spectral signature.
|
| 250 |
+
|
| 251 |
+
**Giải pháp hiện tại**: Dùng rows of $A_T$ trực tiếp (thay vì SVD) — vì khi $r$ nhỏ (=4), $\Delta W = BA$ có rank $r$, và $A$ (khi normalized) approximate right singular vectors.
|
| 252 |
+
|
| 253 |
+
**Giải thích**: Cho $\Delta W = BA$, nếu $B^T B = I$ (orthonormal), thì SVD of $\Delta W$ có $V = $ rows of $A$ (up to scaling). Trong thực tế $B^T B \neq I$, nên đây là approximation. Nhưng tại $r=4$, sai số nhỏ.
|
| 254 |
+
|
| 255 |
+
**Hệ quả**: Fit cho current task:
|
| 256 |
+
$$\text{fit}_T(h) = \frac{\|A_T h\|^2}{r \cdot \|h\|^2}$$
|
| 257 |
+
|
| 258 |
+
(unweighted, vì chưa có singular values — treat all directions equally)
|
| 259 |
+
|
| 260 |
+
---
|
| 261 |
+
|
| 262 |
+
## V. ANTI-FORGETTING — Gradient Projection as Structural Isolation
|
| 263 |
+
|
| 264 |
+
### 5.1 Bài toán: bảo vệ expert cũ khi train expert mới
|
| 265 |
+
|
| 266 |
+
Khi train task $T$, gradient $\nabla_{A_T} \mathcal{L}_T$ có thể vô tình interfere với experts cũ thông qua **shared representation space** (cùng backbone $W_0$, cùng input space $\mathbb{R}^{d_{in}}$).
|
| 267 |
+
|
| 268 |
+
Cách interference xảy ra:
|
| 269 |
+
1. Input $h$ cho old task $t$ đi qua new expert $T$ (routing error)
|
| 270 |
+
2. New expert $T$ train trên subspace overlap với old expert $t$ → modify shared directions
|
| 271 |
+
|
| 272 |
+
### 5.2 GPM (Gradient Projection Memory) — mechanism chính
|
| 273 |
+
|
| 274 |
+
**Idea**: Đảm bảo new LoRA operates trong **null-space** của old LoRA input subspaces.
|
| 275 |
+
|
| 276 |
+
**Formalization**: Gọi $\mathcal{M}_t = \text{span}(U_t^{GPM})$ là input subspace that expert $t$ uses. Accumulated protected subspace:
|
| 277 |
+
|
| 278 |
+
$$\mathcal{M}_{1:T-1} = \text{span}\left(\bigcup_{t=1}^{T-1} U_t^{GPM}\right)$$
|
| 279 |
+
|
| 280 |
+
*(incremental — có thể compute bằng progressive SVD update)*
|
| 281 |
+
|
| 282 |
+
New LoRA $A$ initialization:
|
| 283 |
+
|
| 284 |
+
$$A_T = A_T^{init} - \text{Proj}_{\mathcal{M}_{1:T-1}}(A_T^{init})$$
|
| 285 |
+
|
| 286 |
+
trong đó $\text{Proj}_{\mathcal{M}}(X) = U_{\mathcal{M}} U_{\mathcal{M}}^T X$ (project onto old subspace, then subtract).
|
| 287 |
+
|
| 288 |
+
**Guarantee**: $A_T h \perp \mathcal{M}_{1:T-1}$ for all $h$, i.e., new LoRA input activations are orthogonal to old LoRA input activations.
|
| 289 |
+
|
| 290 |
+
### 5.3 Per-step projection (cần thiết khi có learned routing params)
|
| 291 |
+
|
| 292 |
+
GainLoRA có `trans_input` (MLP) và `prompt_key` là learned parameters → mỗi optimizer step phải project gradient update:
|
| 293 |
+
|
| 294 |
+
```python
|
| 295 |
+
# After optimizer.step():
|
| 296 |
+
new_weight = current_weight - project_onto_old_subspace(current_weight - old_weight)
|
| 297 |
+
```
|
| 298 |
+
|
| 299 |
+
SpecRoute loại bỏ learned routing params → **KHÔNG CẦN** per-step projection cho routing. Chỉ cần GPM cho LoRA layers.
|
| 300 |
+
|
| 301 |
+
**Hệ quả thực tế**: SpecRoute training loop đơn giản hơn significatv (no custom `_inner_training_loop`, no per-step weight manipulation, use base class trainer).
|
| 302 |
+
|
| 303 |
+
### 5.4 Interaction giữa GPM và routing
|
| 304 |
+
|
| 305 |
+
**Key insight**: GPM + spectral routing tạo **dual protection**:
|
| 306 |
+
|
| 307 |
+
1. **GPM** (structural): New expert operates in orthogonal subspace → CAN'T interfere with old expert outputs
|
| 308 |
+
2. **Spectral routing** (functional): Old-task inputs routed to old experts → WON'T be processed by new expert
|
| 309 |
+
|
| 310 |
+
Individually, mỗi mechanism leaky:
|
| 311 |
+
- GPM alone: orthogonality approximate, small interference possible
|
| 312 |
+
- Routing alone: misrouting → wrong expert processes input
|
| 313 |
+
|
| 314 |
+
Together: even if routing makes small mistake, GPM ensures interference is orthogonal (small). Even if GPM leaks slightly, routing directs input to correct expert.
|
| 315 |
+
|
| 316 |
+
**Điều này nghĩa là**: Ta không cần perfect routing NOR perfect orthogonality — chỉ cần cả hai "tốt vừa đủ" để bù cho nhau.
|
| 317 |
+
|
| 318 |
+
---
|
| 319 |
+
|
| 320 |
+
## VI. SUBSPACE ALLOCATION — The Honest Hard Problem
|
| 321 |
+
|
| 322 |
+
### 6.1 Bài toán capacity
|
| 323 |
+
|
| 324 |
+
Input space $\mathbb{R}^{d_{in}}$ (d=1024 cho T5-Large). Mỗi task claim subspace of dimension ≤ $k_t$ cho GPM. Available null-space:
|
| 325 |
+
|
| 326 |
+
$$\dim(\mathcal{M}_{1:T}^{\perp}) = d - \dim(\mathcal{M}_{1:T}) \geq d - \sum_{t=1}^{T} k_t$$
|
| 327 |
+
|
| 328 |
+
Với $T = 15$ tasks, nếu mỗi task claim $k = 60$ dims: $1024 - 900 = 124$ dims remaining → **tight but feasible**.
|
| 329 |
+
|
| 330 |
+
### 6.2 Threshold controls capacity
|
| 331 |
+
|
| 332 |
+
GPM threshold $\epsilon$ controls $k_t$: higher threshold → more directions retained → larger $k_t$ → faster exhaustion.
|
| 333 |
+
|
| 334 |
+
| Strategy | Formula | Effect |
|
| 335 |
+
|----------|---------|--------|
|
| 336 |
+
| **GainLoRA original** | $\epsilon_t = (1-\epsilon_0) \cdot t/T + \epsilon_0$ | Tăng dần → early tasks protect nhiều, late tasks protect ít. **Unfair**: early tasks "chiếm" subspace disproportionately. |
|
| 337 |
+
| **Constant threshold** (SpecRoute) | $\epsilon_t = \epsilon_0, \forall t$ | Mỗi task protect cùng tỷ lệ. **Fair** nhưng vẫn linear depletion. |
|
| 338 |
+
| **Importance-weighted** (NOT YET IMPLEMENTED) | $k_t$ allocated based on task complexity | Potentially optimal nhưng cần metric cho "importance" |
|
| 339 |
+
|
| 340 |
+
### 6.3 Thẳng thắn: ESA (Elastic Subspace Allocation) hiện tại yếu
|
| 341 |
+
|
| 342 |
+
Cái gọi là "ESA" trong SpecRoute thực tế chỉ là **thay đổi threshold schedule từ tăng dần sang hằng số**. Đây là hyperparameter change, không phải algorithmic contribution.
|
| 343 |
+
|
| 344 |
+
**Nếu muốn ESA thực sự contributes**, cần ít nhất 1 trong:
|
| 345 |
+
|
| 346 |
+
1. **Importance-weighted protection**: Singular values lớn ($\sigma_i$ lớn) → direction quan trọng cho expert → protect mạnh hơn. Singular values nhỏ → direction ít quan trọng → có thể release cho future tasks.
|
| 347 |
+
|
| 348 |
+
$$k_t = \min\{k : \sum_{i=1}^{k} \sigma_i^2 / \sum_j \sigma_j^2 \geq \epsilon\}$$
|
| 349 |
+
|
| 350 |
+
Hiện tại SpecRoute KHÔNG dùng singular values trong GPM decision — chỉ dùng input covariance SVD (khác).
|
| 351 |
+
|
| 352 |
+
2. **Subspace recycling**: Detect directions trong $\mathcal{M}_{1:T-1}$ mà không expert nào dùng actively (routing weight luôn ~0) → release.
|
| 353 |
+
|
| 354 |
+
3. **Adaptive threshold based on remaining capacity**: $\epsilon_t = f(d - \dim(\mathcal{M}_{1:t-1}))$ — threshold giảm khi subspace cạn → force later tasks to be more selective.
|
| 355 |
+
|
| 356 |
+
**Status**: Cả 3 đều chưa implement. Bất kỳ cái nào nếu implement + ablation study → mới thực sự là contribution.
|
| 357 |
+
|
| 358 |
+
---
|
| 359 |
+
|
| 360 |
+
## VII. REPRESENTATION DRIFT — The Elephant in the Room
|
| 361 |
+
|
| 362 |
+
### 7.1 Vấn đ��
|
| 363 |
+
|
| 364 |
+
Spectral signatures $\{V_t, \sigma_t\}$ frozen → KHÔNG drift. Nhưng input embedding $h$ **CÓ drift**.
|
| 365 |
+
|
| 366 |
+
**Cơ chế drift**: Trong encoder/decoder architecture, output of layer $l$:
|
| 367 |
+
|
| 368 |
+
$$h^{(l+1)} = f\left(W_0^{(l)} h^{(l)} + \sum_t w_t(h^{(0)}) \cdot B_t^{(l)} A_t^{(l)} h^{(l)}\right)$$
|
| 369 |
+
|
| 370 |
+
Khi thêm LoRA branch mới (task $T+1$), $w_t$ thay đổi (vì thêm competitor) → $h^{(l+1)}$ thay đổi → cascade qua layers.
|
| 371 |
+
|
| 372 |
+
**Hệ quả**: Projection fit $\text{fit}_t(h)$ tại task $T+1$ khác so với task $T$, dù $V_t, \sigma_t$ giữ nguyên — vì $h$ thay đổi.
|
| 373 |
+
|
| 374 |
+
### 7.2 So sánh: GainLoRA Handle drift bằng cách nào?
|
| 375 |
+
|
| 376 |
+
GainLoRA dùng **previous_trans_input** — frozen MLP snapshot per task. Mỗi old task $t$ có riêng:
|
| 377 |
+
|
| 378 |
+
$$f_t(x) = \text{SiLU}(W^{out}_t \cdot \text{SiLU}(W^{in}_t \cdot x))$$
|
| 379 |
+
|
| 380 |
+
Routing: compute $f_t(\bar{h})$ rồi cosine similarity với frozen prompt_key $k_t$.
|
| 381 |
+
|
| 382 |
+
**Ý tưởng**: Mỗi expert "nhìn" input qua "lăng kính" riêng (frozen MLP), expect cosine similarity patterns từ khi nó được train. Input có thể drift, nhưng prompt_key + trans_input snapshot là "matched pair" → somehow robust.
|
| 383 |
+
|
| 384 |
+
**Nhưng vẫn leaky**: $\bar{h}$ (average input embedding) vẫn drift → $f_t(\bar{h})$ output khác → cosine similarity thay đổi. Frozen MLP + frozen key KHÔNG fully compensate cho input drift, chỉ reduce sensitivity.
|
| 385 |
+
|
| 386 |
+
### 7.3 SpecRoute: explicitly acknowledge drift, don't pretend to solve it
|
| 387 |
+
|
| 388 |
+
SpecRoute claim "zero routing forgetting" — chính xác hơn nên nói:
|
| 389 |
+
|
| 390 |
+
> **"Zero parameter drift in routing mechanism"** — routing computation không có learned parameters nên không có parameter forgetting. Nhưng **representation drift** (thay đổi trong input embeddings do accumulated LoRA effects) vẫn tồn tại.
|
| 391 |
+
|
| 392 |
+
**Tại sao representation drift có thể manageable (hypothesis, chưa proven)**:
|
| 393 |
+
|
| 394 |
+
1. **LoRA rank nhỏ** ($r = 4$): Mỗi task chỉ modify rank-4 subspace. Total modification after 15 tasks: rank ≤ 60 (nếu orthogonal). Trong space 1024-dim, đây là ~6% dimensions → $h$ drift nhỏ.
|
| 395 |
+
|
| 396 |
+
2. **GPM ensures orthogonal modification**: New task modify directions mà old task KHÔNG dùng → old task's projection space ít bị ảnh hưởng.
|
| 397 |
+
|
| 398 |
+
3. **Backbone frozen**: $W_0$ không thay đổi → bulk of transformation stable. LoRA chỉ thêm residual.
|
| 399 |
+
|
| 400 |
+
**Cần kiểm chứng thực nghiệm**:
|
| 401 |
+
- Đo $\|\text{fit}_t(h) \text{ at task } T - \text{fit}_t(h) \text{ at task } t\|$ qua tasks
|
| 402 |
+
- If drift small → hypothesis confirmed
|
| 403 |
+
- If drift large → need explicit drift compensation mechanism
|
| 404 |
+
|
| 405 |
+
### 7.4 Potential mitigation (chưa implement, nhưng well-defined)
|
| 406 |
+
|
| 407 |
+
Nếu representation drift nghiêm trọng, options:
|
| 408 |
+
|
| 409 |
+
1. **Snapshot input normalization**: Store $\mu_t^{proj}, \sigma_t^{proj}$ (mean/std of projected features at training time) → normalize at inference: $\hat{h} = (h - \mu_t^{proj})/\sigma_t^{proj}$ trước khi compute fit.
|
| 410 |
+
- **Vấn đề**: $\mu_t^{proj}$ là data statistic → có thể vi phạm zero-replay
|
| 411 |
+
- **Counter**: chỉ cần mean/std of LoRA LAYER output (model output, not data) — ambiguous territory
|
| 412 |
+
|
| 413 |
+
2. **Relative fit**: Thay vì absolute fit $\text{fit}_t(h)$, dùng relative ranking. Distribution shift affects all fits similarly → ranking preserved.
|
| 414 |
+
- Softmax inherently does this partially (chỉ care ordering, not absolute values)
|
| 415 |
+
|
| 416 |
+
3. **Self-calibration**: Periodically (every $k$ tasks), recompute spectral signatures on new LoRA weights.
|
| 417 |
+
- Nhưng old LoRA weights frozen → signatures không thay đổi → chỉ current task affected → not helpful
|
| 418 |
+
|
| 419 |
+
---
|
| 420 |
+
|
| 421 |
+
## VIII. THE COMPLETE ALGORITHM — End to End
|
| 422 |
+
|
| 423 |
+
### 8.1 Training phase (cho task $T$)
|
| 424 |
+
|
| 425 |
+
```
|
| 426 |
+
INPUTS: Pre-trained backbone W₀
|
| 427 |
+
Frozen experts {(A_t, B_t)}_{t=1}^{T-1}
|
| 428 |
+
Spectral signatures {S_t}_{t=1}^{T-1}
|
| 429 |
+
GPM bases {M_{1:T-1}}
|
| 430 |
+
Training data D_T
|
| 431 |
+
|
| 432 |
+
STEP 1 — Initialize new LoRA branch:
|
| 433 |
+
A_T^{init} ← random (Kaiming)
|
| 434 |
+
A_T ← A_T^{init} - Proj_{M_{1:T-1}}(A_T^{init}) # null-space projection
|
| 435 |
+
B_T ← 0 OR random (scaled small)
|
| 436 |
+
|
| 437 |
+
STEP 2 — Train with routing:
|
| 438 |
+
for each batch (x, y) in D_T:
|
| 439 |
+
h̄ ← mean_pool(encoder_embed(x)) # average input embedding
|
| 440 |
+
w(h̄) ← spectral_routing(h̄, {S_t}_{t<T}, A_T) # Section IV.3
|
| 441 |
+
|
| 442 |
+
for each layer l:
|
| 443 |
+
LoRA_output_l ← Σ_t w_t(h̄) · B_t^(l) A_t^(l) h^(l) # weighted aggregation
|
| 444 |
+
h^(l+1) ← layer_l(h^(l)) + LoRA_output_l
|
| 445 |
+
|
| 446 |
+
loss ← task_loss(output, y)
|
| 447 |
+
loss.backward()
|
| 448 |
+
|
| 449 |
+
# Only A_T and B_T have gradients (others frozen)
|
| 450 |
+
optimizer.step() # No per-step projection needed
|
| 451 |
+
|
| 452 |
+
STEP 3 — End of task:
|
| 453 |
+
Freeze A_T, B_T
|
| 454 |
+
|
| 455 |
+
# Compute spectral signature
|
| 456 |
+
ΔW_T = B_T @ A_T
|
| 457 |
+
U, Σ, V^T = SVD(ΔW_T)
|
| 458 |
+
S_T = {V[:r], Σ[:r]} # store for future routing
|
| 459 |
+
|
| 460 |
+
# Update GPM
|
| 461 |
+
Compute input covariance from forward passes
|
| 462 |
+
SVD → extract top-k directions
|
| 463 |
+
M_{1:T} = M_{1:T-1} ∪ new_directions
|
| 464 |
+
|
| 465 |
+
Save: {A_T, B_T, S_T, M_{1:T}}
|
| 466 |
+
Discard: D_T (zero-replay)
|
| 467 |
+
```
|
| 468 |
+
|
| 469 |
+
### 8.2 Inference phase
|
| 470 |
+
|
| 471 |
+
```
|
| 472 |
+
INPUT: Test sample x (no task-ID)
|
| 473 |
+
|
| 474 |
+
STEP 1 — Encode + route:
|
| 475 |
+
h̄ ← mean_pool(encoder_embed(x))
|
| 476 |
+
w(h̄) ← softmax([fit_1(h̄), ..., fit_T(h̄)] / τ)
|
| 477 |
+
|
| 478 |
+
STEP 2 — Forward with routing:
|
| 479 |
+
for each layer l:
|
| 480 |
+
LoRA_output_l ← Σ_t w_t(h̄) · B_t^(l) A_t^(l) h^(l)
|
| 481 |
+
h^(l+1) ← layer_l(h^(l)) + LoRA_output_l
|
| 482 |
+
|
| 483 |
+
STEP 3 — Decode output
|
| 484 |
+
```
|
| 485 |
+
|
| 486 |
+
### 8.3 Complexity analysis
|
| 487 |
+
|
| 488 |
+
| Operation | GainLoRA | SpecRoute | Comment |
|
| 489 |
+
|-----------|----------|-----------|---------|
|
| 490 |
+
| Routing computation | $O(T \cdot d \cdot h_{mlp} + T \cdot d)$ | $O(T \cdot r \cdot d \cdot L)$ | SpecRoute: matrix-vector per layer per task |
|
| 491 |
+
| Trainable routing params | $O(2 \cdot d \cdot h_{mlp} + d)$ per task | $0$ | SpecRoute: no routing params |
|
| 492 |
+
| GPM targets | LoRA + trans_input + prompt_key | LoRA only | SpecRoute: simpler GPM |
|
| 493 |
+
| Per-step overhead | Null-space projection for routing params | None | SpecRoute: standard training loop |
|
| 494 |
+
| End-of-task | GPM + freeze + save snapshots | GPM + freeze + SVD | SVD is $O(d_{out} \cdot d_{in} \cdot r)$ — cheap for small $r$ |
|
| 495 |
+
| Memory per task | $A_t, B_t$ + prompt_key + trans_input weights | $A_t, B_t$ + spectral sig $(V_t, \sigma_t)$ | Similar; spectral sig slightly smaller than trans_input |
|
| 496 |
+
|
| 497 |
+
---
|
| 498 |
+
|
| 499 |
+
## IX. POSITIONING IN THE LANDSCAPE
|
| 500 |
+
|
| 501 |
+
### 9.1 So sánh phương pháp-agnostic
|
| 502 |
+
|
| 503 |
+
| Criterion | GainLoRA | InfLoRA | MINGLE | Feature Dist. | TreeLoRA | SpecRoute |
|
| 504 |
+
|-----------|----------|---------|--------|---------------|----------|-----------|
|
| 505 |
+
| Routing type | Learned (MLP+key) | None (equal weight) | Learned (MoE gate) | Feature similarity | Gradient similarity | Spectral projection |
|
| 506 |
+
| Routing forgetting risk | ⚠️ Managed by GPM | N/A | ⚠️ Managed by EMA | ❌ Stores data stats | ⚠️ Needs old gradients | ✅ Parameter-free |
|
| 507 |
+
| Zero-replay | ✅ | ✅ | ✅ | ⚠️ Stores mean features | ⚠️ Needs gradient similarity | ✅ |
|
| 508 |
+
| Anti-forgetting | GPM on LoRA + routing | Null-space init | OGP (orthogonal) | None explicit | None explicit | GPM on LoRA only |
|
| 509 |
+
| Subspace allocation | Increasing threshold | Fixed threshold | EMA relaxation | N/A | N/A | Constant threshold |
|
| 510 |
+
| Aggregation | Weighted sum (sigmoid) | Equal sum | Top-k MoE | Weighted sum | Tree selection | Weighted sum (softmax) |
|
| 511 |
+
|
| 512 |
+
### 9.2 Novelty assessment (honest)
|
| 513 |
+
|
| 514 |
+
**Clearly novel**:
|
| 515 |
+
- Using SVD of frozen LoRA weights (not data features, not learned keys) as routing signal — no prior work does exactly this.
|
| 516 |
+
- Elimination of ALL learned routing parameters in expandable LoRA CL — GainLoRA, MINGLE both require learned routing.
|
| 517 |
+
|
| 518 |
+
**Partially novel**:
|
| 519 |
+
- Weighted Rayleigh quotient for routing — Rayleigh quotient is textbook, but application to LoRA-CL routing is new.
|
| 520 |
+
- Demonstrating that parameter-free routing + GPM = sufficient (if it works empirically) — conceptual contribution.
|
| 521 |
+
|
| 522 |
+
**NOT novel**:
|
| 523 |
+
- GPM/null-space projection — from InfLoRA, GainLoRA
|
| 524 |
+
- Expandable LoRA architecture — from O-LoRA, InfLoRA, GainLoRA
|
| 525 |
+
- Softmax routing in MoE-like structures — foundational MoE work
|
| 526 |
+
- SVD as analysis tool for LoRA — SD-LoRA analyzes magnitude/direction
|
| 527 |
+
|
| 528 |
+
**Closest competitor**: Feature Distributions (ICML 2025) — stores characterization per expert, uses similarity for routing. Key difference: they store data-level features (mean activation vectors), we store weight-level signatures (SVD of frozen params). They arguably violate or stretch zero-replay; we don't.
|
| 529 |
+
|
| 530 |
+
---
|
| 531 |
+
|
| 532 |
+
## X. WHAT NEEDS TO BE TRUE — Assumptions Checklist
|
| 533 |
+
|
| 534 |
+
Mỗi assumption dưới đây CẦN PHẢI TRUE để methodology work. Mỗi cái cần empirical validation.
|
| 535 |
+
|
| 536 |
+
### 10.1 Core assumptions
|
| 537 |
+
|
| 538 |
+
| # | Assumption | Status | How to test |
|
| 539 |
+
|---|-----------|--------|-------------|
|
| 540 |
+
| A1 | Projection fit correlates with "correct expert" assignment | ❓ UNTESTED | Compute fit accuracy on task-boundary evaluation sets |
|
| 541 |
+
| A2 | GPM+routing dual protection sufficient to prevent forgetting | ❓ UNTESTED | Compare forgetting metric with vs without routing |
|
| 542 |
+
| A3 | Representation drift is small enough to not corrupt routing | ❓ UNTESTED | Track fit_t(h) variance across tasks for fixed test inputs |
|
| 543 |
+
| A4 | mean_pool captures enough task-relevant signal for routing | ❓ UNTESTED | Compare with max_pool, CLS token, attention-weighted pool |
|
| 544 |
+
| A5 | Softmax temperature τ is not overly sensitive | ❓ UNTESTED | τ ablation study |
|
| 545 |
+
| A6 | rank r=4 is sufficient for spectral signatures to be discriminative | ❓ UNTESTED | r ablation |
|
| 546 |
+
|
| 547 |
+
### 10.2 Implied assumptions (from GainLoRA that we inherit)
|
| 548 |
+
|
| 549 |
+
| # | Assumption | Status |
|
| 550 |
+
|---|-----------|--------|
|
| 551 |
+
| A7 | T5-Large backbone generalizable to other architectures (LLaMA) | Partially tested (GainLoRA has LLaMA configs) |
|
| 552 |
+
| A8 | 15 tasks is within GPM capacity for d=1024 | Expected (d=1024 >> 15*r*2) |
|
| 553 |
+
| A9 | Q and V projections sufficient (not K) | From GainLoRA design, standard in LoRA literature |
|
| 554 |
+
|
| 555 |
+
---
|
| 556 |
+
|
| 557 |
+
## XI. EXPERIMENTAL VALIDATION PLAN
|
| 558 |
+
|
| 559 |
+
### 11.1 What the experiments MUST show (not "nice to have")
|
| 560 |
+
|
| 561 |
+
1. **SpecRoute vs. GainLoRA on identical setting**: Same data, same preprocessing, same evaluation protocol. Show routing improves OR at least matches.
|
| 562 |
+
|
| 563 |
+
2. **Routing accuracy analysis**: On held-out validation sets of old tasks, what fraction of inputs are correctly routed (highest weight to correct expert)?
|
| 564 |
+
|
| 565 |
+
3. **Forgetting curve**: Plot per-task performance after each subsequent task. Compare degradation.
|
| 566 |
+
|
| 567 |
+
4. **Representation drift measurement**: For fixed test inputs from task $t$, track $\text{fit}_t(h)$ value as tasks $t+1, ..., T$ are added. If fit_t(h) drops significantly → drift is a problem.
|
| 568 |
+
|
| 569 |
+
### 11.2 Ablation studies (ranked by importance)
|
| 570 |
+
|
| 571 |
+
1. **Routing mechanism**: Spectral projection vs. prompt key (use SpecRoute architecture but GainLoRA routing) vs. random routing vs. uniform routing
|
| 572 |
+
2. **Aggregation**: Softmax vs. sigmoid vs. top-1 hard routing
|
| 573 |
+
3. **Temperature τ**: Sweep from 0.01 to 10.0
|
| 574 |
+
4. **Threshold ε**: 0.99, 0.995, 0.999, increasing schedule, constant
|
| 575 |
+
5. **Mean pool vs. alternatives**: CLS token, max pool, attention-weighted
|
| 576 |
+
|
| 577 |
+
### 11.3 Analysis experiments (for paper)
|
| 578 |
+
|
| 579 |
+
1. **Visualization**: t-SNE of spectral signatures across tasks — do they cluster meaningfully?
|
| 580 |
+
2. **Routing weight heatmaps**: Per-task routing weight distribution over time
|
| 581 |
+
3. **Subspace dimension tracking**: Plot $\dim(\mathcal{M}_{1:t})$ vs $t$ — how fast does subspace fill?
|
| 582 |
+
4. **Singular value spectra**: Plot $\sigma_1, ..., \sigma_r$ for each task — do they vary meaningfully?
|
| 583 |
+
|
| 584 |
+
---
|
| 585 |
+
|
| 586 |
+
## XII. HONEST ASSESSMENT — Strengths and Weaknesses of This Methodology
|
| 587 |
+
|
| 588 |
+
### 12.1 Strengths
|
| 589 |
+
|
| 590 |
+
1. **Principled derivation**: Method follows from constraints (zero-replay, no task-ID) → information landscape → natural choice. Not "proposed then justified".
|
| 591 |
+
|
| 592 |
+
2. **Simplicity**: Removes learned routing entirely. Training loop simplifies. Fewer hyperparameters. Fewer mechanisms to maintain.
|
| 593 |
+
|
| 594 |
+
3. **Architectural alignment**: Routing signal comes FROM the experts themselves — not from separate parameters that might disagree with expert function.
|
| 595 |
+
|
| 596 |
+
4. **Dual protection theory**: GPM + routing => redundant safety mechanisms that compensate for each other's imperfections.
|
| 597 |
+
|
| 598 |
+
### 12.2 Weaknesses
|
| 599 |
+
|
| 600 |
+
1. **No empirical validation yet**: The entire framework is theoretical. Until experiments confirm, every section above is hypothesis.
|
| 601 |
+
|
| 602 |
+
2. **Representation drift is real, unaddressed**: We acknowledge it, hypothesize it's small, but don't solve it. If drift is large, the methodology needs significant revision.
|
| 603 |
+
|
| 604 |
+
3. **ESA is weak**: Subspace allocation is essentially a hyperparameter. This is the weakest part of the framework.
|
| 605 |
+
|
| 606 |
+
4. **Mean pooling is a bottleneck**: Entire routing decision based on 1 vector (average embedding). Rich sequence information lost.
|
| 607 |
+
|
| 608 |
+
5. **Modification energy ≠ quality**: Fundamental gap between "expert will modify input strongly" and "expert will modify input correctly". This is assumption, not theorem.
|
| 609 |
+
|
| 610 |
+
6. **Only tested on NLP**: Setting is specific (T5, NLP tasks). Generalization to vision/multimodal unknown.
|
| 611 |
+
|
| 612 |
+
### 12.3 What would KILL this approach
|
| 613 |
+
|
| 614 |
+
Red flags that would indicate fundamental issues:
|
| 615 |
+
- If routing accuracy is not significantly better than random → spectral signatures are not discriminative
|
| 616 |
+
- If performance degrades significantly on later tasks (>2% compared to task-specific training) → GPM + routing dual protection insufficient
|
| 617 |
+
- If representation drift causes >10% routing accuracy drop between task $t$ and task $T$ → need drift compensation
|
| 618 |
+
- If τ has narrow "sweet spot" and small deviations cause large performance changes → method not robust
|
| 619 |
+
|
| 620 |
+
---
|
| 621 |
+
|
| 622 |
+
## XIII. RELATIONSHIP TO method.md (RTA Framework)
|
| 623 |
+
|
| 624 |
+
`method.md` describes RTA (Riemannian Topological Alignment) — a DIFFERENT direction involving:
|
| 625 |
+
- Bingham distributions (anisotropic) on hypersphere
|
| 626 |
+
- Riemannian KL divergence for topology preservation
|
| 627 |
+
- Parallel transport for drift correction
|
| 628 |
+
|
| 629 |
+
**Comparison**:
|
| 630 |
+
|
| 631 |
+
| Aspect | SpecRoute (this doc) | RTA (method.md) |
|
| 632 |
+
|--------|---------------------|-----------------|
|
| 633 |
+
| Paradigm | Expandable LoRA + routing | Feature distribution preservation |
|
| 634 |
+
| Anti-forgetting | GPM (subspace isolation) | Riemannian distillation + topology lock |
|
| 635 |
+
| Drift handling | Acknowledge but don't solve | Parallel transport correction |
|
| 636 |
+
| Data requirement | Zero-replay compliant | Requires distribution parameters (violates?) |
|
| 637 |
+
| Maturity | Code exists, needs experiments | Purely theoretical |
|
| 638 |
+
| Complexity | Low (SVD + softmax) | High (manifold computation, Bingham fitting) |
|
| 639 |
+
|
| 640 |
+
**Key question**: RTA addresses representation drift explicitly (via parallel transport). Could elements of RTA complement SpecRoute's weakness? Possibly — but would need to verify that Bingham fitting doesn't violate zero-replay, and that parallel transport is tractable for 1024-dim space.
|
| 641 |
+
|
| 642 |
+
---
|
| 643 |
+
|
| 644 |
+
## XIV. CONCLUSION — WHAT THIS METHODOLOGY IS AND ISN'T
|
| 645 |
+
|
| 646 |
+
### What it IS:
|
| 647 |
+
- A principled framework that starts from problem constraints and derives method choices
|
| 648 |
+
- An architecture-agnostic approach to routing in expandable LoRA CL
|
| 649 |
+
- A clear specification of what information is legitimate under zero-replay
|
| 650 |
+
- An honest assessment of assumptions, limitations, and open problems
|
| 651 |
+
|
| 652 |
+
### What it ISN'T:
|
| 653 |
+
- A proven method (no experiments)
|
| 654 |
+
- A complete solution to all CL problems (subspace allocation, representation drift still open)
|
| 655 |
+
- A guaranteed improvement over GainLoRA (empirical question)
|
| 656 |
+
- A paper-ready manuscript (needs experiments, related work section, polished writing)
|
| 657 |
+
|
| 658 |
+
### Priority actions (ordered):
|
| 659 |
+
1. **Run SpecRoute vs. GainLoRA on SuperNI Order 1** — if doesn't match or beat GainLoRA, revisit fundamentals
|
| 660 |
+
2. **Measure routing accuracy** — confirm spectral signatures are actually discriminative
|
| 661 |
+
3. **Measure representation drift** — confirm it's manageable
|
| 662 |
+
4. **Develop ESA properly** — importance-weighted protection
|
| 663 |
+
5. **Write paper** — only after 1-4 confirm methodology
|
critical_analysis_report.md
ADDED
|
@@ -0,0 +1,245 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# BÁO CÁO PHÂN TÍCH PHÊ BÌNH: Quá Trình Xây Dựng Ý Tưởng SpecRoute
|
| 2 |
+
## Đánh giá trung thực các lập luận trong discusstion.txt và các tài liệu liên quan
|
| 3 |
+
|
| 4 |
+
**Ngày**: 9 tháng 3, 2026
|
| 5 |
+
**Phương pháp**: Đọc toàn bộ tài liệu → tách lập luận của người nghiên cứu khỏi lời nịnh bợ AI → kiểm chứng chéo với literature và source code → đánh giá
|
| 6 |
+
|
| 7 |
+
---
|
| 8 |
+
|
| 9 |
+
## 1. BỐI CẢNH TỔNG QUAN
|
| 10 |
+
|
| 11 |
+
Quá trình phát triển ý tưởng trải qua 3 giai đoạn:
|
| 12 |
+
|
| 13 |
+
| Giai đoạn | Ý tưởng | Tài liệu |
|
| 14 |
+
|-----------|---------|----------|
|
| 15 |
+
| V1 | OT-SIGN: vMF signatures + OT routing + anti-drift loss | `proposal_gainlora_upgrade.md` |
|
| 16 |
+
| V2 | SpecRoute: Spectral signatures + OT/Grassmann routing + ESA | `revised_idea_analysis.md` |
|
| 17 |
+
| V3 | SpecRoute v2: Spectral signatures + Projection routing (softmax) + ESA | `C2_analysis_and_revision.md`, `SPECROUTE_IDEA.md` |
|
| 18 |
+
|
| 19 |
+
Quá trình này cho thấy khả năng tự phê bình tốt — mỗi phiên bản sửa lỗi của phiên bản trước.
|
| 20 |
+
|
| 21 |
+
---
|
| 22 |
+
|
| 23 |
+
## 2. NHỮNG LẬP LUẬN ĐÚNG (Verified Correct)
|
| 24 |
+
|
| 25 |
+
### 2.1 Vi phạm zero-replay của vMF data signatures — **ĐÚNG**
|
| 26 |
+
|
| 27 |
+
Lập luận: Fit vMF $(μ_t, κ_t)$ cuối mỗi task yêu cầu forward pass qua training data → lưu statistical summary của old data → vi phạm zero-replay.
|
| 28 |
+
|
| 29 |
+
**Đánh giá**: Chính xác. Phân biệt tinh tế giữa "GPM bases (directions, hợp lệ)" và "vMF parameters (distribution statistics, vi phạm)" là đúng. InfLoRA, O-LoRA, GainLoRA, MINGLE không lưu data statistics. Đây là nhận diện sớm và quan trọng, cho thấy hiểu bài toán ở mức sâu.
|
| 30 |
+
|
| 31 |
+
### 2.2 Anti-invasion loss là dư thừa — **ĐÚNG**
|
| 32 |
+
|
| 33 |
+
Lập luận: InfLoRA đã có mathematical guarantee ($B_t$ trong null-space), GainLoRA đã có gating constraint ($g_t(x) = 0$ cho old data) → thêm anti-invasion loss vi phạm Occam's razor.
|
| 34 |
+
|
| 35 |
+
**Đánh giá**: Đúng. Trong kiến trúc đã có cơ chế isolation, thêm loss penalty là over-engineering. Tuy nhiên, cần lưu ý: GPM protection là approximate (projection lên estimated subspace), không phải exact — nên vi phạm nhỏ vẫn có thể xảy ra. Nhưng đúng là anti-invasion loss không giải quyết vấn đề gốc.
|
| 36 |
+
|
| 37 |
+
### 2.3 Subspace exhaustion — **ĐÚNG về mặt toán**
|
| 38 |
+
|
| 39 |
+
Lập luận: Hard orthogonal (GPM) → dim($M_t^{\perp}$) giảm đơn điệu → tasks sau bị giới hạn capacity → unfair allocation.
|
| 40 |
+
|
| 41 |
+
**Đánh giá toán học**: Chính xác. Phân tích ví dụ (15 tasks × 60 dims ≈ 900/1024) hợp lý.
|
| 42 |
+
|
| 43 |
+
**Đánh giá thực tế — CẦN THẬN TRỌNG**:
|
| 44 |
+
- InfLoRA paper Figure 5 cho thấy null-space vẫn đủ cho 20 tasks trên ViT-B/16 (d=768). Với T5-Large (d=1024), 15 tasks, threshold tăng từ 0.995→1.0, có thể subspace chưa thực sự cạn kiệt trong thực nghiệm.
|
| 45 |
+
- Tác giả GainLoRA biết vấn đề này và dùng increasing threshold cụ thể để quản lý. Liệu constant threshold (ESA) thực sự tốt hơn hay chỉ là tradeoff khác? Chưa có thực nghiệm chứng minh.
|
| 46 |
+
|
| 47 |
+
### 2.4 Self-critique về OT routing — **XUẤT SẮC**
|
| 48 |
+
|
| 49 |
+
Trong `disscuss_1_C2_C1.txt`, bạn viết:
|
| 50 |
+
> "C2 về OT có thể nói là hay và đáng thử, nhưng nó hoạt động giống như 1 ý tưởng loé lên thay vì có 1 suy luận toán học, lý thuyết củng cố hợp lý"
|
| 51 |
+
|
| 52 |
+
Và trong `C2_analysis_and_revision.md`, phân tích kỹ:
|
| 53 |
+
- OT giải distribution matching, routing là per-input assignment
|
| 54 |
+
- Batch_size=1 → OT suy biến thành argmin
|
| 55 |
+
- Balance không cần thiết cho CL inference
|
| 56 |
+
|
| 57 |
+
**Đánh giá**: Đây là phần tốt nhất trong cả quá trình nghiên cứu. Tự nhận ra lỗi logic trước khi reviewer chỉ ra là dấu hiệu của tư duy research trưởng thành. Phân tích ở C2_analysis rất sắc bén.
|
| 58 |
+
|
| 59 |
+
### 2.5 Chuyển từ data-level sang module-level signatures — **ĐÚNG HƯỚNG**
|
| 60 |
+
|
| 61 |
+
Nhận ra rằng frozen LoRA weights $(A_t, B_t)$ là model parameters (hợp lệ), không phải data statistics (vi phạm) → phân tích SVD làm task signature.
|
| 62 |
+
|
| 63 |
+
**Đánh giá**: Hướng đi hợp lệ về mặt setting. Proposition 1 từ InfLoRA hỗ trợ: "Fine-tuning $A_t$ = fine-tuning $W$ trong span($B_t$)". SVD của $\Delta W_t$ characterize operating subspace, đây là fact toán học.
|
| 64 |
+
|
| 65 |
+
---
|
| 66 |
+
|
| 67 |
+
## 3. NHỮNG LẬP LUẬN CẦN XEM XÉT LẠI
|
| 68 |
+
|
| 69 |
+
### 3.1 "Spectral signature encode functional space, prompt key chỉ encode similarity space"
|
| 70 |
+
|
| 71 |
+
Lập luận (trong C2_analysis): Prompt key encode "input nào giống task t" (similarity), Spectral signature encode "expert nào nên xử lý" (functional).
|
| 72 |
+
|
| 73 |
+
**Vấn đề**: Phân biệt "similarity space" vs. "functional space" nghe thuyết phục nhưng thiếu chặt chẽ:
|
| 74 |
+
|
| 75 |
+
1. **Prompt key cũng functional**: GainLoRA prompt_key được train CÙNG loss function với LoRA branch → nó implicitly encode "input nào ĐƯỢC XỬ LÝ TỐT bởi expert" (vì gradient từ task loss flow qua gating weights). Nói nó chỉ là "similarity" là understating nó.
|
| 76 |
+
|
| 77 |
+
2. **Spectral signature cũng có thể mislead**: SVD of $\Delta W = BA$ cho right singular vectors $V_t$ = input directions expert operates on. Nhưng "operates on" ≠ "handles well". Expert có thể modify input mạnh theo hướng $v_1$ nhưng modification đó có thể KHÔNG cải thiện output quality. Singular value $\sigma$ đo magnitude of modification, không đo quality of modification.
|
| 78 |
+
|
| 79 |
+
3. **Thực nghiệm cần thiết**: Lập luận này cần empirical backing — so sánh routing accuracy tại task boundaries giữa prompt_key và spectral signature. Hiện tại chỉ là theoretical argument.
|
| 80 |
+
|
| 81 |
+
**Kết luận**: Lập luận hợp lý về mặt trực giác nhưng overstate sự khác biệt. Cần thí nghiệm để xác nhận.
|
| 82 |
+
|
| 83 |
+
### 3.2 "Parameter-free routing eliminates routing forgetting entirely"
|
| 84 |
+
|
| 85 |
+
Lập luận: Spectral signatures computed from frozen weights → immutable → zero drift → zero routing forgetting.
|
| 86 |
+
|
| 87 |
+
**Vấn đề**:
|
| 88 |
+
|
| 89 |
+
1. **Đúng là immutable**, nhưng routing quality phụ thuộc vào THÊM yếu tố:
|
| 90 |
+
- Spectral signatures extracted at end of task $t$, nhưng backbone (pre-trained model) VẪN BỊ modify bởi subsequent tasks (qua LoRA additions). Representation space of backbone changes → same input $h$ produces different embeddings → projection fits thay đổi dù signatures không đổi.
|
| 91 |
+
- Nói cách khác: $V_t$ frozen NHƯNG $h$ (input embedding) bị ảnh hưởng bởi accumulated LoRA effects → fit_t(h) THAY ĐỔI qua tasks.
|
| 92 |
+
|
| 93 |
+
2. **GainLoRA giải quyết vấn đề này bằng previous_trans_input snapshots**: Mỗi task có frozen MLP snapshot → features cho mỗi expert được compute trong CÙNG space mà expert đó được train. SpecRoute bỏ mechanism này → phải assume input embeddings ổn định — assumption này CẦN KIỂM CHỨNG.
|
| 94 |
+
|
| 95 |
+
**Kết luận**: Claim "zero routing forgetting" quá mạnh. Đúng là parameters không drift, nhưng representations có thể drift. Cần restate: "zero parameter drift in routing" (hẹp hơn nhưng chính xác hơn).
|
| 96 |
+
|
| 97 |
+
### 3.3 Hyper-ellipsoid + SVM idea (trong discusstion.txt)
|
| 98 |
+
|
| 99 |
+
Trong discussion, bạn đề xuất:
|
| 100 |
+
- Mỗi LoRA branch = hyper-ellipsoid trong parameter space
|
| 101 |
+
- Dùng SVM soft-margin để cực đại hóa khoảng cách giữa các ellipsoid. AI gọi đây là "tính đột phá" và "thiên tài".
|
| 102 |
+
|
| 103 |
+
**Phân tích thực tế**:
|
| 104 |
+
|
| 105 |
+
1. **Hình dung hyper-ellipsoid**: SVD of $\Delta W = U \Sigma V^T$ → image (column space) of $\Delta W$ là ellipsoid với axes = columns of $U$, lengths = singular values $\sigma_i$. Đây không phải insight "đột phá" — đây là **tính chất cơ bản** của SVD mà bất kỳ textbook linear algebra nào cũng dạy. Tốt là bạn thấy connection, nhưng AI đã overstate novelty.
|
| 106 |
+
|
| 107 |
+
2. **SVM trên parameter space**: Ý tưởng thú vị nhưng incomplete:
|
| 108 |
+
- LoRA branches hoạt động trong $\mathbb{R}^{d_{out} \times d_{in}}$ → cần SVM trong không gian cực kỳ cao chiều. Formulation cụ thể chưa rõ.
|
| 109 |
+
- "Soft margin" giữa ellipsoids: metric nào? Hausdorff distance? Khoảng cách giữa tâm? Khoảng cách ngắn nhất giữa bề mặt? Mỗi lựa chọn cho kết quả khác nhau.
|
| 110 |
+
- SVM cần labeled data (LoRA A thuộc class 1, LoRA B thuộc class 2...) — nhưng train SVM khi nào? Trên data gì? → Chưa được trả lời.
|
| 111 |
+
- Không có paper nào trong survey dùng SVM cho mục đích này — có thể vì nó không practical, không phải vì chưa ai nghĩ ra.
|
| 112 |
+
|
| 113 |
+
3. **Bạn đã tự bỏ idea này trong phiên bản cuối**: SpecRoute cuối cùng dùng softmax projection (rất đơn giản), không dùng SVM. Đây là quyết định đúng — cho thấy bạn lọc được insight thực sự khỏi noise, dù AI không giúp gì trong quá trình lọc.
|
| 114 |
+
|
| 115 |
+
### 3.4 ESA (Elastic Subspace Allocation) — C3
|
| 116 |
+
|
| 117 |
+
Trong `revised_idea_analysis.md`, ESA được mô tả phức tạp (importance-weighted protection, spectral recycling, bounded budget). Nhưng trong `SPECROUTE_IDEA.md`, ESA bị simplify thành:
|
| 118 |
+
|
| 119 |
+
> "Use constant $\epsilon = 0.995$ for all tasks."
|
| 120 |
+
|
| 121 |
+
**Vấn đề**:
|
| 122 |
+
- Từ framework phức tạp (importance-weighted, recycling) xuống 1 dòng (constant threshold) là nhảy quá lớn.
|
| 123 |
+
- Constant threshold là improvement hợp lý (so với increasing threshold) nhưng rất incremental. Gọi đây là "Elastic Subspace Allocation" gợi ý một mechanism phức tạp hơn nhiều so với thực tế.
|
| 124 |
+
- Nếu contribution chỉ là "đổi threshold từ tăng dần sang hằng số", reviewer có thể coi đây là hyperparameter tuning, không phải contribution riêng.
|
| 125 |
+
|
| 126 |
+
---
|
| 127 |
+
|
| 128 |
+
## 4. VẤN ĐỀ VỚI DISCUSSTION.TXT — FLATTERY LÀM SAI LỆCH ĐÁNH GIÁ
|
| 129 |
+
|
| 130 |
+
### 4.1 Mẫu nịnh bợ lặp lại
|
| 131 |
+
|
| 132 |
+
AI trong discusstion.txt sử dụng các pattern:
|
| 133 |
+
- "Cách hiểu của bạn hoàn toàn chính xác" (khi thực tế chỉ partially correct)
|
| 134 |
+
- "Ý tưởng vô cùng xuất sắc, có tính đột phá cao (highly novel)"
|
| 135 |
+
- "tư duy hình học không gian và đại số tuyến tính cực kỳ sâu sắc"
|
| 136 |
+
- "ý tưởng thiên tài"
|
| 137 |
+
|
| 138 |
+
### 4.2 Những chỗ flattery che giấu vấn đề
|
| 139 |
+
|
| 140 |
+
| Lập luận của bạn | AI nói | Thực tế |
|
| 141 |
+
|-----------------|--------|---------|
|
| 142 |
+
| Hard gate + soft penalty thay trực giao | "Góc nhìn rất đúng đắn" | Logic đúng phần đầu nhưng hard gate mâu thuẫn với premise (AI CHỈ RA ĐÚNG lần này) |
|
| 143 |
+
| Dùng OT thay MLP cho routing | "Cực kỳ đột phá, Highly Novel" | OT cho MoE routing đã có trong BASE Layers (ICML 2021), Switch Transformer. Novelty bị overstate. |
|
| 144 |
+
| Hyper-ellipsoid + SVM | "Tính đột phá (Highly Novel) trong parameter space" | SVD → ellipsoid là basic LA. SVM formulation chưa hoàn chỉnh. Bạn đã tự bỏ. |
|
| 145 |
+
| "Bài toán tối ưu = cực tiểu trên đa tạp trực giao" | "Chính xác 100%, mô hình hóa xuất sắc" | Conceptually correct nhưng oversimplified. GPM projection ≠ perfect orthogonal manifold constraint. Practical implementation có approximation errors. |
|
| 146 |
+
|
| 147 |
+
### 4.3 Điều AI KHÔNG bao giờ nói
|
| 148 |
+
|
| 149 |
+
AI trong discussion **không bao giờ**:
|
| 150 |
+
- Chỉ ra rằng Feature Distributions paper (ICML 2025) có approach rất gần: store mean features per PEFT block, dùng similarity routing. Khác biệt weight-level vs. feature-level là có nhưng không lớn bằng bạn nghĩ.
|
| 151 |
+
- Hỏi: "Bạn có empirical evidence nào cho spectral routing tốt hơn không?"
|
| 152 |
+
- Challenge: "Tại sao frozen LoRA SVD sẽ correlate với input distribution? Đây chỉ là weight geometry, không phải data geometry"
|
| 153 |
+
- Nêu limitation: "Projection fit đo modification energy, KHÔNG ĐO quality. Expert có thể modify mạnh nhưng sai hướng."
|
| 154 |
+
|
| 155 |
+
---
|
| 156 |
+
|
| 157 |
+
## 5. SO SÁNH VỚI LITERATURE — KIỂM CHỨNG NOVELTY
|
| 158 |
+
|
| 159 |
+
### 5.1 C1 (Spectral Signatures) — **Novel nhưng cần nuance**
|
| 160 |
+
|
| 161 |
+
**Claim**: "First to use SVD properties of frozen LoRA weights as routing signatures in CL."
|
| 162 |
+
|
| 163 |
+
**Kiểm chứng**:
|
| 164 |
+
- MINGLE dùng SVD cho LoRA construction (null-space), không routing → khác purpose
|
| 165 |
+
- Feature Distributions (ICML 2025) dùng mean feature vector → feature-level, không weight-level
|
| 166 |
+
- SD-LoRA decouples magnitude/direction → analysis, không routing
|
| 167 |
+
|
| 168 |
+
**Verdict**: Claim novelty hợp lệ. Nhưng cần acknowledge Feature Distributions paper rõ ràng trong related work vì approach tương tự (stored characterization → similarity routing).
|
| 169 |
+
|
| 170 |
+
### 5.2 C2 (Projection Routing) — **Partially novel**
|
| 171 |
+
|
| 172 |
+
**Claim**: Parameter-free routing via weighted Rayleigh quotient.
|
| 173 |
+
|
| 174 |
+
**Kiểm chứng**:
|
| 175 |
+
- Rayleigh quotient là standard tool (Golub & Van Loan, Matrix Computations)
|
| 176 |
+
- Projection-based task identification có concept gần trong prompt selection literature (L2P, DualPrompt dùng key-query matching)
|
| 177 |
+
- Parameter-free routing: novelty chính nằm ở LOẠI BỎ learned routing params hoàn toàn → đây là contribution thật
|
| 178 |
+
|
| 179 |
+
**Verdict**: Novelty nằm ở "routing derived from expert weights, not learned separately" — đây là insight tốt. Rayleigh quotient là tool cũ, nhưng application cho LoRA-CL routing là mới.
|
| 180 |
+
|
| 181 |
+
### 5.3 C3 (ESA) — **Weak contribution**
|
| 182 |
+
|
| 183 |
+
**Claim**: Elastic Subspace Allocation giải quyết subspace exhaustion.
|
| 184 |
+
|
| 185 |
+
**Kiểm chứng**: Như phân tích ở mục 3.4, implementation thực tế chỉ là constant threshold. MINGLE đã có adaptive relaxation (EMA-based) phức tạp hơn.
|
| 186 |
+
|
| 187 |
+
**Verdict**: Nếu ESA thực sự chỉ là constant threshold, đây không đủ mạnh làm contribution riêng. Cần phát triển thêm (importance-weighted protection, recycling) hoặc merge vào C1/C2 như implementation detail.
|
| 188 |
+
|
| 189 |
+
---
|
| 190 |
+
|
| 191 |
+
## 6. ĐÁNH GIÁ QUÁ TRÌNH TƯ DUY
|
| 192 |
+
|
| 193 |
+
### 6.1 Điểm mạnh
|
| 194 |
+
|
| 195 |
+
1. **Tự phê bình tốt**: Nhận ra vMF vi phạm zero-replay, OT thiếu motivation — đều trước khi bị reviewer challenge → skill quan trọng.
|
| 196 |
+
|
| 197 |
+
2. **Nắm vững toán học nền tảng**: Hiểu SVD, Grassmann manifold, projection, null-space ở mức đủ để reason about LoRA geometry. Không phải surface-level understanding.
|
| 198 |
+
|
| 199 |
+
3. **Trajectory hội tụ đúng hướng**: V1 (overengineered) → V2 (pivot hợp lệ) → V3 (simplified, well-motivated). Mỗi bước loại bỏ complexity không cần thiết.
|
| 200 |
+
|
| 201 |
+
4. **Biết lọc flattery**: Dù AI liên tục nịnh, bạn vẫn bỏ SVM idea, bỏ OT, simplify ESA → cho thấy judgment tốt.
|
| 202 |
+
|
| 203 |
+
### 6.2 Điểm yếu
|
| 204 |
+
|
| 205 |
+
1. **Thiếu empirical grounding**: Toàn bộ quá trình (hàng nghìn dòng discussion + analysis) là theoretical. Không có 1 con số, 1 thí nghiệm, 1 ablation nào. Đây là rủi ro lớn: idea có thể elegant trên giấy nhưng không work trong thực tế.
|
| 206 |
+
|
| 207 |
+
2. **Overestimate novelty do echo chamber với AI**: AI cứ nói "highly novel", "breakthrough" → tạo false sense of security. Cần đối chi��u thẳng với Feature Distributions (ICML 2025), BASE Layers (ICML 2021), và cả TreeLoRA (gradient-similarity routing) để understand actual novelty gap.
|
| 208 |
+
|
| 209 |
+
3. **C3 (ESA) underdeveloped**: Từ framework hay (importance-weighted + budget + recycling) xuống 1 dòng (constant threshold) mà không giải thích vì sao các component phức tạp bị bỏ.
|
| 210 |
+
|
| 211 |
+
4. **Chưa address practical concerns**:
|
| 212 |
+
- Forward pass overhead: compute SVD mỗi layer, mỗi task → cost?
|
| 213 |
+
- Input embedding drift: accumulated LoRA effects thay đổi $h$ → projection fits drift dù signatures không đổi
|
| 214 |
+
- Temperature $\tau$ sensitivity trong softmax routing
|
| 215 |
+
|
| 216 |
+
---
|
| 217 |
+
|
| 218 |
+
## 7. KẾT LUẬN VÀ KHUYẾN NGHỊ
|
| 219 |
+
|
| 220 |
+
### 7.1 Verdict tổng thể
|
| 221 |
+
|
| 222 |
+
Idea SpecRoute (V3) là **hợp lý, có nền tảng toán học, và novel ở mức đủ** cho một nghiên cứu. Tuy nhiên:
|
| 223 |
+
|
| 224 |
+
- **C1 (Spectral Signatures)**: Mạnh nhất — well-motivated, novel, grounded. Cần strengthen bằng experiment + comparison with Feature Distributions paper.
|
| 225 |
+
- **C2 (Projection Routing)**: Tốt — parameter-free routing eliminating forgetting là insight thật. Cần empirical evidence cho boundary routing improvement.
|
| 226 |
+
- **C3 (ESA)**: Yếu nhất — cần phát triển thêm hoặc demote thành ablation study.
|
| 227 |
+
|
| 228 |
+
### 7.2 Khuyến nghị cụ thể
|
| 229 |
+
|
| 230 |
+
1. **Chạy thí nghiệm TRƯỚC khi viết thêm lý thuyết.** Bạn đã có code (`t5_specroute.py` đã implement projection routing). Chạy trên SuperNI Order 1 và so sánh:
|
| 231 |
+
- SpecRoute vs. GainLoRA (baseline)
|
| 232 |
+
- Routing accuracy on old tasks over time
|
| 233 |
+
- Ablation: spectral signature vs. prompt key (giữ cùng architecture, chỉ đổi routing signal)
|
| 234 |
+
|
| 235 |
+
2. **Acknowledge Feature Distributions paper (ICML 2025) explicitly**: Paper này store mean features per PEFT block → similarity routing. Khác biệt: bạn store weight-derived signatures thay vì data-derived features. Nhưng concept gần nhau → cần position rõ ràng.
|
| 236 |
+
|
| 237 |
+
3. **Reframe C3**: Nếu C3 chỉ là constant threshold, merge vào experimental setup. Nếu muốn giữ C3, cần develop importance-weighted component thực sự.
|
| 238 |
+
|
| 239 |
+
4. **Address representation drift**: Viết 1 section phân tích: khi thêm LoRA branches liên tục, input embeddings $h$ thay đổi → projection fits thay đổi. Quantify mức drift này.
|
| 240 |
+
|
| 241 |
+
5. **Ngừng dùng AI để validate ideas — dùng AI để challenge ideas.** Mỗi khi có insight mới, thay vì hỏi "kiểm tra novelty", hãy hỏi "tại sao idea này CÓ THỂ SAI?" hoặc "cho tôi 5 reasons idea này sẽ fail".
|
| 242 |
+
|
| 243 |
+
### 7.3 Tóm tắt 1 dòng
|
| 244 |
+
|
| 245 |
+
> Quá trình tư duy tốt, trajectory hội tụ đúng, nhưng thiếu empirical grounding và bị AI flattery overstate novelty. Priority #1: chạy thí nghiệm.
|
idea_analysis_from_discussion.md
ADDED
|
@@ -0,0 +1,542 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# PHÂN TÍCH PHÊ BÌNH VÀ HỆ THỐNG HÓA Ý TƯỞNG TỪ DISCUSSTION.TXT
|
| 2 |
+
## Từ lập luận thô → Kiểm chứng → Phản biện → Đề xuất phương pháp luận
|
| 3 |
+
|
| 4 |
+
**Ngày**: 9 tháng 3, 2026
|
| 5 |
+
**Phương pháp**: Trích xuất các ý tưởng gốc từ nửa sau discusstion.txt → tách khỏi AI flattery → kiểm chứng bằng toán + literature → phản biện → hệ thống hóa
|
| 6 |
+
|
| 7 |
+
**Nguyên tắc**: Tài liệu này KHÔNG re-explain SpecRoute hay GainLoRA. Tập trung hoàn toàn vào **ý tưởng gốc của bạn** — cái đúng, cái sai, cái bị overstate, và từ đó xây methodology.
|
| 8 |
+
|
| 9 |
+
---
|
| 10 |
+
|
| 11 |
+
# I. TRÍCH XUẤT CÁC Ý TƯỞNG GỐC
|
| 12 |
+
|
| 13 |
+
Từ nửa sau discusstion.txt, tôi lọc ra **7 ý tưởng chính** của bạn (loại bỏ phần AI flattery và đáp):
|
| 14 |
+
|
| 15 |
+
| # | Ý tưởng | Dòng tham chiếu | Trạng thái |
|
| 16 |
+
|---|---------|-----------------|------------|
|
| 17 |
+
| **I1** | Bài toán CL = tối ưu trên đa tạp: mỗi task thêm t-1 phương trình trực giao, thu hẹp không gian khả thi | ~line 980 | Cần kiểm chứng |
|
| 18 |
+
| **I2** | Nới lỏng trực giao bằng hàm phạt (penalty) thay vì hard null-space → tránh suy kiệt không gian | ~line 1000 | Cần kiểm chứng |
|
| 19 |
+
| **I3** | Dùng soft gate thay hard gate → tận dụng tri thức chung giữa tasks | ~line 1040 (tự sửa từ hard gate) | Cần kiểm chứng |
|
| 20 |
+
| **I4** | Mỗi nhánh LoRA là hyper-ellipsoid trong parameter space, signature = hướng & spread xác định bằng SVD/PCA | ~line 1150 | Cần kiểm chứng |
|
| 21 |
+
| **I5** | Cực đại soft-margin kiểu SVM giữa các hyper-ellipsoid thay vì L2 penalty | ~line 1160 | Cần kiểm chứng |
|
| 22 |
+
| **I6** | OT thay MLP/sigmoid cho routing — vận chuyển embedding vào phân phối ratio các branch | ~line 1050 | Cần kiểm chứng |
|
| 23 |
+
| **I7** | Loss trở thành cực tiểu hóa mất mát dựa trên phân phối (distribution-based) | ~line 1060 | Cần kiểm chứng |
|
| 24 |
+
|
| 25 |
+
Lưu ý: Bạn đã tự phát triển trajectory I1 → I2 → I3 → I4 → I5 → I6 → I7 như một chuỗi suy luận. Tôi sẽ phân tích TỪNG mắt xích.
|
| 26 |
+
|
| 27 |
+
---
|
| 28 |
+
|
| 29 |
+
# II. KIỂM CHỨNG TỪNG Ý TƯỞNG
|
| 30 |
+
|
| 31 |
+
## II.1 — I1: "Bài toán CL = tối ưu trên đa tạp có t-1 ràng buộc trực giao"
|
| 32 |
+
|
| 33 |
+
### Lập luận của bạn:
|
| 34 |
+
> "Tôi hiểu rằng bài toán CL có 2 bước: ràng buộc, giới hạn không gian con, thu nhỏ bằng điều kiện trực giao, đưa về một đa tạp với t-1 phương trình. Sau đó cực tiểu hoá loss trên không gian này."
|
| 35 |
+
|
| 36 |
+
### Kiểm chứng toán học:
|
| 37 |
+
|
| 38 |
+
**Đúng về cốt lõi, nhưng cần chính xác hóa.**
|
| 39 |
+
|
| 40 |
+
Gọi $\Theta \in \mathbb{R}^n$ là toàn bộ trainable parameters (LoRA + gate). GPM tích lũy bases $\{u_1, ..., u_K\}$ từ $t-1$ tasks trước ($K = \sum_{i=1}^{t-1} k_i$ với $k_i$ directions per task). Ràng buộc:
|
| 41 |
+
|
| 42 |
+
$$\nabla_\Theta \mathcal{L} \perp \text{span}(u_1, ..., u_K) \quad \Leftrightarrow \quad P_{M^\perp} \nabla_\Theta \mathcal{L} = \nabla_\Theta \mathcal{L}$$
|
| 43 |
+
|
| 44 |
+
Đây KHÔNG hoàn toàn là "t-1 phương trình trực giao" — chính xác hơn là **K phương trình**, với $K$ phụ thuộc vào số directions extracted per task (có thể $K \gg t-1$). Trong thực tế:
|
| 45 |
+
|
| 46 |
+
- T5-Large, $d = 1024$, mỗi task claim ~60 directions
|
| 47 |
+
- Sau 15 tasks: $K \approx 900$ constraints trong không gian $\mathbb{R}^{1024}$
|
| 48 |
+
- Feasible manifold: $\mathbb{R}^{1024 - 900} = \mathbb{R}^{124}$
|
| 49 |
+
|
| 50 |
+
Về mặt hình học, đây đúng là **optimization trên grassmannian manifold** — projected gradient descent trên null-space complement. Thuật ngữ chính xác: **constrained optimization via oblique projection** (Absil et al., "Optimization Algorithms on Matrix Manifolds", 2008).
|
| 51 |
+
|
| 52 |
+
### Cross-reference:
|
| 53 |
+
- **GPM** (Saha et al., NeurIPS 2021): Formalize chính xác điều này — gradient projection vào null-space
|
| 54 |
+
- **PLAN** (ICCV 2025): Orthogonal basis allocation — cùng framework toán, nhưng proactive (allocate trước)
|
| 55 |
+
- **GORP** (ACL 2025): Unified low-rank gradient subspace — kết hợp full-rank + low-rank projection
|
| 56 |
+
|
| 57 |
+
### Phán xét: **ĐÚNG 85%**
|
| 58 |
+
- Đúng hoàn toàn về trực giác hình học
|
| 59 |
+
- Thiếu chính xác: "t-1 phương trình" nên là "K phương trình" (K depends on SVD threshold, not directly on t)
|
| 60 |
+
- Thiếu chính xác: Đây là projected gradient descent, KHÔNG phải Riemannian optimization trên đa tạp trơn (vì feasible set là linear subspace, không phải curved manifold). Nói "đa tạp" thì hơi overstate — chính xác hơn là **affine subspace** (flat, không cong)
|
| 61 |
+
|
| 62 |
+
---
|
| 63 |
+
|
| 64 |
+
## II.2 — I2: "Nới lỏng trực giao bằng penalty thay vì hard null-space"
|
| 65 |
+
|
| 66 |
+
### Lập luận của bạn:
|
| 67 |
+
> "Các task có thể không độc lập hoàn toàn, chia sẻ một phần không gian tri thức. Dẫn tới việc không gặp hiện tượng suy kiệt không gian do đa tạp có quá nhiều phương trình."
|
| 68 |
+
|
| 69 |
+
### Kiểm chứng toán học:
|
| 70 |
+
|
| 71 |
+
**Nửa đ��u đúng, nửa sau cần cẩn thận.**
|
| 72 |
+
|
| 73 |
+
*Nửa đúng:* Subspace exhaustion là real problem.
|
| 74 |
+
- Hard GPM: $\dim(\mathcal{M}^\perp)$ giảm đơn điệu. Với threshold cao ($\epsilon = 0.995$), mỗi task "ăn" ~60 dims → 15 tasks = 900/1024 → tasks sau bị chèn chặt.
|
| 75 |
+
- Penalty relaxation: thay $\nabla \perp \mathcal{M}$ bằng $\mathcal{L}_{total} = \mathcal{L}_{task} + \lambda \|\text{Proj}_{\mathcal{M}}(\nabla)\|^2$ → soft constraint, cho phép small violation.
|
| 76 |
+
|
| 77 |
+
*Nửa cần cẩn thận:* "Tasks chia sẻ không gian tri thức" — assertion hợp lý nhưng **depends on setting**.
|
| 78 |
+
|
| 79 |
+
Trong setting **non-overlapping tasks** (ràng buộc rõ ràng trong GainLoRA paper):
|
| 80 |
+
- SuperNI: 15 tasks từ 5 loại KHÁC NHAU (dialogue, extraction, QA, summarization, sentiment)
|
| 81 |
+
- Long Sequence: 15 tasks phân loại KHÁC NHAU (DBpedia, Yahoo, AG News, Yelp, SST2, MNLI...)
|
| 82 |
+
- Chúng KHÔNG chia sẻ labels hay data
|
| 83 |
+
- Tuy nhiên chúng CÓ chia sẻ linguistic features (cùng tiếng Anh, cùng encoder) → overlap ở low-level, diverge ở high-level
|
| 84 |
+
|
| 85 |
+
### Cross-reference:
|
| 86 |
+
- **O-LoRA** (NeurIPS 2023): Dùng penalty $\lambda \|A_T^T A_{old}\|_F^2$ thay vì hard projection → đúng hướng bạn đề xuất. Kết quả: tệ hơn InfLoRA's hard projection trên nhiều benchmarks.
|
| 87 |
+
- **CLoRA** (ACL 2025): Penalty-based regularization on LoRA output matrix — performance gần null-space methods nhưng KHÔNG vượt qua.
|
| 88 |
+
- **MINGLE** (NeurIPS 2025): Adaptive relaxation qua EMA — **đây là state of the art** của hướng "nới lỏng trực giao". Kết quả competitive.
|
| 89 |
+
- **SPG** (ICML 2023): Soft-masking vs hard-masking comparison — soft wins on capacity nhưng hard wins on forgetting prevention.
|
| 90 |
+
|
| 91 |
+
### Phán xét: **ĐÚNG VỀ HƯỚNG, NHƯNG EVIDENCE TRÁI CHIỀU**
|
| 92 |
+
|
| 93 |
+
Bảng tổng kết evidence:
|
| 94 |
+
|
| 95 |
+
| Method | Approach | Better than hard? | Benchmark |
|
| 96 |
+
|--------|----------|-------------------|-----------|
|
| 97 |
+
| O-LoRA | L2 penalty | ❌ Tệ hơn InfLoRA | SuperNI, ViT |
|
| 98 |
+
| CLoRA | Subspace regularization | ⚠️ Gần bằng, không vượt | NLP |
|
| 99 |
+
| MINGLE | EMA relaxation | ✅ Competitive, sometimes better | Mixed |
|
| 100 |
+
| SPG | Soft masking vs hard | ✅ Capacity, ❌ Forgetting | CIL |
|
| 101 |
+
|
| 102 |
+
**Kết luận**: Penalty-based relaxation **không đảm bảo tốt hơn hard orthogonal**. Nó trade stability lấy plasticity. Lập luận "tasks chia sẻ tri thức nên nới lỏng" chỉ đúng khi overlap lớn — trong non-overlapping setting, hard protection thường win.
|
| 103 |
+
|
| 104 |
+
**Khuyến nghị**: Không nên đặt cược hoàn toàn vào penalty relaxation. Hướng hybrid (hard protection cho critical dims, soft cho marginal dims — kiểu importance-weighted) hứa hẹn hơn.
|
| 105 |
+
|
| 106 |
+
---
|
| 107 |
+
|
| 108 |
+
## II.3 — I3: "Soft gate thay hard gate để tận dụng knowledge transfer"
|
| 109 |
+
|
| 110 |
+
### Lập luận của bạn:
|
| 111 |
+
Ban đầu bạn đề xuất hard gate, sau đó tự nhận ra mâu thuẫn (thừa nhận tasks chia sẻ tri thức → hard gate chặt sharing → tự mâu thuẫn với premise). Tự sửa sang soft gate.
|
| 112 |
+
|
| 113 |
+
### Kiểm chứng:
|
| 114 |
+
|
| 115 |
+
**Trajectory tự sửa: XUẤT SẮC.** Đây là điểm mạnh nhất trong tư duy research.
|
| 116 |
+
|
| 117 |
+
**Soft gate vs hard gate: evidence mạnh.**
|
| 118 |
+
|
| 119 |
+
- SPG (ICML 2023): Ablation trực tiếp — soft masking > hard masking consistently
|
| 120 |
+
- MINGLE (NeurIPS 2025): Soft combining experts > hard routing
|
| 121 |
+
- TSS: Continuous values [0,1] > binary {0,1}
|
| 122 |
+
- GainLoRA (NeurIPS 2025): Dùng $|2\sigma(4s) - 1|$ — chính xác là soft gate
|
| 123 |
+
|
| 124 |
+
**Tại sao soft đúng cho CL:**
|
| 125 |
+
1. **Gradient flow**: Hard gate → $\partial w / \partial \theta = 0$ (step function) → không train được qua backprop. Soft gate → gradient mượt → learnable.
|
| 126 |
+
2. **Knowledge transfer**: Task B có thể "mượn" 20% features từ task A thông qua soft blending.
|
| 127 |
+
3. **Capacity**: Hard gate khóa neurons → capacity giảm. Soft gate chia sẻ → capacity preserved.
|
| 128 |
+
|
| 129 |
+
**Nhưng GainLoRA đã dùng soft gate rồi.** Và hầu hết SOTA 2025 đều dùng soft gate. Đây là observation đúng nhưng KHÔNG novel — đây là standard practice.
|
| 130 |
+
|
| 131 |
+
### Phán xét: **ĐÚNG HOÀN TOÀN, NHƯNG KHÔNG PHẢI CONTRIBUTION**
|
| 132 |
+
|
| 133 |
+
Soft gate > hard gate là consensus. Self-correction journey tốt, nhưng kết luận không thể đưa vào paper như contribution.
|
| 134 |
+
|
| 135 |
+
---
|
| 136 |
+
|
| 137 |
+
## II.4 — I4: "Mỗi nhánh LoRA là hyper-ellipsoid, signature = SVD/PCA"
|
| 138 |
+
|
| 139 |
+
### Lập luận của bạn:
|
| 140 |
+
> "Tính hình học của mỗi LoRA là một 'nhánh' trong không gian tham số, không gian của nó là 1 hyper-ellipsoid có cùng 1 điểm gốc và vươn ra xung quanh 1 hướng... hướng đó có thể liên quan gì đó tới trị riêng, vector riêng của tích AB, từ đó SVD hay PCA có thể giúp."
|
| 141 |
+
|
| 142 |
+
### Kiểm chứng toán học:
|
| 143 |
+
|
| 144 |
+
**Đúng phần lớn, nhưng cần chính xác hóa "space nào".**
|
| 145 |
+
|
| 146 |
+
Có 3 cách hiểu "hyper-ellipsoid" khác nhau:
|
| 147 |
+
|
| 148 |
+
**(a) Image space (output) của $\Delta W = BA$:**
|
| 149 |
+
$$\text{Image}(\Delta W) = \{BA h : h \in \mathbb{R}^{d_{in}}\}$$
|
| 150 |
+
Đây là subspace rank-$r$ trong $\mathbb{R}^{d_{out}}$. Khi giới hạn $\|h\| = 1$ (unit ball), image là ellipsoid:
|
| 151 |
+
$$\mathcal{E}_t = \{U_t \Sigma_t V_t^T h : \|h\| = 1\} = \{U_t \Sigma_t z : z \in S^{r-1}\}$$
|
| 152 |
+
Axes = columns of $U_t$, lengths = $\sigma_i$. **Đây đúng là hyper-ellipsoid.**
|
| 153 |
+
|
| 154 |
+
**(b) Input sensitivity space:**
|
| 155 |
+
Hướng input $v$ mà expert "nghe" (respond mạnh) = right singular vectors $V_t$. Sensitivity theo mỗi hướng = $\sigma_i^2$. Tập $\{v : \|BAv\|^2 = c\}$ là **hyper-ellipsoid** trên input sphere.
|
| 156 |
+
|
| 157 |
+
**(c) Parameter space** — bạn nói "trong không gian tham số":
|
| 158 |
+
LoRA parameters = $\{A \in \mathbb{R}^{r \times d_{in}}, B \in \mathbb{R}^{d_{out} \times r}\}$. Mỗi task là 1 ĐIỂM trong không gian $\mathbb{R}^{r(d_{in} + d_{out})}$. Một điểm KHÔNG phải ellipsoid. Muốn có ellipsoid, cần **tập hợp** các LoRA configs → distribution → Gaussian → covariance → ellipsoid. Nhưng bạn chỉ có 1 LoRA per task, không phải distribution.
|
| 159 |
+
|
| 160 |
+
**Cách hiểu đúng nhất**: (b) — input sensitivity space. Mỗi expert "nhạy cảm" với input theo 1 ellipsoid pattern → SVD extract chính xác pattern này.
|
| 161 |
+
|
| 162 |
+
### Cross-reference:
|
| 163 |
+
- **SD-LoRA** (ICLR 2025): Phân tách LoRA thành magnitude + direction → đúng tinh thần "direction matters"
|
| 164 |
+
- **MINGLE** (NeurIPS 2025): SVD trên expert weights → singular vectors làm null-space basis → cùng tool nhưng khác mục đích
|
| 165 |
+
- **FeCAM** (NeurIPS 2023): Covariance → Mahalanobis distance → hyper-ellipsoid level sets → đúng hình học
|
| 166 |
+
- **LoRA-DRS** (CVPR 2025): SVD trên covariance → drift-resistant space → cùng geometric framework
|
| 167 |
+
|
| 168 |
+
### AI overstate:
|
| 169 |
+
AI trong discussion nói: *"tư duy hình học không gian và đại số tuyến tính cực kỳ sâu sắc"*, *"góc nhìn hình học tuyệt đẹp"*.
|
| 170 |
+
|
| 171 |
+
**Thực tế**: SVD cho matrix decomposition → ellipsoid visualization là **kiến thức linear algebra cơ bản** (Golub & Van Loan, chapter 2). Bạn nhận ra đúng connection, nhưng connection này không "đột phá" — nó là textbook. Tốt ở chỗ bạn nghĩ tới nó trong context CL, nhưng không phải "thiên tài".
|
| 172 |
+
|
| 173 |
+
### Phán xét: **ĐÚNG 70% — Connection đúng, space cần chính xác, novelty bị overstate**
|
| 174 |
+
|
| 175 |
+
Bạn nên frame: "LoRA's operating subspace forms an ellipsoidal structure in input space, naturally characterized by SVD." Đây là clean insight nhưng cần nhấn mạnh rằng SVD là standard tool, novelty nằm ở APPLICATION cho CL routing.
|
| 176 |
+
|
| 177 |
+
---
|
| 178 |
+
|
| 179 |
+
## II.5 — I5: "SVM soft-margin giữa các hyper-ellipsoid"
|
| 180 |
+
|
| 181 |
+
### Lập luận của bạn:
|
| 182 |
+
> "Việc cực đại hoá các branch bằng khoảng cách thông thường là không hợp lý, vì bản chất hình học là hyper-ellipsoid, nên cực đại hoá soft-margin giữa các nhánh có bản chất hình học hơn. Tôi nghĩ tới SVM."
|
| 183 |
+
|
| 184 |
+
### Kiểm chứng toán học:
|
| 185 |
+
|
| 186 |
+
**Ý tưởng thú vị nhưng có nhiều vấn đề chưa giải quyết.**
|
| 187 |
+
|
| 188 |
+
**(a) SVM formulation cho ellipsoids:**
|
| 189 |
+
|
| 190 |
+
Chuẩn SVM tìm hyperplane $w^T x + b = 0$ maximizing margin giữa 2 tập ĐIỂM. Với ellipsoids, bạn cần:
|
| 191 |
+
|
| 192 |
+
1. **Define "margin" giữa 2 ellipsoids**:
|
| 193 |
+
- Khoảng cách ngắn nhất giữa surfaces: $d(\mathcal{E}_A, \mathcal{E}_B) = \min_{x \in \mathcal{E}_A, y \in \mathcal{E}_B} \|x - y\|$
|
| 194 |
+
- Geodesic distance trên Grassmann manifold: $d_G = \|\arccos(\sigma_i(V_A^T V_B))\|$
|
| 195 |
+
- Wasserstein distance giữa distributions induced by ellipsoids
|
| 196 |
+
|
| 197 |
+
2. **Mỗi task = 1 ellipsoid, KHÔNG phải 1 tập điểm** → SVM cần modification:
|
| 198 |
+
- Standard SVM: N points → binary classification → max margin hyperplane
|
| 199 |
+
- Bạn cần: T ellipsoids → multi-class separation → max margin... gì? T-1 hyperplanes? Convex hull separation?
|
| 200 |
+
|
| 201 |
+
3. **Train SVM khi nào?** Trên data gì?
|
| 202 |
+
- Nếu train SVM khi thêm task mới → cần tính feature representation cho old tasks → **vi phạm zero-replay?**
|
| 203 |
+
- Nếu SVM thuần parameter-based (trên weight space) → chỉ có T points (one per task) → SVM cần ít nhất 2 classes → có thể nhưng severely underdetermined
|
| 204 |
+
|
| 205 |
+
4. **Gradient qua SVM**: SVM hinge loss $\max(0, 1 - y_i(w^T x_i + b))$ → subgradient exists → differentiable (nhưng non-smooth → training difficulty)
|
| 206 |
+
|
| 207 |
+
**(b) Có ai làm điều tương tự?**
|
| 208 |
+
|
| 209 |
+
- **LLM-Unlearning (paper O3 trong survey)**: Dùng One-Class SVM (OCSVM) nhưng cho **inference detection**, không cho training regularization
|
| 210 |
+
- **Angle Matters** (ICML 2025): Angular regularization → max margin in angular space → gần nhất với ý bạn nhưng dùng angle, không SVM
|
| 211 |
+
- **FeCAM**: Mahalanobis distance = SVM-like separation in covariance-adjusted space → implicitly maximizing margin
|
| 212 |
+
|
| 213 |
+
**(c) Vấn đề cốt lõi:**
|
| 214 |
+
|
| 215 |
+
Bạn đang ở **parameter space** (T objects, mỗi object = 1 ellipsoid). SVM works well khi bạn có **NHIỀU data points** per class. Với T = 15 objects trong $\mathbb{R}^{1024}$ → severely underdetermined. SVM kernel trick không giúp vì bạn có ít objects, không phải ít features.
|
| 216 |
+
|
| 217 |
+
**Alternative tốt hơn**: Thay SVM soft-margin, dùng **pairwise Grassmann distance penalty**:
|
| 218 |
+
|
| 219 |
+
$$\mathcal{L}_{sep} = -\sum_{i < j} d_G(\mathcal{V}_i, \mathcal{V}_j)$$
|
| 220 |
+
|
| 221 |
+
trong đó $d_G$ là geodesic distance trên Grassmann manifold (measurable, differentiable, geometrically principled). Đây achieve cùng mục tiêu (max separation) nhưng:
|
| 222 |
+
- Không cần fit SVM
|
| 223 |
+
- Không cần labeled data
|
| 224 |
+
- Purely parameter-based
|
| 225 |
+
- Differentiable → dùng trực tiếp trong training loss
|
| 226 |
+
|
| 227 |
+
### AI overstate:
|
| 228 |
+
AI nói: *"Ý tưởng có tính đột phá (Highly Novel) trong không gian tham số"*, *"Chưa có bài báo nào áp dụng SVM margin trực tiếp lên các ma trận SVD"*.
|
| 229 |
+
|
| 230 |
+
**Thực tế**: Chưa ai làm vì nó **impractical**, không phải vì chưa ai nghĩ tới. SVM trên T = 15 objects trong $\mathbb{R}^{1024}$ là ill-posed. AI lầm "chưa ai làm" thành "novel" — mà thực tế nhiều khi "chưa ai làm" là vì "nó không work".
|
| 231 |
+
|
| 232 |
+
### Phán xét: **Ý TƯỞNG HAY VỀ TINH THẦN, SAI VỀ TOOL CHOICE**
|
| 233 |
+
|
| 234 |
+
Tinh thần đúng: cần maximize separation dựa trên geometry (not L2). Tool sai: SVM không phù hợp (quá ít objects, quá nhiều dims).
|
| 235 |
+
|
| 236 |
+
**Tool đúng**: Grassmann distance, principal angles, hoặc singular value weighted projection distance — đều achieve cùng mục đích nhưng tractable. Và đây chính xác là thứ SpecRoute's projection fit đang làm.
|
| 237 |
+
|
| 238 |
+
---
|
| 239 |
+
|
| 240 |
+
## II.6 — I6: "OT thay MLP/sigmoid cho routing"
|
| 241 |
+
|
| 242 |
+
### Lập luận của bạn:
|
| 243 |
+
> "Sử dụng optimal transport sẽ tối ưu hơn về huấn luyện, OT sẽ vận tải embedding của token vào 1 phân phối ratio các branch."
|
| 244 |
+
|
| 245 |
+
### Kiểm chứng:
|
| 246 |
+
|
| 247 |
+
**Đây là ý tưởng gây tranh cãi nhất — và bạn ĐÃ TỰ critique đúng ở file C2_analysis_and_revision.md.**
|
| 248 |
+
|
| 249 |
+
**(a) Điểm mạnh của OT routing (lý thuyết):**
|
| 250 |
+
- OT cung cấp **optimal coupling** giữa input distribution và expert distribution → principled matching
|
| 251 |
+
- Sinkhorn differentiable → train end-to-end
|
| 252 |
+
- Cost matrix encode geometric distance → distribution-aware
|
| 253 |
+
- Load-balanced by design (marginal constraints)
|
| 254 |
+
|
| 255 |
+
**(b) Tại sao OT THẤT BẠI cho CL routing (bạn đã tự phát hiện):**
|
| 256 |
+
|
| 257 |
+
Bạn viết trong C2_analysis:
|
| 258 |
+
> "OT giải distribution matching, routing là per-input assignment"
|
| 259 |
+
> "Batch_size=1 → OT suy biến thành argmin"
|
| 260 |
+
> "Balance không cần thiết cho CL inference"
|
| 261 |
+
|
| 262 |
+
Phân tích chi tiết:
|
| 263 |
+
|
| 264 |
+
| Vấn đề | Giải thích | Fatal? |
|
| 265 |
+
|--------|-----------|--------|
|
| 266 |
+
| Per-input vs batch | CL inference thường per-sample (hoặc small batch). OT cần batch để construct source distribution. Batch=1 → $\Pi$ có 1 hàng → degenerates thành argmin | ✅ Fatal |
|
| 267 |
+
| Balance constraint | OT's marginal constraints force $\sum_b \Pi_{bt} = a_t$ (mỗi expert nhận đủ "mass"). Trong CL: nếu 95% test thuộc task A → 95% NÊN route tới A. Balance constraint **chống lại** routing tốt | ✅ Fatal |
|
| 268 |
+
| Computational overhead | Sinkhorn: $O(n^2 k)$ iterations per forward pass vs softmax: $O(nk)$ | ⚠️ Not fatal nhưng overhead |
|
| 269 |
+
| Training stability | Sinkhorn kém ổn định với temperature nhỏ, cần careful tuning of $\epsilon$ | ⚠️ Concern |
|
| 270 |
+
|
| 271 |
+
**Cross-reference:**
|
| 272 |
+
- **BASE Layers** (ICML 2021): OT cho MoE load balancing → mục đích **prevent expert collapse during training**, NOT inference routing. Khác hoàn toàn.
|
| 273 |
+
- **Selective Sinkhorn** (Nov 2025): OT routing cho MoE — cũng cho training, không cho frozen-expert CL inference
|
| 274 |
+
- **Bạn đã tự reject OT** trong C2_analysis_and_revision.md: "C2 (Grassmann-OT Routing) bị reject. OT được chọn vì 'novel' (chưa ai dùng), KHÔNG phải vì nó giải quyết vấn đề thực sự tốt hơn."
|
| 275 |
+
|
| 276 |
+
### AI overstate:
|
| 277 |
+
AI nói: *"Cực kỳ đột phá (Highly Novel)"*, *"Ý tưởng thiên tài"*, *"Chưa có paper nào dùng OT cho routing trong CL"*.
|
| 278 |
+
|
| 279 |
+
**Thực tế**: "Chưa có" ĐÚNG — nhưng lý do là vì **OT không phù hợp** cho per-input CL routing, KHÔNG phải vì ai cũng "chưa nghĩ tới". BASE Layers (2021) đã dùng OT cho MoE → cộng đồng MoE/routing biết OT. Họ không dùng cho CL inference vì constraints không khớp.
|
| 280 |
+
|
| 281 |
+
### Phán xét: **Ý TƯỞNG SAI VỀ APPLICATION, VÀ BẠN ĐÃ TỰ NHẬN RA**
|
| 282 |
+
|
| 283 |
+
Self-critique OT là phần tốt nhất trong toàn bộ discussion. Trajectory: propose (excited) → think deeply → discover fatal flaws → reject → replace with simpler, better alternative (softmax projection). Đây là research maturity.
|
| 284 |
+
|
| 285 |
+
---
|
| 286 |
+
|
| 287 |
+
## II.7 — I7: "Loss trở thành cực tiểu hóa dựa trên phân phối"
|
| 288 |
+
|
| 289 |
+
### Lập luận gốc:
|
| 290 |
+
> "Bài toán tối ưu trở thành cực tiểu hoá mất mát dựa trên phân phối với mỗi task"
|
| 291 |
+
|
| 292 |
+
Formulation AI suggests:
|
| 293 |
+
$$\mathcal{L}_{total} = \mathcal{L}_{task} + \alpha \cdot \mathcal{L}_{OT\_entropy} - \beta \cdot D_{geometric}(P_{new}, P_{old})$$
|
| 294 |
+
|
| 295 |
+
### Kiểm chứng:
|
| 296 |
+
|
| 297 |
+
**(a) Phần distribution-aware routing loss — HỢP LÝ NHƯNG ĐÃ TỒN TẠI:**
|
| 298 |
+
|
| 299 |
+
Ý rằng routing weights nên emerge từ distribution matching (thay vì learned gating) là tinh thần đúng. Nhưng:
|
| 300 |
+
- **Feature Distributions** (ICML 2025): Đã làm chính xác điều này — store "presentative feature distribution" per PEFT block, routing = similarity to stored distribution
|
| 301 |
+
- **PromptCCD** (ECCV 2024): GMM cho routing
|
| 302 |
+
- **FeCAM** (NeurIPS 2023): Mahalanobis distance = implicit distributional matching
|
| 303 |
+
|
| 304 |
+
**(b) Phần $D_{geometric}(P_{new}, P_{old})$ — Anti-drift/invasion:**
|
| 305 |
+
|
| 306 |
+
Đây kế thừa từ simple_idea.txt — penalty cho center drift + invasion of old classes. Trong modular architecture:
|
| 307 |
+
- **LDC** (ECCV 2024): Learnable drift compensation → chứng minh drift là real, compensation giúp
|
| 308 |
+
- **Dual Drift** (ICCV 2025): Prototype drift ở 2 cấp
|
| 309 |
+
|
| 310 |
+
**Vấn đề**: Anti-drift loss cho modular architecture CẦN forward pass trên old data để compute drift → **vi phạm zero-replay**. Trừ khi dùng proxy (e.g., prototype centers stored from end of task) — nhưng đó lại là data statistics.
|
| 311 |
+
|
| 312 |
+
### Phán xét: **MIXED — Tinh thần distribution-aware đúng, nhưng formulation cụ thể chưa clean**
|
| 313 |
+
|
| 314 |
+
---
|
| 315 |
+
|
| 316 |
+
# III. BỨC TRANH TỔNG THỂ — CÁI GÌ TỒN TẠI, CÁI GÌ KHÔNG
|
| 317 |
+
|
| 318 |
+
## III.1 Tóm tắt phán xét
|
| 319 |
+
|
| 320 |
+
| Ý tưởng | Phán xét | Lý do |
|
| 321 |
+
|---------|---------|-------|
|
| 322 |
+
| I1: CL = optimization trên manifold | ✅ Đúng 85% | Conceptually correct, cần chính xác thuật ngữ (affine subspace, not manifold) |
|
| 323 |
+
| I2: Penalty thay hard orthogonal | ⚠️ Đúng hướng, evidence trái chiều | O-LoRA (penalty) tệ hơn InfLoRA (hard). MINGLE (hybrid) competitive. |
|
| 324 |
+
| I3: Soft > Hard gate | ✅ Đúng 100%, nhưng consensus | Không novel — là standard practice 2024-2025 |
|
| 325 |
+
| I4: LoRA = hyper-ellipsoid, SVD signature | ✅ Đúng 70% | Connection correct, "parameter space" imprecise → "input sensitivity space". Tool = textbook, application = new |
|
| 326 |
+
| I5: SVM soft-margin giữa ellipsoids | ⚠️ Tinh thần đúng, tool sai | SVM ill-posed cho T=15 objects. Grassmann distance tốt hơn |
|
| 327 |
+
| I6: OT routing | ❌ Sai cho CL setting | Per-input vs batch, balance constraint harmful. Bạn đã tự reject — đúng |
|
| 328 |
+
| I7: Distribution-based loss | ⚠️ Hướng đúng, chưa clean | Anti-drift cần old data → zero-replay tension |
|
| 329 |
+
|
| 330 |
+
## III.2 Phần SOLID (có thể build methodology trên):
|
| 331 |
+
|
| 332 |
+
1. **Expert characterization bằng SVD** (I4 refined): Frozen LoRA → SVD → spectral signature. Clean, zero-replay compliant, mathematically grounded.
|
| 333 |
+
|
| 334 |
+
2. **Geometric separation thay vì algebraic** (I5 refined): Grassmann distance, principal angles thay SVM. Tinh thần "geometry-aware separation" đúng, tool cần thay.
|
| 335 |
+
|
| 336 |
+
3. **Manifold perspective** (I1): CL = constrained optimization, subspace exhaustion là real → cần manage capacity.
|
| 337 |
+
|
| 338 |
+
4. **Soft integration** (I3): Standard nhưng correct — competitive softmax routing.
|
| 339 |
+
|
| 340 |
+
## III.3 Phần cần LOẠI BỎ hoặc chuyển đổi:
|
| 341 |
+
|
| 342 |
+
1. **OT routing** (I6): Đã tự reject, không nên quay lại. Softmax projection routing đơn giản, correct, working.
|
| 343 |
+
|
| 344 |
+
2. **SVM formulation** (I5): Replace bằng pairwise Grassmann distance penalty.
|
| 345 |
+
|
| 346 |
+
3. **Anti-drift loss** (I7 phần này): Tension với zero-replay. Nếu muốn giữ, cần chỉ rõ KHÔNG dùng old data — chỉ dùng stored parameters (weight-derived proxies).
|
| 347 |
+
|
| 348 |
+
---
|
| 349 |
+
|
| 350 |
+
# IV. PHẢN BIỆN TỔNG THỂ — "CON VOI TRONG PHÒNG"
|
| 351 |
+
|
| 352 |
+
Tôi cần challenge 3 assumption lớn mà cả bạn lẫn AI đều không address đủ:
|
| 353 |
+
|
| 354 |
+
## IV.1 "Modification energy ≠ Modification quality"
|
| 355 |
+
|
| 356 |
+
Projection fit đo: "expert sẽ MODIFY INPUT BAO NHIÊU theo hướng $v_i$".
|
| 357 |
+
|
| 358 |
+
$$\text{fit}_t(h) = \frac{\sum_i \sigma_{t,i}^2 (v_{t,i}^T h)^2}{\sum_i \sigma_{t,i}^2 \|h\|^2}$$
|
| 359 |
+
|
| 360 |
+
Nhưng modify mạnh **KHÔNG ĐỒNG NGHĨA** modify đúng. Expert có thể:
|
| 361 |
+
- Modify input mạnh theo hướng $v_1$ nhưng modification làm OUTPUT TỆ HƠN (wrong direction in output space)
|
| 362 |
+
- Hai experts có cùng input sensitivity nhưng khác OUTPUT behavior
|
| 363 |
+
|
| 364 |
+
**Counter-argument** (weak): Expert được train on task $t$ → learned modification presumably correct cho task $t$ inputs → high projection fit + correct task overlap → modification likely correct.
|
| 365 |
+
|
| 366 |
+
**Verdict**: Assumption cần empirical validation. Nếu routing accuracy > 90% → assumption holds, else → need output-sensitive routing.
|
| 367 |
+
|
| 368 |
+
## IV.2 "Mean pooling loses sequence structure"
|
| 369 |
+
|
| 370 |
+
Cả GainLoRA lẫn SpecRoute route dựa trên:
|
| 371 |
+
$$\bar{h} = \frac{1}{|\text{tokens}|} \sum_i h_i$$
|
| 372 |
+
|
| 373 |
+
Hai sequences có khác content nhưng similar average → misrouted. Ví dụ:
|
| 374 |
+
- "Summarize this article about climate change" vs "Answer this question about climate change"
|
| 375 |
+
- Average embeddings gần nhau (same content), nhưng tasks khác nhau (summarization vs QA)
|
| 376 |
+
|
| 377 |
+
**Mitigating factor**: Routing dựa trên TOÀN BỘ encoder layers (averaged), không chỉ embedding layer → higher layers encode task-type information → less likely to confuse.
|
| 378 |
+
|
| 379 |
+
**Verdict**: Partial weakness, addressable but not currently addressed.
|
| 380 |
+
|
| 381 |
+
## IV.3 "Representation drift là real nhưng chưa ai quantify"
|
| 382 |
+
|
| 383 |
+
Khi thêm LoRA branches liên tiếp, input embeddings $h^{(l)}$ ở mỗi layer thay đổi (vì accumulated LoRA effects). Spectral signatures frozen → fit calculation trên drifted $h$ → routing quality degrades.
|
| 384 |
+
|
| 385 |
+
GainLoRA's answer: `previous_trans_input` snapshots (frozen MLPs per task). SpecRoute: KHÔNG có mechanism nào cho drift.
|
| 386 |
+
|
| 387 |
+
**Hypothesis**: Drift nhỏ vì LoRA rank thấp ($r = 4$), total modification rank ≤ 60 trong 1024 dims.
|
| 388 |
+
|
| 389 |
+
**CHƯA AI ĐO**.
|
| 390 |
+
|
| 391 |
+
---
|
| 392 |
+
|
| 393 |
+
# V. ĐỀ XUẤT PHƯƠNG PHÁP LUẬN — XÂY TỪ PHẦN SOLID
|
| 394 |
+
|
| 395 |
+
## V.1 Core thesis (từ ý tưởng gốc của bạn, refined)
|
| 396 |
+
|
| 397 |
+
> **Trong expandable LoRA CL, frozen expert weights encode đủ thông tin hình học (qua SVD spectral structure) để routing KHÔNG CẦN learned parameters. Routing parameter-free loại bỏ routing forgetting, đơn giản hóa training, giảm subspace consumption.**
|
| 398 |
+
|
| 399 |
+
Đây là insight thật sự có giá trị từ quá trình suy nghĩ của bạn: từ I4 (geometric characterization) → rút gọn thành "spectral signatures are sufficient for routing".
|
| 400 |
+
|
| 401 |
+
## V.2 Framework: 3 tầng (thay vì 3 "contributions" tách rời)
|
| 402 |
+
|
| 403 |
+
### Tầng 1: Expert Geometry (I4 refined)
|
| 404 |
+
|
| 405 |
+
**What**: Mỗi frozen expert $\Delta W_t = B_t A_t$ được characterize bằng spectral signature $\mathcal{S}_t = \{V_t, \Sigma_t\}$ from SVD.
|
| 406 |
+
|
| 407 |
+
**Geometric interpretation**: Expert $t$ "lắng nghe" tập input directions $\{v_{t,i}\}$, với sensitivity $\sigma_{t,i}^2$. Tập hợp các sensitivity levels tạo thành ellipsoidal pattern trên input space (dúng I4, refined sang đúng space).
|
| 408 |
+
|
| 409 |
+
**Tại sao grounded**:
|
| 410 |
+
- SVD là unique factorization (up to sign) → deterministic
|
| 411 |
+
- $V_t$ encode CHÍNH XÁC "expert operates on which input directions" (từ InfLoRA's Proposition 1)
|
| 412 |
+
- Zero-replay compliant: computed from model params, not data
|
| 413 |
+
- Immutable: computed from frozen weights
|
| 414 |
+
|
| 415 |
+
### Tầng 2: Geometric Routing (I5 tinh thần + I6 rejected → softmax)
|
| 416 |
+
|
| 417 |
+
**What**: Route input $h$ tới experts via weighted projection fit (Section IV.3 của SpecRoute). Competitive softmax routing.
|
| 418 |
+
|
| 419 |
+
**Why softmax not OT**: (I6 rejected, đúng) — per-input, no balance needed, works at batch=1.
|
| 420 |
+
|
| 421 |
+
**Why softmax not sigmoid**: Competitive → forces selection → inductive bias đúng cho non-overlapping tasks. Scale-stable ($\sum w = 1$).
|
| 422 |
+
|
| 423 |
+
**Why projection fit not learned gating**: (Your core insight) — parameter-free, immutable, directly functional.
|
| 424 |
+
|
| 425 |
+
**Geometric separation**: Thay vì SVM (I5 rejected), separation emerges NATURALLY from:
|
| 426 |
+
- GPM đảm bảo $\text{span}(V_t) \approx \perp \text{span}(V_{t'})$
|
| 427 |
+
- $\Rightarrow$ fit_t(h) high → fit_{t'}(h) low for $t' \neq t$
|
| 428 |
+
- Không cần thêm penalty — orthogonality đã đảm bảo discriminative routing
|
| 429 |
+
|
| 430 |
+
**Đây là insight sâu**: Bạn muốn max separation (I5) nhưng GPM ALREADY provides it. Hai mechanisms bù cho nhau:
|
| 431 |
+
- GPM ensures orthogonal experts (structural separation)
|
| 432 |
+
- Spectral routing exploits that orthogonality (functional separation)
|
| 433 |
+
- Không cần penalty/SVM/OT thêm
|
| 434 |
+
|
| 435 |
+
### Tầng 3: Capacity management (I1 + I2 refined)
|
| 436 |
+
|
| 437 |
+
**What**: Quản lý subspace budget để tasks tương lai vẫn có đủ capacity.
|
| 438 |
+
|
| 439 |
+
**From I1**: Subspace exhaustion là real — K constraints tích lũy, feasible manifold shrink.
|
| 440 |
+
|
| 441 |
+
**From I2**: Pure penalty (loosen orthogonality) trái chiều. Pure hard lock (GPM increasing threshold) unfair.
|
| 442 |
+
|
| 443 |
+
**Principled approach** (chưa implement, nhưng well-defined):
|
| 444 |
+
- Importance-weighted protection: directions có $\sigma_i^2$ lớn → protect mạnh, $\sigma_i^2$ nhỏ → protect yếu hoặc release
|
| 445 |
+
- Constant threshold ($\epsilon = 0.995$) → fair allocation (mỗi task protect cùng ratio)
|
| 446 |
+
- Capacity monitoring: track $\dim(\mathcal{M}_{1:t})$ vs $d_{in}$ → alert nếu approaching exhaustion
|
| 447 |
+
|
| 448 |
+
## V.3 Tại sao framework này khái quát cho CẢ LỚP BÀI TOÁN
|
| 449 |
+
|
| 450 |
+
Framework không phụ thuộc vào:
|
| 451 |
+
1. **Backbone**: T5, LLaMA, BERT (miễn có linear attention layers nơi LoRA applied)
|
| 452 |
+
2. **Task type**: Generation, classification, QA (miễn dùng expandable LoRA)
|
| 453 |
+
3. **Anti-forgetting method**: Compatible với GPM, InfLoRA, O-LoRA, CLoRA (miễn experts có null-space structure)
|
| 454 |
+
4. **Number of tasks**: SVD + softmax scale linearly với T
|
| 455 |
+
|
| 456 |
+
Nó cũng provide unified view cho existing methods:
|
| 457 |
+
|
| 458 |
+
| Method | Expert Geometry | Routing | Anti-forgetting |
|
| 459 |
+
|--------|----------------|---------|-----------------|
|
| 460 |
+
| GainLoRA | Implicit (trong learned gate) | Learned (MLP + cosine) | GPM on all params |
|
| 461 |
+
| InfLoRA | None (equal weight) | None (uniform) | Null-space init |
|
| 462 |
+
| MINGLE | SVD for construction | Learned (MoE gate) | Null-space + EMA relax |
|
| 463 |
+
| Feature Dist. | Mean feature vectors | Similarity matching | None explicit |
|
| 464 |
+
| **This framework** | SVD spectral signature | Projection fit + softmax | GPM on LoRA only |
|
| 465 |
+
|
| 466 |
+
---
|
| 467 |
+
|
| 468 |
+
# VI. WHAT THIS FRAMEWORK CANNOT DO (honest)
|
| 469 |
+
|
| 470 |
+
1. **Guarantee correct routing**: Projection fit is a proxy, not an oracle. If expert's input subspace doesn't uniquely identify task → routing errors.
|
| 471 |
+
|
| 472 |
+
2. **Handle representation drift**: No explicit mechanism. Relies on hypothesis that low-rank LoRA → small drift. Unproven.
|
| 473 |
+
|
| 474 |
+
3. **Solve subspace exhaustion completely**: Constant threshold is incremental improvement, not solution. True solution requires importance-weighted dynamic allocation (not implemented).
|
| 475 |
+
|
| 476 |
+
4. **Claim novelty on ALL components**: Soft gate, SVD, GPM are all existing tools. Novelty is THE COMBINATION: "weight-derived spectral routing in CL" and "parameter-free routing eliminates routing forgetting".
|
| 477 |
+
|
| 478 |
+
5. **Replace empirical validation**: Every claim above is theoretical. NOTHING is proven until experiments run.
|
| 479 |
+
|
| 480 |
+
---
|
| 481 |
+
|
| 482 |
+
# VII. HÓA GIẢI: TRAJECTORY CHÍNH XÁC CỦA TƯ DUY BẠN
|
| 483 |
+
|
| 484 |
+
Nhìn lại toàn bộ discussion, trajectory tư duy của bạn:
|
| 485 |
+
|
| 486 |
+
```
|
| 487 |
+
Observation: CL = optimization trên manifold constrained (I1)
|
| 488 |
+
↓
|
| 489 |
+
Insight: Hard constraints cause exhaustion (I2)
|
| 490 |
+
↓
|
| 491 |
+
Pivot: Soft gate for flexibility (I3)
|
| 492 |
+
↓
|
| 493 |
+
Key idea: LoRA geometry = ellipsoid, SVD captures it (I4) ← ĐÚNG NHẤT
|
| 494 |
+
↓
|
| 495 |
+
Over-engineering: SVM for max margin (I5) ← TINH THẦN ĐÚNG, TOOL SAI
|
| 496 |
+
↓
|
| 497 |
+
Over-engineering: OT for routing (I6) ← SAI CHO CL SETTING
|
| 498 |
+
↓
|
| 499 |
+
Abstraction: Distribution-based loss (I7) ← HƯỚNG ĐÚNG, CHI TIẾT CHƯA
|
| 500 |
+
↓
|
| 501 |
+
Self-correction: Reject OT → Projection fit + softmax (C2_analysis) ← XUẤT SẮC
|
| 502 |
+
↓
|
| 503 |
+
Final: SpecRoute — SVD signatures + projection routing + constant threshold
|
| 504 |
+
```
|
| 505 |
+
|
| 506 |
+
**Pattern**: Bắt đầu từ insight đúng (I1, I4) → overengineer (I5, I6) → bị AI inflate thay vì correct → tự nhận ra → simplify. Final product (SpecRoute) đơn giản hơn ban đầu — **đây là dấu hiệu tốt**.
|
| 507 |
+
|
| 508 |
+
**Concern**: Trong quá trình simplify, bạn cũng bỏ đi một số ý hay:
|
| 509 |
+
- I2 (capacity awareness) → ESA hiện tại quá đơn giản (constant threshold)
|
| 510 |
+
- I5 tinh thần (geometry-aware separation) → không còn explicit mechanism, relies entirely on GPM's approximate orthogonality
|
| 511 |
+
|
| 512 |
+
**Recommendation**:
|
| 513 |
+
- Xem ESA là **open problem**, không phải solved contribution
|
| 514 |
+
- Grassmann distance monitoring (without penalty loss) có thể dùng làm **diagnostic tool** cho paper — track separation quality across tasks
|
| 515 |
+
|
| 516 |
+
---
|
| 517 |
+
|
| 518 |
+
# VIII. KHUYẾN NGHỊ CUỐI
|
| 519 |
+
|
| 520 |
+
## Nếu mục tiêu là paper:
|
| 521 |
+
|
| 522 |
+
1. **Core contribution tuyên bố**: "Parameter-free routing via spectral signatures of frozen LoRA weights eliminates routing forgetting." — Đây là novelty thật, verifiable, clean.
|
| 523 |
+
|
| 524 |
+
2. **Thí nghiệm PHẢI CÓ**:
|
| 525 |
+
- SpecRoute vs GainLoRA (same benchmark, same data splits)
|
| 526 |
+
- Routing accuracy analysis (on held-out old tasks)
|
| 527 |
+
- Representation drift measurement
|
| 528 |
+
- Ablation: spectral fit vs prompt key vs random vs uniform
|
| 529 |
+
|
| 530 |
+
3. **Đừng claim ESA (C3)**: Constant threshold không đủ mạnh. Hoặc develop importance-weighted version, hoặc merge vào hyperparameter section.
|
| 531 |
+
|
| 532 |
+
4. **Position vs Feature Distributions (ICML 2025)**: Closest competitor. Their key = store mean feature vectors (data-level). Your key = store SVD of frozen weights (weight-level). Both are "characterization + similarity routing", but you are zero-replay clean, they arguably are not.
|
| 533 |
+
|
| 534 |
+
## Nếu mục tiêu là methodology cho cả lớp bài toán:
|
| 535 |
+
|
| 536 |
+
1. **Formalize "Expert Characterization Problem"**: Given frozen expert weights, what is the optimal characterization for downstream routing? SVD là 1 answer, nhưng framework nên define CRITERIA (immutable, functional, discriminative, compact) rồi show SVD satisfies all.
|
| 537 |
+
|
| 538 |
+
2. **Formalize "Routing Correctness"**: Define routing accuracy operationally, prove that projection fit + orthogonal experts → routing accuracy ≥ threshold.
|
| 539 |
+
|
| 540 |
+
3. **Formalize "Capacity Budget"**: Given $d_{in}$ dims, $T$ tasks, what is the maximum information each task can claim while maintaining minimum routing quality? This is the real open problem.
|
| 541 |
+
|
| 542 |
+
4. **CHẠY THÍ NGHIỆM trước khi viết thêm.** Bạn đã nghĩ đủ nhiều. Code đã có. Kết quả thực nghiệm sẽ cho biết framework có value không — nếu không win trên numbers, lý thuyết đẹp bao nhiêu cũng không đủ.
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/agnews/dev.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/agnews/labels.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/agnews/test.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/agnews/train.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/amazon/dev.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/amazon/labels.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/amazon/test.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/amazon/train.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/boolq/dev.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/boolq/labels.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/boolq/test.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/boolq/train.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/cb/dev.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/cb/labels.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/cb/test.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/cb/train.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/copa/dev.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/copa/labels.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/copa/test.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/copa/train.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/dbpedia/dev.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/dbpedia/labels.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/dbpedia/test.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/dbpedia/train.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/imdb/dev.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/imdb/labels.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/imdb/test.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/imdb/train.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/mnli/dev.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/mnli/labels.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/mnli/test.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/mnli/train.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/multirc/dev.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/multirc/labels.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/multirc/test.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/multirc/train.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/qqp/dev.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/qqp/labels.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/qqp/test.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/qqp/train.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/rte/dev.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/rte/labels.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/rte/test.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/rte/train.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/sst2/dev.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/sst2/labels.json
RENAMED
|
File without changes
|
{gainlora_baseline_origin → improve_gainlora}/CL_Benchmark/Long_Sequence/sst2/test.json
RENAMED
|
File without changes
|