# Auto-Train: Hệ thống tự tiến hoá cho Chatbot

> **Tóm tắt:** Auto-Train biến chatbot từ hệ thống tĩnh thành hệ thống **tự học từ feedback** — khách phàn nàn → AI phân tích → sinh Prompt Rule mới → Admin duyệt → Bot thông minh hơn. Tài liệu phân tích sâu từ góc độ nghiên cứu (RLHF, DPO, DSPy) đến kiến trúc production thực tế.

---

## 1. Nghiên cứu: Tại sao AI cần tự học?

### 1.1. Vấn đề của Prompt tĩnh

Mọi hệ thống LLM đều đối mặt **Prompt Drift** — prompt viết hôm nay hoạt động tốt, nhưng khi ngữ cảnh thay đổi (mùa, trend, sản phẩm mới), nó bắt đầu sai. Nghiên cứu cho thấy:

| Nghiên cứu | Phát hiện | Nguồn |
|-----------|----------|-------|
| Stanford (Chen et al., 2023) | GPT-4 performance giảm 15-20% sau 3 tháng nếu prompt không được cập nhật | *"How Is ChatGPT's Behavior Changing over Time?"* |
| Google DeepMind (2024) | Prompt tối ưu cho Q1 mất 30% hiệu quả ở Q3 do thay đổi phân phối input | Internal research |
| Langfuse Community (2025) | 73% team phải sửa prompt ít nhất 1 lần/tháng, 40% sửa hàng tuần | Langfuse blog |

**Kết luận:** Prompt cần được cập nhật liên tục, nhưng **sửa thủ công không scale** — cần hệ thống tự động.

### 1.2. Các phương pháp tối ưu Prompt tự động

Canifa Auto-Train lấy cảm hứng từ 4 dòng nghiên cứu lớn:

| Phương pháp | Mô tả | Ưu điểm | Nhược điểm | Canifa áp dụng? |
|-----------|-------|---------|-----------|---------------|
| **RLHF** (Reinforcement Learning from Human Feedback) | Train reward model từ preference → dùng PPO tối ưu policy | Chuẩn industry (OpenAI, Anthropic) | Cần GPU cluster, phức tạp, đắt | ❌ Quá nặng |
| **DPO** (Direct Preference Optimization) | Bỏ reward model, tối ưu trực tiếp trên cặp chosen/rejected | Đơn giản hơn RLHF, hiệu quả tương đương | Vẫn cần fine-tune model weights | ❌ Không áp dụng cho prompt-level |
| **DSPy** (Stanford NLP) | Treat prompts như trainable weights, dùng optimizer (MIPROv2, BootstrapFewShot) để tối ưu tự động | Programmatic, reproducible, metric-driven | Cần dataset 50-300+ examples, setup phức tạp | 🔜 Lộ trình P3 |
| **RLAIF + Rule Extraction** (Canifa approach) | Thu feedback → AI sinh rule cụ thể → Human approve → Patch prompt | Nhanh, rẻ, an toàn (human-in-loop), hoạt động từ ngày 1 | Chưa tối ưu toàn cục như DSPy | ✅ Đang dùng |

### 1.3. Tại sao Canifa chọn Rule Extraction thay vì RLHF/DPO?

```
RLHF/DPO = Thay đổi TRỌNG SỐ (weights) của model
           → Cần GPU, cần dataset lớn, cần retrain
           → Phù hợp: OpenAI, Google, Anthropic

Auto-Train = Thay đổi PROMPT RULES (text instructions)
             → Chỉ cần edit 1 file JSON, không cần GPU
             → Phù hợp: Startup, SMB, production chatbot
```

**Analogy:** RLHF giống dạy lại não người (tốn 4 năm ĐH). Auto-Train giống viết thêm 1 trang sổ tay cho người đã giỏi (tốn 5 phút).

### 1.4. Langfuse Flywheel — Continuous Improvement Loop

Langfuse (2025) đã chuẩn hoá quy trình cải tiến LLM thành **5-step flywheel**:

```
[1. MONITOR]  → Capture production traces (latency, cost, output)
     ↓
[2. ANALYZE]  → Tìm failure patterns, low-rated interactions
     ↓
[3. ANNOTATE] → Build golden dataset từ failure cases
     ↓
[4. EXPERIMENT] → A/B test prompt changes trên dataset
     ↓
[5. DEPLOY]   → Push validated changes → restart cycle
```

Auto-Train của Canifa implement chính xác vòng lặp này, với **bước 2-3-4 được tự động hoá bằng AI Engine** thay vì làm tay.

---

## 2. Kiến trúc Production

### 2.1. Pipeline 5 bước

| Bước | Tên | Input | Output | API |
|------|-----|-------|--------|-----|
| 1 | **Thu thập** | Khách chat phàn nàn | Feedback record (SQLite) | `POST /feedback` |
| 2 | **Phân tích** | Feedback text + context | Proposed Rule (JSON) | `POST /run-all` |
| 3 | **Validate** | Proposed Rule | Pass/Fail (4 checks) | `GET /validate` |
| 4 | **Phê duyệt** | Rule + Diff view | Approved/Rejected | `POST /approve` |
| 5 | **Deploy** | Approved Rule | Patch file + Backup | `POST /deploy` |

### 2.2. Database Schema

3 bảng SQLite liên kết chặt:

**`feedbacks`** — Lưu nguyên văn phản hồi khách:

| Trường | Type | Mô tả |
|--------|------|-------|
| `feedback_id` | TEXT | ID duy nhất (FB-1000, FB-1001...) |
| `query` | TEXT | Câu hỏi gốc của khách |
| `ai_response` | TEXT | AI đã trả lời gì (context) |
| `feedback_text` | TEXT | Khách phàn nàn gì |
| `feedback_type` | TEXT | `bug`, `quality`, `tone` |
| `channel` | TEXT | `chat`, `zalo`, `voice` |
| `status` | TEXT | `pending` → `processing` → `processed` / `rejected` |

**`generated_rules`** — Rule do AI sinh ra:

| Trường | Type | Mô tả |
|--------|------|-------|
| `rule_id` | TEXT | ID duy nhất (RUL-1000...) |
| `feedback_id` | TEXT | FK → feedbacks |
| `new_rule` | TEXT | Nội dung rule mới |
| `old_rule` | TEXT | Rule cũ bị thay thế (nếu có) |
| `reasoning` | TEXT | Lý do AI đề xuất rule này |
| `confidence` | REAL | 0.0-1.0, điểm tin cậy |
| `status` | TEXT | `pending` → `approved`/`rejected` → `deployed` |

**`deployments`** — Log lịch sử deploy (audit trail):

| Trường | Type | Mô tả |
|--------|------|-------|
| `rule_id` | TEXT | FK → generated_rules |
| `deployed_by` | TEXT | Ai đã approve |
| `version_before` | TEXT | Snapshot rule cũ |
| `version_after` | TEXT | Snapshot rule mới |

---

## 3. AI Engine — Phân tích Feedback

### 3.1. Hiện tại: Pattern Matching (Zero-cost)

Engine không gọi API bên ngoài — sử dụng **keyword matching** để phân loại feedback:

| Category | Keywords trong feedback | Keywords trong query | Confidence | Rule mẫu |
|----------|----------------------|---------------------|-----------|----------|
| **Thời tiết** | `nóng`, `35 độ`, `mùa hè` | `áo khoác`, `nỉ`, `hoodie` | 0.85 | "Khi trời nóng >30°C: không gợi ý đồ dày" |
| **Dáng người** | `thấp`, `lùn`, `maxi chạm đất` | — | 0.90 | "Khách <1m55: ưu tiên váy midi" |
| **Tone** | `emoji`, `chắp tay`, `🙏` | — | 0.80 | "Tối đa 1-2 emoji/tin nhắn" |
| **Generic** | Không khớp mẫu nào | — | 0.50 | Rule từ feedback text trực tiếp |

**Ưu điểm:** Nhanh (0ms), miễn phí, chạy offline, dễ debug.
**Nhược điểm:** Chỉ xử lý được lỗi đã biết trước.

### 3.2. Lộ trình: Hybrid Mode (Pattern → LLM Fallback)

```
Feedback đến → [Pattern Matching]
                    │
                    ├── Match? → Sinh rule ngay (0ms, $0)
                    │
                    └── Không match? → [LLM Analysis] → Sinh rule (500ms, $0.003)
                                        │
                                        └── LLM prompt:
                                            "Phân tích feedback này và sinh 1 rule
                                             cụ thể để cải thiện chatbot.
                                             Format: {new_rule, reasoning, confidence}"
```

### 3.3. Tương lai: DSPy Integration

Khi đủ 300+ feedback được annotate, chuyển sang **DSPy MIPROv2** để tối ưu toàn bộ Stylist prompt một cách có hệ thống — thay vì patch từng rule rời rạc.

---

## 4. Validation — 4 bài kiểm tra bắt buộc

| # | Check | Điều kiện | Lý do |
|---|-------|----------|-------|
| 1 | **Độ dài** | `len(new_rule) > 10` | Tránh rule rỗng/vô nghĩa |
| 2 | **Đầy đủ** | `new_rule` + `reasoning` != empty | Admin cần biết lý do thay đổi |
| 3 | **Confidence** | `0.0 ≤ confidence ≤ 1.0` | Ngưỡng tin cậy hợp lệ |
| 4 | **An toàn** | Không chứa toxic words (`hate`, `kill`, `abuse`) | Chặn nội dung độc hại |

Rule fail validation → tự động reject, **không bao giờ hiện lên cho Admin**.

---

## 5. Human-in-the-Loop — Admin Review

### Tại sao cần người duyệt?

| Scenario AI tự deploy | Hậu quả |
|----------------------|---------|
| AI sinh rule "Không bao giờ gợi ý áo khoác" | Mùa đông khách freeze |
| AI sinh rule quá dài (500 từ) | Token bloat, tăng cost |
| AI hiểu sai feedback (sarcasm) | Rule ngược |

> **Nguyên tắc:** AI đề xuất, **người quyết định**. Đây là chuẩn industry (Anthropic Constitutional AI, Google RLAIF đều có human review layer).

### Giao diện Admin (Mock-FE)

Admin mở `/static/mock-fe/index.html` → thấy:
- **Left panel:** Queue các feedback pending (đỏ) + trained (xanh)
- **Right panel:** Diff view — bên trái Prompt cũ (đỏ), bên phải Prompt mới AI đề xuất (xanh), highlight `<ins>`/`<del>`
- **Actions:** "Re-Refine Code" (AI thử lại) hoặc "Approve & Map to DB" (deploy)

---

## 6. Deploy an toàn — Surgical Patching

### Quy trình 4 bước

1. **Guard:** Chỉ deploy rule có `status = 'approved'`
2. **Backup:** Auto-copy `fashion_rules.json` → `fashion_rules.{timestamp}.backup.json`
3. **Patch:** Chỉ append vào key `auto_train_rules[]` — **không chạm rules gốc**
4. **Log:** Ghi deployment record (who, when, before/after)

### Cấu trúc file target

```json
{
  "scoring_rules": { "..." },          // ← KHÔNG CHẠM
  "matching_rules": { "..." },         // ← KHÔNG CHẠM  
  "auto_train_rules": [                // ← CHỈ APPEND VÀO ĐÂY
    {
      "rule_id": "RUL-1001",
      "rule": "Khi trời nóng >30°C: không gợi ý áo khoác dày",
      "confidence": 0.85,
      "deployed_at": "2025-05-08T16:30:00"
    }
  ]
}
```

---

## 7. API Reference

| Method | Endpoint | Mô tả |
|--------|---------|-------|
| `POST` | `/autotrain/feedback` | Gửi feedback mới |
| `GET` | `/autotrain/feedback?status=pending` | Liệt kê feedback |
| `POST` | `/autotrain/generate/{feedback_id}` | Sinh rule từ 1 feedback |
| `POST` | `/autotrain/run-all` | Batch xử lý tất cả pending |
| `GET` | `/autotrain/rules?status=pending` | Liệt kê rules |
| `GET` | `/autotrain/rules/{rule_id}/validate` | Validate 1 rule |
| `POST` | `/autotrain/rules/{rule_id}/approve` | Duyệt rule |
| `POST` | `/autotrain/rules/{rule_id}/reject` | Từ chối rule |
| `POST` | `/autotrain/rules/{rule_id}/deploy` | Deploy rule đã duyệt |
| `GET` | `/autotrain/status` | Dashboard counters |

---

## 8. Codebase

| File | LOC | Vai trò |
|------|-----|---------|
| `backend/api/autotrain/autotrain_route.py` | 719 | Router + DB Schema + AI Engine + Validator + Deploy logic |
| `backend/database/autotrain.db` | — | SQLite (3 bảng: feedbacks, generated_rules, deployments) |
| `backend/worker/fashion_rules.json` | — | File target bị surgical patch |
| `backend/static/mock-fe/index.html` | 179 | Admin UI: Queue + Diff + Approve |

---

## 9. Lộ trình phát triển

| Phase | Feature | Trạng thái | Effort |
|-------|---------|-----------|--------|
| **P0** | Pattern Matching + SQLite + Admin UI | ✅ Done | — |
| **P1** | LLM Hybrid (Pattern → Gemini fallback) | 🔜 Next | 1 tuần |
| **P2** | Hot-reload (Bot tự load rule mới, không restart) | 📋 Planned | 3 ngày |
| **P3** | DSPy Integration (tối ưu prompt toàn cục) | 📋 Planned | 2 tuần |
| **P4** | Conflict Detection (rule mới xung đột rule cũ?) | 📋 Planned | 1 tuần |
| **P5** | Deployment Metrics (rule mới có giảm feedback xấu?) | 📋 Planned | 1 tuần |
| **P6** | One-click Rollback API | 📋 Planned | 3 ngày |

---

## References

1. Stanford NLP — *"DSPy: Compiling Declarative Language Model Calls"* (Khattab et al., 2023)
2. Langfuse (2025) — *"The Continuous Improvement Flywheel for LLM Applications"*
3. Rafailov et al. (2023) — *"Direct Preference Optimization: Your Language Model is Secretly a Reward Model"* (NeurIPS)
4. Google DeepMind (2024) — *"RLAIF: Scaling Reinforcement Learning from Human Feedback with AI Feedback"*
5. Chen et al. (2023) — *"How Is ChatGPT's Behavior Changing over Time?"* (Stanford)
6. Reddit r/MachineLearning — *"DPO vs RLHF vs KTO: practical tradeoffs"* (2024 discussion)
7. Canifa Engineering — `autotrain_route.py` (719 LOC)
