DOMINO: Fine-tune LLM cho domain cụ thể mà không cần viết prompt
Framework mới giúp synthesize training data chất lượng cao chỉ từ vài ví dụ mẫu, không cần mô tả domain bằng ngôn ngữ tự nhiên.
Nguyễn Nhật Long
@nguyennhatlong1303
Ai đã từng thử fine-tune một LLM cho một domain cụ thể ví dụ như code review nội bộ, xử lý văn bản pháp lý, hay phân tích log hệ thống đều biết cái đau đầu nhất không phải là thiếu compute, mà là thiếu data chất lượng.
Và khi không có đủ data thật, người ta thường nghĩ ngay đến data synthesis dùng LLM mạnh hơn để generate ra training data. Nhưng cái bẫy ở đây là: để generate data đúng domain, bạn phải mô tả cái domain đó bằng ngôn ngữ tự nhiên, rồi engineer prompt cẩn thận. Nghe có vẻ ổn, nhưng thực tế thì nhiều domain cực kỳ khó articulate. Bạn thử mô tả "phong cách code của team mình" bằng một đoạn text xem, khó lắm.
Đó là vấn đề mà paper DOMINO (Domain-Specific Data Synthesis for LLMs via Minimal Sufficient Representation Learning) đang giải quyết.
Paradigm cũ đang bị break ở đây
Các approach synthesis data hiện tại đều theo hướng deductive: bạn viết mô tả domain → LLM generate data dựa trên mô tả đó. Pipeline này hoạt động tốt khi domain rõ ràng, ví dụ như "generate câu hỏi toán học lớp 10" hay "viết email marketing tiếng Anh formal". Nhưng nó fail khá nặng khi:
- Domain khó articulate ("code theo style của codebase này")
- Domain có nhiều implicit rule mà chính expert cũng không nói ra được
- Bạn muốn capture những pattern subtle mà prompt engineering không với tới
Nhóm tác giả gọi cái mình muốn làm là inductive paradigm: thay vì mô tả domain, bạn chỉ cần đưa vào một tập reference examples và hệ thống tự học lấy domain là gì từ đó.
Mình thấy cái shift này thực ra rất hợp lý. Trong thực tế, khi mình muốn một junior hiểu "code style của team", mình không ngồi viết doc dài 10 trang mình chỉ cho họ đọc 20-30 file code cũ là họ hiểu. Con người học theo inductive paradigm rất tự nhiên, vậy tại sao không làm thế với LLM?
DOMINO hoạt động như thế nào
Core idea của DOMINO gồm hai phần chính:
1. Minimal Sufficient Representation Learning
Thay vì học toàn bộ thông tin từ reference examples (bao gồm cả noise, quirk cụ thể của từng sample), DOMINO cố gắng extract ra một minimal sufficient representation tức là phần thông tin tối thiểu nhưng đủ để capture domain-level pattern.
Kỹ thuật chính ở đây là kết hợp prompt tuning với một contrastive disentanglement objective. Ý tưởng là:
- Prompt tuning để học soft representation của domain
- Contrastive loss để tách domain-level signal ra khỏi sample-specific noise
Ví dụ nếu bạn cho 50 đoạn code Python làm reference, DOMINO sẽ học được "domain này dùng Python, có convention này, pattern kia" chứ không bị overfit vào chi tiết cụ thể của từng file như tên biến hay comment cụ thể.
2. Guided Synthetic Data Generation
Sau khi đã có domain representation đó, nó được dùng để guide quá trình generate synthetic data. Output là training data mới, aligned với domain của bạn, nhưng đa dạng hơn reference examples gốc.
Về mặt lý thuyết, paper chứng minh được rằng DOMINO expand support của synthetic data distribution tức là data generate ra không chỉ copy lại reference mà thực sự cover được nhiều case hơn. Đây là điểm quan trọng vì nếu synthetic data chỉ là paraphrase của reference thì fine-tune xong cũng không generalize được.
Kết quả thực tế trên coding benchmark
Nhóm tác giả test chủ yếu trên coding benchmarks và đây là domain khá lý tưởng để validate approach này vì:
- Domain rules của coding rất implicit và khó mô tả
- Có metric rõ ràng để đánh giá (Pass@1)
- Đây là use case thực tế mà nhiều team đang cần
Kết quả: fine-tune trên data synthesized bởi DOMINO cải thiện Pass@1 accuracy lên đến 4.63% so với strong instruction-tuned baselines.
4.63% nghe có vẻ nhỏ nhưng trong context coding benchmark thì đây là con số đáng kể, đặc biệt khi baseline đã là model được instruction-tune cẩn thận.
So sánh với các approach hiện tại
Cái mình thấy DOMINO có lợi thế rõ nhất so với few-shot prompting thông thường là phần disentanglement nó chủ động tách noise ra thay vì để model tự xử lý. Khi bạn chỉ throw reference examples vào prompt và bảo LLM "generate tương tự", model rất dễ bị anchor vào những detail bề mặt không quan trọng.
| Approach | Cần mô tả domain? | Cần prompt engineering? | Xử lý được implicit domain? | Risk overfit |
|---|---|---|---|---|
| Manual data collection | Không | Không | Có | Thấp |
| Deductive synthesis (prompt-based) | Có | Nhiều | Khó | Trung bình |
| Few-shot prompting | Một phần | Có | Giới hạn | Trung bình |
| **DOMINO** | **Không** | **Không** | **Có** | **Thấp (có disentanglement)** |
Ứng dụng thực tế mình nghĩ đến ngay mấy case này
Nếu DOMINO hoạt động đúng như paper mô tả, mình thấy nó cực kỳ hữu ích cho:
Fine-tune model cho codebase nội bộ: Bạn có 1000 file code của team, muốn train model hiểu convention của team để làm code completion hoặc review. Trước đây bạn phải ngồi viết spec dài dòng, giờ chỉ cần feed reference examples vào.
Domain adaptation cho văn bản pháp lý/y tế: Những domain mà expert biết cách làm nhưng không thể articulate hết rules. Luật sư giỏi không nhất thiết giải thích được tại sao họ draft contract theo cách đó nhưng bạn có thể cho DOMINO học từ những contract họ đã viết.
Localization cho product-specific language: Mỗi công ty có cách nói chuyện với user khác nhau tone, vocabulary, cách handle edge case. Rất khó describe, nhưng có thể learn từ ví dụ.
Theo kinh nghiệm của mình, cái bottleneck lớn nhất khi làm domain-specific fine-tuning không phải là thiếu model hay thiếu compute mà là thiếu người có thể articulate domain đủ tốt để viết prompt. Product manager biết domain nhưng không biết prompt engineering. ML engineer biết prompt engineering nhưng không hiểu domain. DOMINO về cơ bản là bypass cái gap đó.
Một vài điểm cần lưu ý
Anh em lưu ý là paper này vẫn còn khá mới (published tháng 5/2026) và chủ yếu được validate trên coding tasks. Mình chưa thấy có ablation study chi tiết về việc cần bao nhiêu reference examples để DOMINO hoạt động tốt đây là câu hỏi thực tế quan trọng nhất nếu bạn muốn apply vào production.
Ngoài ra, phần prompt tuning trong pipeline nghĩa là bạn vẫn cần fine-tune một phần của model (soft prompts), không hoàn toàn training-free. Tùy vào infrastructure của team, đây có thể là constraint.
Mình cũng tự hỏi về khả năng scale khi reference examples của bạn rất lớn và diverse (ví dụ toàn bộ codebase của một công ty lớn), liệu contrastive disentanglement có còn hiệu quả không, hay lúc đó "domain" trở nên quá broad để capture?
Dù sao thì đây là một hướng research thực sự thú vị và address đúng pain point mà nhiều team đang gặp. Code và model chưa thấy release public, nhưng paper đã có trên arXiv nếu bạn muốn đọc chi tiết phần math của contrastive objective.
Nguyễn Nhật Long
@nguyennhatlong1303Nguyễn Nhật Long is a Senior Frontend Engineer and Frontend Team Leader with 7 years of experience building real-time fintech platforms. Specializing in React, Next.js, TypeScript, and React Native, shipping 10+ products across Web, Mobile, Telegram Mini-Apps, and Web3.
Thấy hay? Chia sẻ cho bạn bè!