# DSPy: biến bộ eval của khách hàng thành cỗ máy tự viết lại prompt

> Nếu bạn vẫn sửa từng chữ trong prompt mỗi lần khách đổi model, có một cách làm khác: định nghĩa thế nào là đúng, rồi để thuật toán đi tìm câu chữ.

Bản gốc: https://fdetimes.net/vi/cong-cu/dspy-va-toi-uu-prompt-tu-dong/

"Let's think step by step", câu prompt chain-of-thought do con người viết, từng bị một thuật toán dùng mô hình ngôn ngữ vượt qua. Phương pháp Automatic Prompt Engineer (APE) tìm ra một biến thể dài hơn, yêu cầu mô hình giải từng bước "to be sure we have the right answer".

Theo Prompt Engineering Guide của DAIR.AI, câu này cải thiện kết quả trên hai bộ bài toán MultiArith và GSM8K.

Chi tiết đáng chú ý không nằm ở câu chữ mà ở cách nó ra đời. Không ai ngồi nghĩ ra câu đó. Một thuật toán đã tìm kiếm rồi chọn ra nó, giống hệt cách người ta dò hyperparameter.

Một FDE gặp đúng bài toán này gần như mỗi tuần. Ở chỗ khách hàng, bạn có thể mất cả tuần để chỉnh prompt cho một pipeline phân loại hay trích xuất. Rồi khách đổi model và mọi thứ phải làm lại. DSPy là công cụ biến việc chỉnh tay đó thành một bài toán tối ưu, với bộ eval của khách làm hàm mục tiêu.

## Prompt là tham số, không phải tác phẩm

Ý tưởng tìm prompt bằng thuật toán được trình bày rõ trong bài báo "Large Language Models Are Human-Level Prompt Engineers" của Zhou và cộng sự, đăng lên arXiv ngày 3/11/2022. Cơ chế của APE khá đơn giản: một LLM đề xuất cả loạt instruction ứng viên, rồi hệ thống tìm trong loạt đó bản cho điểm cao nhất.

Trên 24 tác vụ NLP, instruction do APE sinh ra ngang hoặc tốt hơn instruction của người chú thích ở 19 tác vụ.

DSPy áp dụng cùng logic ở cấp pipeline. Bài báo của Khattab, Zaharia, Potts và cộng sự, đăng ngày 5/10/2023, mô tả một trình biên dịch có thể tối ưu bất kỳ pipeline DSPy nào để đạt điểm cao nhất theo một metric cho trước.

Các module trong DSPy được tham số hóa, nghĩa là chúng học được, chẳng hạn học prompt hay học bộ ví dụ few-shot.

README chính thức của Stanford NLP gọi DSPy là framework để lập trình mô hình ngôn ngữ thay vì viết prompt cho chúng. Tên đầy đủ là Declarative Self-improving Python, và theo README, framework này có thuật toán tối ưu cả prompt lẫn trọng số mô hình.

**Điểm mấu chốt:** Với DSPy, bạn không giao cho khách một prompt. Bạn giao một metric, một bộ eval và một quy trình tự tìm lại prompt mỗi khi có gì thay đổi.

## Khi nào nên dùng đến DSPy?

DSPy phù hợp nhất khi có ba điều kiện: bài toán có đáp án đo được, khách có hoặc sẵn sàng gán nhãn dữ liệu, và pipeline sẽ còn thay đổi về model hay yêu cầu. Nếu thiếu điều kiện đầu, ví dụ khách chỉ muốn câu trả lời "nghe hay hơn" mà không ai định nghĩa được thế nào là hay, thì optimizer không có gì để bám vào.

Hãy thử hình dung một ngân hàng muốn tự động phân loại email khiếu nại vào 6 nhóm để chuyển đúng bộ phận. Đội vận hành gán nhãn 300 email. Bạn tách 200 email làm dữ liệu tối ưu và giữ riêng 100 email làm holdout, không đưa cho optimizer xem. Metric chỉ là một hàm: nhãn dự đoán trùng nhãn người gán thì được 1 điểm, sai thì 0.

Phác thảo dưới đây cho thấy ba mảnh ghép đó trong code: một module khai báo đầu vào, đầu ra; một hàm metric; và một lời gọi biên dịch. Đây là sketch minh họa, tên lớp optimizer và tham số cụ thể bạn nên đối chiếu với tài liệu của phiên bản DSPy đang dùng.

```python
import dspy

# Module: khai báo việc cần làm, không viết prompt
phan_loai = dspy.Predict("email -> nhom_khieu_nai")

# Metric: đúng nhãn người gán thì 1, sai thì 0
def dung_nhan(vi_du, du_doan, trace=None):
return du_doan.nhom_khieu_nai == vi_du.nhom_khieu_nai

# Biên dịch: optimizer thử instruction và ví dụ few-shot từ 200 email
optimizer = dspy.BootstrapFewShot(metric=dung_nhan)
ban_toi_uu = optimizer.compile(phan_loai, trainset=email_toi_uu)

# Chỉ báo cáo điểm trên 100 email holdout
```

Giả sử prompt viết tay đạt 78/100 trên holdout. Bạn chạy trình biên dịch, để nó thử các phương án rồi chấm từng phương án bằng metric. Nếu phương án tốt nhất đạt 86/100 trên holdout, khoảng cách là 8 email trên mỗi 100.

Với lượng 5.000 email mỗi tháng, ngân hàng bớt được khoảng 400 email chuyển nhầm mỗi tháng, một con số mà giám đốc vận hành hiểu ngay.

| Việc | Ai làm |
|---|---|
| Định nghĩa thế nào là "đúng" | FDE cùng khách hàng |
| Gán nhãn và tách holdout | Khách hàng, FDE kiểm tra |
| Sinh và thử các phương án prompt | Optimizer |
| Đọc các lỗi còn lại trên holdout | FDE |

Hàng cuối cùng mới là phần đáng tiền. 14 email còn sai thường chỉ ra một nhóm phân loại mơ hồ hoặc nhãn gán không nhất quán, và đó là chủ đề cho buổi họp tiếp theo với khách.

## Optimizer chỉ trung thành với metric

DSPy tối ưu đúng những gì bạn đo, không hơn. Nếu metric chỉ kiểm tra định dạng đầu ra mà không kiểm tra nội dung, bạn sẽ nhận về một prompt rất giỏi trả về định dạng đúng. Nếu bộ eval quá nhỏ hoặc lệch phân bố, prompt sẽ khớp quá mức với vài chục ví dụ đó.

Vì vậy điểm trên holdout mới là con số nên báo cáo, không phải điểm trên dữ liệu tối ưu.

Chi phí cũng cần tính. Mỗi lần thử một phương án là thêm một loạt lời gọi model, nên hãy bắt đầu với bộ dữ liệu nhỏ và model rẻ trước khi chạy lớn.

Dù vậy, so với các con đường khác, tối ưu prompt vẫn là lựa chọn tiết kiệm. Nhóm tác giả của GEPA, một phương pháp tiến hóa prompt có phản chiếu do Agrawal, Khattab và cộng sự đăng năm 2025, chỉ ra rằng các phương pháp reinforcement learning như GRPO thường cần hàng nghìn rollout để học tác vụ mới.

Trên sáu tác vụ, GEPA vượt GRPO trung bình 6%, có tác vụ tới 20%, trong khi dùng ít rollout hơn tới 35 lần. Bài học cho FDE là hãy vắt kiệt tối ưu prompt trước khi đề xuất fine-tune với khách.

## Học gì trước để dùng được ngay?

Đừng bắt đầu từ API. Hãy bắt đầu bằng kỹ năng viết metric và xây bộ eval, vì đó là thứ DSPy không làm thay bạn. Sau đó đọc abstract của APE để nắm vòng lặp đề xuất và chấm điểm, rồi đọc bài báo DSPy để hiểu module, metric và trình biên dịch khớp với nhau thế nào.

Khi đọc mô tả công việc FDE hay AI engineer, hãy để ý các cụm như "eval", "prompt optimization" hay tên DSPy. Trong CV, đừng viết "thành thạo prompt engineering". Hãy viết một câu có số liệu: xây bộ eval bao nhiêu ví dụ, dùng tối ưu tự động, độ chính xác trên holdout tăng từ bao nhiêu lên bao nhiêu.

Prompt viết tay sẽ cũ đi ngay khi khách đổi model. Bộ eval được định nghĩa tốt thì vẫn dùng được, và lần tới chỉ cần chạy lại trình biên dịch.

**Thử ngay tuần này:**

- Chọn một prompt bạn đang chạy production, gom 50-100 ví dụ có nhãn và viết một hàm metric trả về đúng/sai cho từng ví dụ.
- Chia bộ dữ liệu thành phần tối ưu và phần holdout, ghi lại điểm của prompt viết tay trên holdout làm mốc so sánh.
- Đọc abstract của bài báo DSPy (arXiv 2310.03714) và APE (arXiv 2211.01910), rồi tóm tắt cơ chế của mỗi bên trong ba câu.

## Nguồn

- [Automatic Prompt Engineer (APE) | Prompt Engineering Guide](https://www.promptingguide.ai/techniques/ape)

- [Large Language Models Are Human-Level Prompt Engineers](https://arxiv.org/abs/2211.01910)

- [DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines](https://arxiv.org/abs/2310.03714)

- [GitHub - stanfordnlp/dspy: DSPy: The framework for programming—not prompting—language models](https://github.com/stanfordnlp/dspy)

- [GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning](https://arxiv.org/abs/2507.19457)