Phần 7 — Declarative Prompting với DSPy (2026)

📖 Bản tiếng Anh (English Edition)

← Chương trước: Phần 6 — Từ Prompting sang Context Engineering (2026) | Mục lục Series | Chương tiếp theo: Phần 8 — Production PromptOps Pipeline (2026) →

Answer-first: DSPy thay thế việc tinh chỉnh chuỗi prompt thủ công bằng cách biên dịch tự động các Signature khai báo thành prompt tối ưu theo metric mục tiêu. Lập trình viên chỉ cần định nghĩa kiểu dữ liệu vào ra, bộ tối ưu hóa MIPROv2 sẽ tự động sinh và chọn lọc ví dụ few-shot hiệu quả nhất. Điều kiện tiên quyết: Nắm vững lập trình Python hướng đối tượng, thư viện Pydantic v2, và các khái niệm tối ưu hóa hàm mục tiêu (metric).

Vấn đề của prompt viết tay

Answer-first: Prompt viết tay được tối ưu bằng trực giác con người, không phải bằng dữ liệu — nên dễ vỡ khi đổi model, khó mở rộng qua pipeline phức tạp, và không giải thích được tại sao một cách diễn đạt thắng. Điều kiện tiên quyết: Nắm vững lập trình Python hướng đối tượng, thư viện Pydantic v2, và các khái niệm tối ưu hóa hàm mục tiêu (metric).

Dù đã có Prompt Standard tốt, prompt viết tay vẫn có điểm yếu cốt lõi: chúng được tối ưu bằng trực giác con người, không phải bằng dữ liệu.

Bạn viết prompt, test vài case, sửa từ ngữ, và hy vọng nó tổng quát hóa được. Đây gọi là “vibes-based prompting,” và có 3 vấn đề đo được:

1. Dễ vỡ: Prompt tuned cho GPT-4 có thể chạy kém trên Claude — hướng dẫn migration của chính Anthropic tồn tại vì hiện tượng này (Chương 2 của series đã trích dẫn).
2. Khó mở rộng: Khi pipeline phức tạp (RAG → reasoning → tool → validate), tuning từng prompt trở thành cơn ác mộng — và chất lượng pipeline là hàm của tất cả prompt cùng lúc, thứ tay không tối ưu được.
3. Thiếu minh bạch: Bạn không giải thích được tại sao một cách diễn đạt lại tốt hơn.

Bài báo gốc của DSPy (Khattab et al., Stanford NLP, 10/2023) chẩn đoán giống hệt: các pipeline LM “typically implemented using hard-coded ‘prompt templates’, i.e. lengthy strings discovered via trial and error.”

DSPy là gì?

Answer-first: DSPy (Declarative Self-improving Python) xem prompt là tham số nội bộ cần tối ưu, không phải chuỗi ký tự cần viết tay — “a compiler that will optimize any DSPy pipeline to maximize a given metric.” Điều kiện tiên quyết: Nắm vững lập trình Python hướng đối tượng, thư viện Pydantic v2, và các khái niệm tối ưu hóa hàm mục tiêu (metric).

DSPy trừu tượng hóa pipeline LM thành đồ thị biến đổi văn bản: các bước gọi model được khai báo qua declarative modules, và một compiler tối ưu toàn bộ pipeline theo metric bạn chỉ định.

Bằng chứng: compiler thắng tay ở mức nào?

Answer-first: Ba họ số liệu từ hai thế hệ nghiên cứu: (1) +25% (GPT-3.5) / +65% (llama2-13b-chat) over standard few-shot; (2) vượt expert-created demonstrations 5–46% / 16–40%; (3) chương trình compile cho T5-770M cạnh tranh với expert chains trên GPT-3.5 — và MIPRO (2024) cải thiện thêm tới +13% trên baseline optimizer mạnh hơn. Điều kiện tiên quyết: Nắm vững lập trình Python hướng đối tượng, thư viện Pydantic v2, và các khái niệm tối ưu hóa hàm mục tiêu (metric).

Các con số của bài báo gốc (Stanford NLP, 10/2023) — trích với baseline rõ ràng:

1. Vượt standard few-shot: “a few lines of DSPy allow GPT-3.5 and llama2-13b-chat to self-bootstrap pipelines that outperform standard few-shot prompting (generally by over 25% and 65%, respectively)” — trong vòng phút sau khi compile.
2. Vượt cả expert demonstrations: compiled pipelines vượt “pipelines with expert-created demonstrations (by up to 5-46% and 16-40%)” — compiler chọn demonstrations tốt hơn chuyên gia, đúng ở chính trò chuyên gia giỏi nhất.
3. Compile bù quy mô model: “programs compiled to open and relatively small LMs like 770M-parameter T5 and llama2-13b-chat are competitive with approaches that rely on expert-written prompt chains for proprietary GPT-3.5” — compilation là đòn bẩy chi phí, không chỉ chất lượng.

Thế hệ thứ hai — MIPRO (EMNLP 2024, arXiv:2406.11695): tối ưu jointly instruction + demonstrations cho mọi module trong pipeline (giải bài toán credit assignment mà tay không làm nổi), thắng baseline optimizers trên 5/7 program với Llama-3-8B, cao nhất +13% accuracy.

Vì sao delta thu nhỏ (25/65% → 13%)? Baseline mạnh dần: so sánh 2023 với few-shot thủ công, 2024 với optimizer thế hệ trước — trích số nào cũng phải kèm baseline của nó.

Cách hoạt động: Signatures, Modules, và Optimizers

1. Signatures — hợp đồng khai báo

Khai báo module làm gì, không chỉ định làm thế nào:

class ReviewCode(dspy.Signature):
    """Review a code diff for bugs and security issues."""
    diff: str = dspy.InputField(desc="The code diff to review")
    findings: list[str] = dspy.OutputField(desc="List of issues found")

Signature chính là cặp Input Contract + Output Contract của Phần 2 được hình thức hóa: typed fields, mô tả ngữ nghĩa, diff được như API. Desc strings không phải documentation — chúng là bề mặt tối ưu mà compiler có thể diễn đạt lại.

2. Modules — pattern thực thi

Các building block kết hợp được: dspy.Predict (zero-shot trực tiếp), dspy.ChainOfThought (tự append bước reasoning), dspy.ReAct (đan xen thought với tool call — điểm gặp trụ cột MCP của Phần 6).

class CodeReviewer(dspy.Module):
    def __init__(self):
        self.review = dspy.ChainOfThought(ReviewCode)
    def forward(self, diff):
        return self.review(diff=diff)

3. Optimizers — compiler

Cho trước trainset + metric, optimizer tự tìm chiến lúc prompt tốt nhất:

# Thế hệ khởi động: bootstrap demonstrations từ chính các run đúng
optimizer = dspy.BootstrapFewShot(metric=bug_detection_accuracy)
optimized_reviewer = optimizer.compile(CodeReviewer(), trainset=examples)

Ba thế hệ optimizer, mỗi thế hệ mở rộng không gian tìm kiếm:

graph LR
    B["BootstrapFewShot<br/>(2023)<br/>tự sinh demonstrations<br/>từ run đúng"] --> M["MIPRO<br/>(EMNLP 2024)<br/>tìm instruction jointly<br/>+13% accuracy"] --> V["MIPROv2<br/>(production)<br/>Bayesian search<br/>instruction + exemplar"]

    style B fill:#e8f4f8,stroke:#2a7da0
    style V fill:#e8f8e8,stroke:#2a7da0

Pipeline compile production hoàn chỉnh (dịch từ bản đặc tả tiếng Anh của series):

import dspy

# 1. Signature — hợp đồng khai báo
class VulnerabilityAnalysisSignature(dspy.Signature):
    """Analyze source code snippet for security vulnerabilities and output structured fix."""
    code_snippet = dspy.InputField(desc="Raw source code snippet")
    language = dspy.InputField(desc="Programming language: Go, Python, or TypeScript")

    vulnerability_detected = dspy.OutputField(desc="Boolean True or False")
    cwe_id = dspy.OutputField(desc="CWE Identifier such as CWE-89 or 'None'")
    remediation_patch = dspy.OutputField(desc="Minimal corrected code patch")

# 2. Module pipeline
class VulnerabilityAnalyzerModule(dspy.Module):
    def __init__(self):
        super().__init__()
        self.analyze = dspy.ChainOfThought(VulnerabilityAnalysisSignature)

    def forward(self, code_snippet: str, language: str):
        return self.analyze(code_snippet=code_snippet, language=language)

# 3. Metric — chuẩn eval của Phần 4 cài thành hàm
def accuracy_and_format_metric(example, pred, trace=None):
    detection_matches = (str(example.vulnerability_detected).lower()
                        == str(pred.vulnerability_detected).lower())
    cwe_valid = pred.cwe_id is not None and len(pred.cwe_id.strip()) > 0
    patch_present = pred.remediation_patch is not None and len(pred.remediation_patch.strip()) > 0
    return detection_matches and cwe_valid and patch_present

# 4. Compile bằng MIPROv2 → artifact JSON versioned
optimizer = dspy.MIPROv2(metric=accuracy_and_format_metric)
compiled = optimizer.compile(VulnerabilityAnalyzerModule(), trainset=golden_set)
compiled.save("vulnerability_analyzer.v3.json")  # known-good tag như Part 4

Artifact compile là file JSON versioned — prompt thành build artifact: reproducible, diffable, rollback được bằng checkout. Đổi model? Recompile — artifact thích nghi (chính là portability mà bài báo đo: GPT-3.5 ↔ llama2 ↔ T5).

Khi nào dùng DSPy vs Prompt Standard truyền thống?

Answer-first: Ba lớp ba công cụ, không giao thoa: cấu trúc tổ chức → Prompt Standard; tối ưu task-level → DSPy; dữ liệu & truy xuất → RAG. Thực tế production dùng hybrid: block viết tay cho policy ổn định, module compiled cho bước LM biến động. Điều kiện tiên quyết: Nắm vững lập trình Python hướng đối tượng, thư viện Pydantic v2, và các khái niệm tối ưu hóa hàm mục tiêu (metric).

Hai kiến trúc compose chứ không cạnh tranh: layered stack L1–L3 (identity, rules, SOPs) assembler quanh pipeline DSPy; L4 skill có thể chính là module compiled. Và metric của compiler chính là chuẩn eval Phần 4 cài thành hàm — team đã có Part 4 discipline là đã viết xong spec metric function.

Cây quyết định khi nào tay, khi nào compile:

graph TD
    Q["Task lặp lại<br/>có golden examples?"] -->|"Không — 1 lần, không trainset"| H["Viết tay theo 8 khối<br/>(đủ tốt, rẻ hơn)"]
    Q -->|"Có: vài chục cặp<br/>+ metric chấm được"| T["Thay đổi prompt >2 lần/quý<br/>hoặc từng vỡ vì đổi model?"]
    T -->|"Không"| H
    T -->|"Có"| C["Compile với DSPy<br/>(BootstrapFewShot trước,<br/>MIPROv2 khi cần instruction search)"]

    style H fill:#e8f4f8,stroke:#2a7da0
    style C fill:#e8f8e8,stroke:#2a7da0

Production failure: khi compiler tối ưu nhầm thứ

Answer-first: Ba mode thất bại kinh điển của compiled pipeline: metric sai (compiler tự tin tối ưu hướng sai — “BootstrapFewShot với metric luôn True” cải thiện về noise), overfit trainset nhỏ (artifact thắng eval thua production), và signature drift (đổi field vô hiệu mọi demonstrations cũ). Điều kiện tiên quyết: Nắm vững lập trình Python hướng đối tượng, thư viện Pydantic v2, và các khái niệm tối ưu hóa hàm mục tiêu (metric).

Scenario 1 — metric rỗng: team cài metric = lambda e, p: True làm placeholder, chạy BootstrapFewShot qua đêm. Sáng ra artifact “cải thiện 40%” — trên noise. Bài học: metric review đứng trước prompt review trong pipeline compiled; không bao giờ compile với placeholder metric.

Scenario 2 — overfit: trainset 20 cặp, artifact pass 100% golden nhưng production sai 15%. Bài học: giữ held-out slice ngoài vòng compile (cùng kỷ luật held-out của Anthropic eval guidance); verify generalization trước khi promote.

Scenario 3 — signature drift: thêm output field vào signature, artifact cũ vẫn chạy nhưng demonstrations reference field không còn — output méo dạng. Bài học: signature change = API bump: recompile bắt buộc, changelog ghi “signature v2 → recompiled”.

Nếu bạn làm kế toán, hãy hiểu DSPy theo cách này

Answer-first: Compile phần phán đoán, giữ nguyên phần quy tắc: công thức tính thuế là rule (không compile); “đọc hóa đơn tay viết và phân loại” là judgment lặp lại có chấm điểm được — ứng viên compile đầu tiên. Điều kiện tiên quyết: Nắm vững lập trình Python hướng đối tượng, thư viện Pydantic v2, và các khái niệm tối ưu hóa hàm mục tiêu (metric).

• Công thức = rule, phân loại = judgment: việc tính lương theo công thức deterministic không cần “tối ưu”; việc đọc mô tả hóa đơn tự do để gán mã chi phí là probabilistic, lặp lại, metric-checkable — chính là ứng viên.
• Golden dataset = sao kê mẫu: vài chục cặp hóa đơn-đã-đối-chứng mà phòng đã lưu chính là trainset; không cần dữ liệu mới, chỉ cần dữ liệu đã chấm đúng.
• “Không tự điền số” cài vào signature: thêm output field insufficient_data tường minh, metric phạt mọi output tự điền — control của Phần 4 thành bảo đảm của compiled artifact.
• Provenance bắt đầu từ signature: input fields mang voucher_id — mọi output compiled truy được về chứng từ nào đã feed nó.
• Kỳ cuối tháng = recompile: quy định thuế mới, loại hóa đơn mới làm distribution trôi — period-end close bao gồm một pass recompile + eval.
• Chi phí: kết quả T5-770M đọc theo hướng tiết kiệm — compile cho model nhỏ, chạy rẻ hơn nhiều, chất lượng giữ được. Compilation là đòn bẩy chi phí, không chỉ chất lượng.

Một câu cho toàn bộ paradigm: “Thay vì dạy AI đọc hóa đơn bằng cách diễn giải dài, bạn đưa cho nó 50 hóa đơn đã chấm đúng và bảo máy tự học cách hỏi.”

Ý chính cần nhớ

Answer-first: DSPy không phải “prompt engineering đã chết” — đúng hơn: “tối ưu token bằng tay đã chết.” Mental model mới: ngừng viết prompt, bắt đầu định nghĩa contract và metric. Điều kiện tiên quyết: Nắm vững lập trình Python hướng đối tượng, thư viện Pydantic v2, và các khái niệm tối ưu hóa hàm mục tiêu (metric).

DSPy đại diện cho bước chuyển nơi chất lượng prompt là hàm của dữ liệu và metric, không phải trực giác.

Ba con số mang đi (đều có baseline):

• +25% / +65% — GPT-3.5 / llama2-13b-chat vượt standard few-shot khi compile (Stanford 2023)
• 5–46% / 16–40% — vượt expert-created demonstrations
• +13% — MIPRO cải thiện trên 5/7 program so baseline optimizer mạnh (EMNLP 2024)

Ranh giới trung thực: DSPy cần trainset, tối ưu module chứ không tối ưu tổ chức, tốn compute thật, và fail thảm khi metric sai — trong biên đó, nó thắng tay một khoảng đo được; ngoài biên đó, Prompt Standard vẫn trị.

Chương tiếp theo: Phần 8 — Production PromptOps Pipeline — compiled artifact vào CI/CD gate như code.

🔗 Đọc thêm các chuyên đề liên quan:

• Phần 4 — Version prompt và eval (2026) — metric function chính là chuẩn eval của chương này
• Phần 6 — Từ Prompting sang Context Engineering (2026) — compiled module sống trong context stack
• Phần 9 — MCP và Hybrid RAG (2026) — multi-hop retrieval case của DSPy
• Series: MCP Engineering In Production
• Kiến trúc Microservices Golang & DDD

❓ Câu Hỏi Thường Gặp (FAQ)

📚 Nguồn nghiên cứu (verification anchors)

Bản nghiên cứu đầy đủ 100 rounds: reports/research-prompt-standard-part-7-declarative-prompting-dspy-100-rounds.{md,json} (dossier nội bộ series, mirror cả 2 repo). Ghi chú grounding: 62/100 rounds có URL nguồn bên ngoài; 34/100 truy vết series-internal; 4 rounds gắn nhãn [INFERENCE]. Ghi chú phiên bản: code examples target DSPy 2.5+.

← Chương trước: Phần 6 — Từ Prompting sang Context Engineering (2026) | Mục lục Series | Chương tiếp theo: Phần 8 — Production PromptOps Pipeline (2026) →