DSPy: lập trình mô hình ngôn ngữ thay vì viết prompt, tối ưu bằng chỉ số đo
Đăng ngày 12/10/2026
Mục lục bài nghiên cứu
Viết chương trình thay vì viết prompt: DSPy đáng dùng khi nào?
DSPy, viết tắt của Declarative Self-improving Python, là framework Python để lập trình thay vì viết prompt (lời nhắc) cho mô hình ngôn ngữ. README nêu hai năng lực cốt lõi: dựng hệ thống AI dạng mô-đun và cung cấp thuật toán tối ưu prompt lẫn trọng số, áp dụng từ bộ phân loại đơn giản, pipeline RAG (truy xuất tài liệu rồi sinh câu trả lời) tới vòng lặp agent [1].
Giá trị của DSPy chỉ lộ ra khi có thứ để đo: phần tối ưu trong tài liệu bắt đầu bằng một chỉ số, tức hàm Python chấm điểm từng dự đoán, cùng một điểm nền để so [5].
Nên cân nhắc cho bài toán có cấu trúc rõ như phân loại, trích xuất trường, hỏi đáp trên tài liệu, khi đã có ví dụ được người xác nhận. Không nên bắt đầu bằng DSPy nếu chỉ cần một lời gọi đơn lẻ, không có dữ liệu đánh giá hoặc không ai đọc được Python. Lưu ý thời điểm: 3.4 là bản chuyển tiếp của tầng giao tiếp mô hình, và 3.5 sẽ gỡ một số giao diện cũ [9].
Vì sao prompt viết tay khó duy trì khi hệ thống lớn dần?
Một ứng dụng thường khởi đầu bằng một prompt chạy được rồi phình dần: thêm ví dụ, quy tắc định dạng, câu xử lý ngoại lệ. Đổi mô hình là chất lượng thay đổi khó đoán, và không ai chắc dòng nào đang gánh việc gì. README gọi đó là prompt dễ vỡ và đề xuất viết mã Python ghép nối được [1].
Công sức đánh giá thường dồn vào kiểm tra cấu trúc như JSON có hợp lệ, có đủ trường hay không. Tài liệu chỉ số của DSPy lập luận rằng signature đã lo phần cấu trúc, nên chỉ số chỉ cần nhắm vào mục tiêu của nhiệm vụ [5].
Tối ưu bằng tay cũng không lặp lại được. Optimizer (bộ tối ưu) của DSPy chạy chương trình nhiều lần và giữ phiên bản điểm cao nhất, bằng cách chọn ví dụ minh họa, viết lại chỉ dẫn hoặc tinh chỉnh mô hình [5]; kết quả là một tạo tác lưu và nạp lại được, thay cho kinh nghiệm nằm trong đầu một người [11].
Signature, Module, Adapter và Optimizer ghép với nhau thế nào?
Signature là bản khai các trường đầu vào và đầu ra [10], dạng ngắn nhất là chuỗi question -> answer [6]. Module là đơn vị thực thi: ChainOfThought thêm trường suy luận trước câu trả lời [6][10], còn chương trình tự viết kế thừa dspy.Module và đặt logic trong forward() [6].
Adapter đứng giữa signature và mô hình: định dạng chỉ dẫn, các trường và ví dụ thành tin nhắn chat, gửi lời gọi, rồi phân tích phản hồi thành giá trị Python có kiểu [10]. ChatAdapter là mặc định; JSONAdapter, XMLAdapter, TwoStepAdapter, BAMLAdapter thay vào được mà không phải sửa signature [10].
Tầng mô hình là dspy.LM, khai báo bằng chuỗi nhà cung cấp và tên mô hình; dspy.configure đặt mặc định cho cả tiến trình, dspy.context ghi đè trong phạm vi hẹp [4]. Trang cài đặt mô tả LiteLLM là lớp chuẩn hóa nhà cung cấp [4], còn tài liệu chuyển đổi 3.4 cho biết tầng LM nay dùng đối tượng lm15 đóng gói sẵn, với LiteLLM là backend tương thích [9].
Optimizer nhận chương trình, tập huấn luyện và chỉ số, rồi chỉnh một hay nhiều trong ba núm: chỉ dẫn, ví dụ minh họa, trọng số [11]. compile() trả về bản sao mới; module đã biên dịch được gắn cờ để optimizer chạy sau bỏ qua, nhờ vậy có thể tối ưu phần trong rồi nhúng vào chương trình ngoài [11].
Một lời gọi đi qua những bước nào từ đầu vào tới Prediction?
Khi chương trình được gọi, module chuyển signature, ví dụ và dữ liệu cho adapter. Mọi adapter đi qua năm bước: tiền xử lý để tận dụng tính năng gốc như gọi hàm hay suy luận; định dạng tin nhắn hệ thống, ví dụ và câu hỏi; gọi mô hình; hậu xử lý để tách lời gọi công cụ và kiểu phản hồi gốc như Reasoning; rồi phân tích [10].
Bước phân tích tìm giá trị từng trường và đưa qua hàm ép kiểu dùng chung parse_value, nên mọi adapter áp cùng quy tắc [10]. Nếu ChatAdapter không đọc được định dạng, nó mặc định chạy lại qua JSONAdapter; tài liệu khuyên tắt cơ chế này khi kiểm thử [10].
Ở tầng dưới, DSPy giữ quyền với bộ nhớ đệm, thử lại, sinh nhiều ứng viên, callback và lịch sử; mức dùng token được ghi một lần cho mỗi lời gọi công khai, lượt trúng bộ nhớ đệm không cộng mức dùng [9]. Thử lại giãn cách 1, 2, 4 giây, tối đa 60 giây, và không bảo đảm chỉ thực hiện một lần; khi lặp yêu cầu là không an toàn, đặt num_retries=0 [9].
Dữ liệu cho tối ưu đi đường riêng: mỗi bản ghi thành dspy.Example, with_inputs chỉ định trường nào vào chương trình, phần còn lại giữ cho chỉ số; dspy.Evaluate chấm điểm trên tập kiểm định [5]. Đầu ra là chương trình đã biên dịch, lưu lại để phục vụ nhiều lần [11].
Bản 3.4 đổi gì ở tầng LM, và cần chuẩn bị gì cho 3.5?
Tài liệu chuyển đổi tại commit khảo sát gọi 3.4 là bản chuyển tiếp: giao diện cũ vẫn chạy nhưng phát DeprecationWarning, còn 3.5 sẽ gỡ cách gọi kiểu OpenAI qua tham số messages=, LM tự viết bằng BaseLM.forward(), các lớp bọc LegacyEngine và lối tắt complete_legacy() [9]. Python có thể ẩn các cảnh báo này theo mặc định [9].
Engine có ba chế độ: auto (mặc định) ưu tiên lm15 gốc và chọn LiteLLM trước khi thực thi nếu yêu cầu không biểu diễn được; lm15 bắt buộc backend gốc; litellm dùng backend tương thích. Lỗi xác thực, quá thời gian hay lỗi nhà cung cấp không khiến hệ thống tự đổi backend, và LiteLLM không bị khai tử [9].
Một số khác biệt chạm tới chi phí: cần n câu trả lời thì đường lm15 gốc gửi n yêu cầu riêng và tính phí token đầu vào nhiều lần; thiết lập không mang nguyên văn được sẽ bị điều chỉnh và ghi vào mục adaptations, như temperature 1.5 trên Anthropic thành 1.0; ước tính chi phí để là chưa biết, không phải bằng không, khi thiếu bảng giá [9].
Với mã cũ, việc cần làm là bật cảnh báo, chuyển hội thoại nhiều lượt sang Request của dspy.lm15 và viết lại LM tùy biến thành engine có complete(request). Đối tượng pickle cũ chứa lớp đã bị gỡ không được tự chuyển đổi, phải nạp và xuất lại trong môi trường gốc [9].
Những năng lực nào đã được đối chiếu trong tài liệu?
Cài bằng pip install dspy hoặc uv add dspy, cần Python 3.10 trở lên; bản mới nhất cài được từ nhánh main [1][4]. Kết nối mô hình bằng dspy.LM và đặt mặc định bằng dspy.configure [4].
Adapter: ChatAdapter; JSONAdapter ưu tiên chế độ đầu ra có cấu trúc theo thứ tự json_schema, json_object rồi JSON văn bản; XMLAdapter; TwoStepAdapter cho mô hình suy luận định dạng kém; BAMLAdapter cho kiểu lồng nhau phức tạp. Kiểu tùy biến gồm Image, Audio, File, Code, History, Reasoning, Tool, ToolCalls, Citations; xuất dữ liệu tinh chỉnh hiện chỉ có ở ChatAdapter [10].
Optimizer: LabeledFewShot, BootstrapFewShot, BootstrapFewShotWithRandomSearch, KNNFewShot cho ví dụ; COPRO, GEPA cho chỉ dẫn; MIPROv2, SIMBA, InferRules cho cả hai; BootstrapFinetune cho trọng số; BetterTogether, Ensemble để kết hợp; AvatarOptimizer cho chương trình kiểu agent. Riêng GEPA đọc cả nhận xét bằng lời từ chỉ số, dạng Prediction(score, feedback) [11].
Đánh giá và triển khai: dspy.Example, dspy.Evaluate, chỉ số trả số thực theo quy ước từ 0 đến 1 [5]; dspy.asyncify, dspy.streamify, tích hợp MLflow [6]. README liệt kê các bài báo nền tảng, trong đó có bài GEPA năm 2025 [1]; bài này không dùng kết quả của chúng làm bằng chứng cho bài toán doanh nghiệp.
Ai nên đầu tư học DSPy, và lĩnh vực nào hợp?
Hợp nhất là kỹ sư Python hoặc kỹ sư dữ liệu quen tư duy đánh giá: có tập dữ liệu, có chỉ số, biết chia tập huấn luyện và kiểm tra. DSPy chuyển công việc từ viết câu chữ sang thiết kế chương trình và thước đo.
Lĩnh vực hợp là nơi có nhiều văn bản lặp lại và đáp án kiểm chứng được: phân loại yêu cầu khách hàng, trích xuất trường từ email, hợp đồng, hóa đơn, hỏi đáp trên kho tài liệu nội bộ, vốn phổ biến trong tài chính, bảo hiểm, logistics và thương mại điện tử.
Ít hợp với nhóm cần giao diện kéo thả, ứng dụng sáng tạo không có tiêu chí chấm, hay dự án chỉ vài chục lượt gọi mỗi tháng. Với kho ghi chú cá nhân dạng second brain, DSPy chỉ có ích khi đã có câu hỏi lặp lại và đáp án tham chiếu để đo.
Một công ty môi giới bảo hiểm có thể thử DSPy ra sao?
Đây là kịch bản đề xuất, không mô tả một công ty có thật: một công ty môi giới bảo hiểm ở TP.HCM phục vụ khách hàng doanh nghiệp trong các mảng tài sản – kỹ thuật, hàng hóa và sức khỏe nhóm. Bộ phận dịch vụ nhận nhiều email yêu cầu chào phí, sửa đổi bổ sung, thông báo tổn thất, viết tự do bằng tiếng Việt lẫn tiếng Anh; nhân viên đọc, phân loại rồi chép vào phiếu yêu cầu gửi các công ty bảo hiểm.
Đề xuất hai module: một phân loại email vào danh mục yêu cầu cố định, một trích các trường như loại hình bảo hiểm, đối tượng, giá trị bảo hiểm, địa điểm rủi ro, thời hạn, lịch sử tổn thất. Trường có danh sách giá trị được khai báo bằng Literal để bước phân tích chỉ nhận giá trị hợp lệ [10]. Kết quả vào hệ thống quản lý khách hàng ở trạng thái chờ duyệt; chuyên viên môi giới vẫn là người tư vấn và chịu trách nhiệm.
Dữ liệu huấn luyện lấy từ hồ sơ cũ đã được chuyên viên xác nhận và che định danh. Chỉ số kết hợp kiểm tra quy tắc với so sánh nhãn chuẩn theo từng trường [5]. Bắt đầu bằng BootstrapFewShot làm mốc, sau đó mới thử MIPROv2 hoặc GEPA; GEPA cần chỉ số trả về cả điểm lẫn nhận xét [11].
Dữ liệu sức khỏe nhóm nhạy cảm, nên giai đoạn đầu chỉ làm mảng tài sản và hàng hóa. Nếu chính sách nội bộ không cho gửi dữ liệu ra ngoài, có thể trỏ dspy.LM tới máy chủ mô hình nội bộ qua đăng ký nhà cung cấp HTTP hoặc engine tùy biến [9], rồi đo lại bằng cùng bộ chỉ số.
Đưa chương trình DSPy vào vận hành cần những gì?
Tài liệu triển khai đưa ra hai đường. FastAPI là đường nhẹ: dspy.asyncify chạy chương trình trong luồng riêng, mặc định tối đa 8 lời gọi đồng thời và chỉnh được bằng async_max_workers; dspy.streamify phát đầu ra từng phần dạng server-sent events [6].
MLflow là đường thứ hai: ghi chương trình kèm yêu cầu môi trường bằng mlflow.dspy.log_model, phục vụ bằng mlflow models serve, đóng gói thành ảnh Docker; với MLflow 2.22.0, chương trình phải được bọc trong lớp kế thừa dspy.Module [6].
Vòng đời tạo tác là điểm then chốt: biên dịch tốn kém còn suy luận trên chương trình đã biên dịch thì rẻ, nên chỉ hợp lý khi biên dịch một lần cho mỗi phiên bản rồi phục vụ nhiều lần [11]. Cần quản lý phiên bản cho mã, dữ liệu, chỉ số, mô hình dùng khi biên dịch và tạo tác. Khi xong việc, đóng pool kết nối bằng lm.close() hoặc await lm.aclose() [9].
Rủi ro bảo mật nằm ở đâu trong một chương trình DSPy?
DSPy chạy trong tiến trình của ứng dụng, nên ranh giới bảo mật do ứng dụng quyết định: ai gọi được endpoint, dữ liệu nào tới nhà cung cấp mô hình, log nằm ở đâu. Ví dụ FastAPI trong tài liệu trả nguyên chuỗi ngoại lệ về client qua lỗi HTTP 500 [6]; production nên ẩn chi tiết lỗi và thêm xác thực.
Từ bản 3.3, tạo hay kiểm tra giá trị Image, Audio, File không còn tự đọc tệp cục bộ hay tải URL khi gặp chuỗi giống đường dẫn, để bước phân tích đầu ra mô hình không vô tình cấp quyền truy cập máy chủ; muốn tải phải gọi rõ from_path hoặc from_url [10]. from_url theo chuyển hướng và không kiểm tra danh sách cho phép chống SSRF (giả mạo yêu cầu phía máy chủ), nên ứng dụng phải tự kiểm tra URL không tin cậy [10].
Trạng thái LM lưu dạng JSON loại bỏ khóa API; nạp engine hoặc lớp LM tùy biến phải bật allow_unsafe_lm_state=True, và các cơ chế nạp có kiểm soát vẫn giữ nguyên [9]. Chỉ nạp chương trình đã lưu từ nguồn tin cậy, vì pickle của Python có thể thực thi mã khi nạp.
Thử lại có thể gửi lặp một yêu cầu mà nhà cung cấp đã xử lý hoặc đã tính phí [9], nên công cụ có tác dụng phụ cần num_retries=0 hoặc phải chịu được lặp. Lỗ hổng được báo riêng qua GitHub Private Vulnerability Reporting hoặc email nhóm duy trì, sau khi xóa bí mật khỏi báo cáo [3].
Giấy phép MIT bao phủ những gì trong kho DSPy?
Tệp LICENSE ở gốc kho là MIT, bản quyền năm 2023 của Stanford Future Data Systems. Văn bản cho phép sử dụng, chỉnh sửa, phân phối và bán bản sao, với điều kiện kèm thông báo bản quyền cùng nội dung giấy phép; mọi bảo đảm đều bị loại trừ [2].
Kho còn hai tệp giấy phép trong thư mục con. Mã lm15 đóng gói kèm (vendored) trong DSPy [9] có tệp giấy phép MIT riêng ở dspy/_vendor, bản quyền năm 2026 của nhóm đóng góp lm15 [7]. Thư mục dspy/clients/model_metadata mang giấy phép MIT ghi bản quyền Berri AI năm 2023, kèm điều khoản rằng nội dung thư mục enterprise, nếu có, theo giấy phép riêng [8]. Phân phối lại DSPy cần giữ cả các thông báo này.
Giấy phép mã không bao trùm mô hình được gọi, dữ liệu huấn luyện, dịch vụ API hay thư viện phụ thuộc cài từ gói riêng; ví dụ minh họa lấy từ dữ liệu doanh nghiệp nằm trong chương trình đã biên dịch thuộc trách nhiệm của doanh nghiệp. Bài dựa trên commit f1260ff1 ngày 08/10/2026, giai đoạn 3.4 theo tài liệu chuyển đổi [9]; tại ngày kiểm tra, không thấy dấu hiệu kho bị lưu trữ hay đổi giấy phép.
Chi phí của DSPy nằm ở biên dịch hay ở phục vụ?
Thư viện miễn phí theo MIT [2]; chi phí nằm ở lượt gọi mô hình khi biên dịch và khi phục vụ, giờ công xây dữ liệu và chỉ số, và hạ tầng. Tài liệu chọn optimizer xếp LabeledFewShot, BootstrapFewShot vào nhóm gần như không tốn; BootstrapRS, MIPROv2, GEPA tốn tiền thật; BetterTogether trả cả hai loại [11].
Tài liệu này cảnh báo GEPA và MIPROv2 có thể tiêu tới hàng trăm đô la tiền gọi mô hình trong một lần chạy [11]; đó là cảnh báo của nhóm phát triển, không phải ước tính cho một bài toán cụ thể. Tinh chỉnh trọng số cộng thêm chi phí huấn luyện và triển khai mô hình mới [11].
Giả định ngân sách cho ví dụ môi giới gồm vài trăm mẫu gán nhãn, số lần biên dịch mỗi quý, số email mỗi ngày, số token mỗi email và tỷ lệ cần sửa. TwoStepAdapter nhân đôi số lời gọi mỗi lần suy luận [10]; bộ nhớ đệm giúp lần chạy lặp không cộng mức dùng [9]. Nhân lực gồm một kỹ sư Python, một chuyên viên gán nhãn và một người phụ trách dữ liệu cá nhân.
So với viết prompt thủ công, framework điều phối hay tinh chỉnh mô hình thì sao?
Viết prompt thủ công kèm bộ kiểm thử là cách rẻ nhất để bắt đầu và đủ cho nhiều bài toán nhỏ. Khác biệt của DSPy là biến bộ kiểm thử thành tín hiệu tối ưu: cùng chỉ số ấy được optimizer dùng để chọn ví dụ hoặc sửa chỉ dẫn [5][11].
Framework điều phối như LangChain hay LlamaIndex thường được dùng để ghép thành phần, công cụ và nguồn dữ liệu; DSPy cũng ghép module nhưng trọng tâm ở signature và optimizer, và hai hướng không loại trừ nhau. Thư viện ép đầu ra có cấu trúc như Instructor lo phần hình thức; DSPy cũng tận dụng chế độ structured output qua JSONAdapter [10] nhưng thêm lớp tối ưu.
Tinh chỉnh trọng số trực tiếp hợp khi có nhiều dữ liệu và mô hình mở tự lưu trữ. Tài liệu DSPy coi đó là đòn bẩy cuối: chỉ chuyển sang khi tối ưu prompt chững lại, vì phần cải thiện thêm thường nhỏ còn chi phí lớn hơn nhiều [11].
Khi nào DSPy không phải lựa chọn đúng?
Không có chỉ số thì không có tối ưu; với tiêu chí mơ hồ như giọng văn thuyết phục, phải dùng mô hình khác làm giám khảo [5], kéo theo chi phí và thiên lệch của giám khảo. DSPy cũng không tự chọn optimizer thay người dùng [11].
Tối ưu bằng ví dụ dễ khớp quá mức với tập nhỏ; tài liệu coi tối ưu chỉ dẫn thường tổng quát hơn, nhưng đó chỉ là mặc định hữu ích [11]. Cơ chế tự chuyển sang JSONAdapter có thể che lỗi định dạng [10]. Mã dùng messages= hay LM tùy biến kiểu cũ sẽ ngừng chạy ở 3.5 [9], trong khi nhiều hướng dẫn trên mạng vẫn viết cho giao diện cũ.
Không nên dùng khi cần độ trễ rất thấp mà ChainOfThought hay TwoStepAdapter làm tăng token và số lời gọi, khi quyết định có hệ quả pháp lý mà không có người duyệt, hoặc khi dữ liệu huấn luyện chứa thông tin cá nhân chưa được phép dùng.
Thử nghiệm tám tuần nên đo những gì?
Tuần 1–2: chọn bài toán hẹp như phân loại email mảng tài sản; gom 300 đến 500 mẫu đã che danh tính, nhờ hai chuyên viên gán nhãn độc lập để biết mức đồng thuận giữa người với người; chia tập trước khi viết mã. Lộ trình này là gợi ý, chưa được chạy thử.
Tuần 3–4: viết signature và chương trình nền, chạy dspy.Evaluate để có điểm nền [5]; thử BootstrapFewShot rồi một optimizer tìm kiếm, ghi chi phí, thời gian biên dịch và điểm kiểm định [9][11]; đặt use_json_adapter_fallback=False khi kiểm thử [10].
Tuần 5–7: chạy đối chứng cùng nhân viên, đo độ chính xác từng trường trên tập kiểm tra, tỷ lệ hồ sơ phải sửa, thời gian và chi phí mỗi hồ sơ, số lỗi nghiêm trọng như gán nhầm loại hình bảo hiểm; thử thêm email trộn hai ngôn ngữ, thiếu tệp đính kèm, nhà cung cấp mô hình trả lỗi.
Tuần 8 quyết định theo ngưỡng đặt trước, ví dụ chương trình đã biên dịch vượt rõ điểm nền và không thua mức đồng thuận giữa hai chuyên viên ở các trường quan trọng. Dừng nếu chi phí biên dịch vượt ngân sách, lỗi nghiêm trọng lặp lại, hoặc không che được dữ liệu cá nhân như yêu cầu.
Kết luận: DSPy đáng giá khi doanh nghiệp sẵn sàng đo
DSPy đổi câu hỏi từ tìm prompt hay nhất sang định nghĩa chương trình, dữ liệu, chỉ số rồi để optimizer tìm cấu hình tốt hơn [1][11]; việc tách signature, adapter và optimizer giúp đổi mô hình mà không viết lại logic [10].
Cái giá là kỷ luật dữ liệu và quản lý phiên bản tạo tác, cộng với việc viết mã theo giao diện LM mới trước mốc 3.5 [9].
Với doanh nghiệp Việt Nam có nhiều văn bản nghiệp vụ lặp lại như môi giới bảo hiểm, DSPy đáng thử cho trích xuất và phân loại, miễn là con người giữ quyền tư vấn và dữ liệu cá nhân được bảo vệ ngay từ thiết kế.
Bài này dựa trên nguồn nào và giới hạn ở đâu?
Bài thuộc chuyên mục AI agents và ứng dụng của loạt tuyển chọn năm 2026. DSPy lọt vào danh sách nhờ một bản lưu trữ GitHub Trending chia theo ngôn ngữ do bên thứ ba duy trì; trang làm chứng là ngày 13/02/2026, mục Python, hạng 15 [12], và theo dữ liệu tuyển chọn, dự án xuất hiện 5 lần, lần cuối ngày 12/08/2026. Bản lưu trữ chỉ có bốn mục Python, Go, JavaScript, Swift và vắng hai ngày 03/09, 12/10, nên đây không phải bảng Top 100 chính thức nào.
Nguồn tại commit f1260ff14610286cb295c7d3a5ee2cbfd0ba5cb9 (08/10/2026), đối chiếu ngày 12/10/2026, gồm README, LICENSE, SECURITY.md, các trang cài đặt, chỉ số, triển khai, hai tệp giấy phép trong thư mục con, tài liệu chuyển đổi LM bản 3.4, tài liệu adapter và tài liệu chọn optimizer [1][2][3][4][5][6][7][8][9][10][11]. Trang cài đặt mô tả LiteLLM còn tài liệu chuyển đổi mô tả lm15; bài dựa vào tài liệu chuyển đổi cho các kết luận về bản 3.4.
Bài là nghiên cứu tài liệu có AI hỗ trợ, không phải công bố khoa học qua bình duyệt; DSPy không được cài, optimizer không được chạy, độ chính xác và chi phí không được đo. Kịch bản môi giới bảo hiểm, giả định ngân sách và lộ trình tám tuần đều là phân tích của bài, chưa được kiểm chứng thực tế.