Chọn model & cách tiếp cận

Hai quyết định:
RAG-hay-không & chọn model nào.

Đây là hai lựa chọn junior sai nhiều nhất. Quyết cả hai bằng sơ đồ và eval — không bằng cảm tính. Rẻ nhất trước, mỗi lần nâng cấp phải biện minh bằng một con số.

Quyết định 1

RAG hay không?

RAG = trước khi trả lời, lấy vài đoạn liên quan nhất trong kiến thức của khách và đưa vào prompt. Đi cây này từ trên xuống và dừng ở nhánh khớp đầu tiên.

Q1 · Có cần sự kiện mà model gốc không nắm chắc không (chính sách, dữ liệu riêng / nội bộ / mới)?
└ KHÔNG → CHỈ PROMPT. Viết một system prompt tốt. Rẻ nhất. Luôn thử trước.
└ CÓ ↓
Q2 · Kiến thức đó có nhỏ VÀ ổn định không (vừa prompt, ít thay đổi)?
├ CÓ → LONG-CONTEXT. Dán tài liệu vào mỗi lần gọi + bật prompt caching.
└ KHÔNG (lớn / nhiều tài liệu / hay đổi) → RAG. Embed một lần, truy hồi top-k mỗi câu hỏi.
Q3 · Thực ra là dạy một PHONG CÁCH / ĐỊNH DẠNG / HÀNH VI, không phải sự kiện? → FINE-TUNE. Phương án cuối; tốn nhất để dựng & bảo trì.

Thiên hướng mặc định

prompt < long-context < RAG < fine-tune. Phần lớn dự án doanh nghiệp dừng ở RAG. Fine-tuning hiếm — nó dạy hành vi, không phải sự kiện, và RAG + prompt tốt thường thắng với công sức ít hơn nhiều.

Vì sao trợ lý đề xuất của ta = lai (hybrid)

Bảng giá & phương pháp nhỏ + ổn định → ghim vào prompt (long-context); dự án cũ tăng dần và độ tương đồng quan trọng → RAG trên chúng; đây là sự kiện chứ không phải phong cách viết (không fine-tune). → ghim + RAG.

RAG giá rẻ hợp với một agency chi phí thấp

  • Embeddings: một model sentence-transformers chạy local (vd all-MiniLM-L6-v2). Chạy CPU, $0 mỗi lần gọi, không khóa nhà cung cấp. Đủ tốt cho KB nhỏ/vừa.
  • Vector store: với vài nghìn đoạn, tìm cosine bằng numpy trong bộ nhớ là quá đủ. Chỉ thêm vector DB thật (pgvector, Qdrant) khi khối lượng bắt buộc.
  • Sinh nội dung: Claude Haiku, bám chặt vào các đoạn đã truy hồi.
Quyết định 2

Chọn model Claude nào?

Mặc định dùng họ Claude và chọn theo bậc. Kiểm tra giá hiện hành trong tài liệu Anthropic trước khi báo giá cho khách — ID và bậc bên dưới, giá có thể đổi.

BậcModel IDKhi nào dùng
rẻ / nhanhclaude-haiku-4-5-20251001Mặc định của ta. Khối lượng lớn, phạm vi rõ: phân loại, trích xuất, trả lời RAG bám nguồn, soạn nháp.
cân bằngclaude-sonnet-4-6Suy luận khó hơn, nhiều bước, đầu vào mơ hồ, vòng lặp agent. Cũng là giám khảo eval tốt.
mạnh nhấtclaude-opus-4-8Suy luận khó nhất / agent / ca biên — hoặc làm giám khảo eval nghiêm khắc cho model rẻ hơn đang dùng.

Phương pháp

  1. Bắt đầu ở Haiku. Dựng lát cắt mỏng trên đó.
  2. Chạy eval. Xanh + trong ngân sách → ra mắt. Xong, và rẻ.
  3. Đỏ ở một kỹ năng cụ thể? Chỉ định tuyến riêng bước đó cho Sonnet trước khi nâng cấp tất cả. Eval lại.
  4. Vẫn đỏ? Leo lên Sonnet, rồi Opus, eval lại từng bước. Dừng ngay khi xanh.
  5. Chấm điểm bằng model mạnh hơn model bạn triển khai.

Cần giảm chi phí (làm trước khi nâng cấp)

  • Prompt caching cho các phần ổn định (system prompt, tài liệu dán vào).
  • Truy hồi ít / nhỏ đoạn hơn — ít ngữ cảnh, ít token đầu vào.
  • Giới hạn token đầu ra.
  • Gộp lô (batch) việc không gấp.

Vì sao trợ lý đề xuất của ta leo lên Sonnet

Ta bắt đầu trên Haiku và chạy eval — nó cấu trúc đề xuất kém và bám sai con số ước lượng. Soạn một đề xuất mạch lạc, bám nguồn là suy luận thực sự, nên ta leo một bậc lên claude-sonnet-4-6 và chấm bằng claude-opus-4-8. Eval quyết định, không phải cảm tính.