Gọi hàm trong OpenAI API: Nó thực sự làm gì và cách sử dụng đúng cách

Bạn chuyển tiếp thông điệp của người dùng tới GPT API, và thay vì một câu trả lời ngôn ngữ tự nhiên, mô hình trả về cho bạn một đối tượng JSON có cấu trúc cho biết chính xác nên gọi hàm nào và với những tham số nào. Đó là function calling — và nó thay đổi kiểu ứng dụng bạn có thể xây dựng với LLM.

Hầu hết các lập trình viên nghe “function calling” và cho rằng mô hình đang thực thi mã thay họ. Không phải vậy.

Khi dùng function calling, bản thân LLM không thực thi hàm. Thay vào đó, nó xác định hàm phù hợp, thu thập tất cả tham số cần thiết và cung cấp thông tin ở dạng JSON có cấu trúc.

Ứng dụng của bạn vẫn chịu trách nhiệm chạy logic thực tế. Mô hình chỉ cho bạn biết cần chạy cái gì và với đầu vào nào.

Sự khác biệt đó quan trọng hơn bạn nghĩ, và nó định hình mọi thứ từ cách bạn thiết kế tích hợp cho tới cách bạn nghĩ về bảo mật.

Thực chất gọi hàm là gì — và mọi người thường hiểu sai điều gì

Function calling (còn gọi là tool calling) cung cấp một cách mạnh mẽ và linh hoạt để các mô hình của OpenAI giao tiếp với hệ thống bên ngoài và truy cập dữ liệu ngoài phạm vi dữ liệu huấn luyện.

Cách đặt tên là nguồn gốc nhầm lẫn đầu tiên. Mọi người nghĩ mô hình đang thực thi thứ gì đó. Không phải vậy.

Có nhiều tên gọi và cách giải thích cho function calling, nhưng tất cả tóm lại một câu: “function calling là một dạng khả năng xuất ra có cấu trúc của một mô hình ngôn ngữ lớn.” LLM không tự gọi bất kỳ hàm nào; chúng đề xuất bạn nên gọi hàm nào từ các hàm đã được bạn định nghĩa trước và cung cấp cho LLM trong prompt.

Sự nhầm lẫn thứ hai nằm ở bề mặt API cũ.

Tham số functions và function_call đã bị loại bỏ với bản phát hành 2023-12-01-preview của API. Tham số thay thế cho functions là tools.

Nếu bạn đang theo một hướng dẫn sử dụng tham số functions cũ, bạn đã dùng cú pháp lỗi thời. Hãy dùng tools và tool_choice.

Một function là một dạng cụ thể của tool, được định nghĩa bởi một JSON schema. Định nghĩa function cho phép mô hình truyền dữ liệu tới ứng dụng của bạn, nơi mã của bạn có thể truy cập dữ liệu hoặc thực hiện các hành động mà mô hình đề xuất.

Chính lược đồ đó mang lại lợi thế về độ tin cậy cho function calling so với prompt thuần — bạn không còn trông chờ mô hình định dạng đầu ra đúng nữa, bạn đang áp đặt cấu trúc ở cấp API.

Cách function calling hoạt động trong OpenAI API — từng bước

Tool calling là một cuộc hội thoại nhiều bước giữa ứng dụng của bạn và mô hình thông qua OpenAI API. Luồng tool calling có năm bước ở mức cao: gửi một yêu cầu tới mô hình với các tool mà nó có thể gọi...

Dưới đây là từng bước trông như thế nào trong thực tế.

Bước 1: Định nghĩa lược đồ hàm của bạn. Bạn mô tả mỗi hàm có sẵn như một đối tượng JSON trong tham số tools. Lược đồ gồm tên hàm, một mô tả ngôn ngữ tự nhiên mà mô hình dùng để quyết định khi nào nên gọi, và một khối parameters tuân theo quy ước JSON Schema.

Phần description càng chi tiết — về các tình huống có thể và nên gọi hàm — càng tốt. Lưu ý, mô tả hàm là một phần của prompt nên cũng tiêu tốn token như nhau.

Bước 2: Gửi yêu cầu. Bạn gọi Chat Completions API với thông điệp của người dùng và danh sách tools. Mô hình nhìn thấy cả hai.

Bước 3: Mô hình quyết định có gọi hàm hay không.

Một cuộc gọi hàm đề cập tới dạng phản hồi đặc biệt mà bạn có thể nhận từ mô hình nếu nó xem xét prompt và xác định rằng, để làm theo hướng dẫn, nó cần gọi một trong các tool sẵn có. Nếu mô hình nhận prompt kiểu “thời tiết ở Paris thế nào?”, nó có thể phản hồi bằng một tool call cho tool get_weather, với Paris là đối số vị trí.

Bước 4: Mã của bạn thực thi hàm. Bạn phân tích phản hồi của mô hình, trích xuất tên hàm và đối số, rồi chạy mã thực tế trong môi trường của bạn. API trả về JSON có cấu trúc — bạn quyết định sẽ làm gì với nó.

Bước 5: Gửi kết quả quay lại.

Sau đó bạn gửi toàn bộ định nghĩa tool, prompt gốc, tool call của mô hình và đầu ra của tool call về lại cho mô hình để cuối cùng nhận một câu trả lời dạng văn bản

— kiểu như “Thời tiết ở Paris hôm nay là 25°C.”

Một chi tiết mà hầu hết hướng dẫn đều bỏ qua:

khi bạn đặt strict: true trong định nghĩa hàm, Structured Outputs đảm bảo rằng các đối số do mô hình tạo ra cho một function call khớp chính xác với JSON Schema bạn đã cung cấp.

Bật strict thành true sẽ đảm bảo các function call tuân thủ nghiêm ngặt lược đồ hàm, thay vì chỉ ở mức tốt nhất có thể. OpenAI khuyến nghị luôn bật chế độ nghiêm ngặt.

Luôn luôn. Không có lý do chính đáng nào để không bật.

Cũng có khái niệm gọi hàm song song cần biết.

Tùy theo truy vấn của người dùng, mô hình sẽ kích hoạt gọi hàm song song nếu dùng các model mới phát hành vào hoặc sau ngày 6 tháng 11, 2023.

Điều này có nghĩa là một yêu cầu như “thời tiết ở London và Tokyo thế nào?” có thể kích hoạt hai tool call đồng thời, thay vì xâu chuỗi tuần tự.

Các trường hợp sử dụng thực tế của Function Calling

Ví dụ thời tiết xuất hiện ở khắp nơi vì nó sạch sẽ. Các trường hợp thực tế ngoài sản xuất thì lộn xộn và thú vị hơn.

Quy trình hỗ trợ khách hàng với dữ liệu trực tiếp

Function calling hữu ích cho rất nhiều tình huống — ví dụ, một trợ lý AI cần truy xuất dữ liệu khách hàng mới nhất từ hệ thống nội bộ khi người dùng hỏi “đơn hàng gần đây của tôi là gì?” trước khi có thể tạo câu trả lời.

Mô hình xác định ý định, trích xuất ID khách hàng từ ngữ cảnh và gọi API nội bộ của CRM của bạn. Không cần regex mong manh. Không cần mẫu prompt dễ vỡ vì thiếu một dấu phẩy.

Trích xuất dữ liệu có cấu trúc ở quy mô lớn

Một pipeline trích xuất dữ liệu lấy văn bản thô, chuyển nó thành dữ liệu có cấu trúc và lưu vào cơ sở dữ liệu cũng rất phù hợp. Bạn có được lược đồ nhất quán trên hàng nghìn tài liệu mà không cần tinh chỉnh logic phân tích theo từng loại tài liệu.

Chuyển ngôn ngữ tự nhiên thành lời gọi API

Các giải pháp dùng LLM để trích xuất và gán thẻ dữ liệu, ứng dụng có thể giúp chuyển ngôn ngữ tự nhiên thành lời gọi API hoặc truy vấn cơ sở dữ liệu hợp lệ, và công cụ truy xuất tri thức hội thoại tương tác với một kho tri thức — tất cả những thứ này hưởng lợi từ cam kết về định dạng đầu ra của function calling. Khi bạn cần đầu ra để điều khiển các hệ thống phía sau, bạn không thể dung thứ sự biến thiên.

Quy trình tác tử với nhiều công cụ

Đối với lập trình viên, function calling cho phép truy cập dữ liệu thời gian thực để vượt qua hạn chế về thời điểm cắt dữ liệu huấn luyện bằng cách lấy giá cổ phiếu, thời tiết, hoặc các bản ghi cơ sở dữ liệu gần đây. Nó cũng cho phép thực thi hành động — biến LLM từ một quan sát viên thụ động thành một tác nhân chủ động có thể thay đổi trạng thái, như gửi email, cập nhật CRM, hoặc triển khai mã.

Khác biệt then chốt so với một chatbot thuần văn bản: mô hình không chỉ tạo văn bản, nó đang điều phối các thao tác thực sự trên hệ thống của bạn.

Thực hành tốt với Function Calling — điều các lập trình viên thường làm sai

Đây là mục mà đa số hướng dẫn bỏ qua, và đó là lý do các nhóm phải debug các lỗi lạ lúc 2 giờ sáng.

Viết mô tả quá chung chung. Mô hình dùng mô tả hàm của bạn để quyết định khi nào nên gọi. Nếu mô tả chung chung — kiểu như “xử lý yêu cầu người dùng” — mô hình không có tín hiệu đáng tin cậy để kích hoạt. Hãy cụ thể về điều kiện kích hoạt và hình dạng đầu vào mong đợi. Hãy coi mô tả như một bản hợp đồng, không phải nhãn dán.

Công khai quá nhiều hàm cùng lúc

Mô tả function có thể tiêu tốn một số lượng token đáng kể trong prompt đầu vào.

Nạp định nghĩa cho hơn 50+ tool vào system prompt gây hai vấn đề: chi phí và độ trễ, vì định nghĩa tool tiêu thụ token đầu vào; và suy giảm độ chính xác, vì khi số lượng tùy chọn tool tăng, khả năng của mô hình trong việc chọn đúng công cụ giảm.

Hãy bắt đầu với tập hàm nhỏ nhất mà trường hợp sử dụng của bạn thực sự cần.

Giả định mô hình sẽ không bịa tham số. Nó sẽ bịa.

Mô hình có thể bịa tham số

— đặc biệt với các trường tùy chọn không bị ràng buộc rõ bằng một enum. Đây chính là lý do strict: true quan trọng: nó loại bỏ khả năng mô hình phát minh ra các trường nằm ngoài lược đồ của bạn.

Không xử lý vòng hội thoại nhiều lượt. Lập trình viên thường xây dựng con đường thuận lợi — người dùng hỏi, mô hình gọi hàm, xong.

Các mô hình có thể tạo ra function call không khớp lược đồ bạn định nghĩa hoặc cố gắng gọi một hàm bạn không cung cấp. Nếu mô hình tạo ra các function call nằm ngoài dự kiến, hãy thử chèn một câu vào thông điệp hệ thống nói rằng “Chỉ dùng những hàm đã được cung cấp cho bạn.”

Hãy xây dựng cho cả các tình huống ngoại lệ.

Bỏ qua bước xác nhận trước khi thực hiện thao tác ghi.

Hãy ý thức về tác động thực tế của các function call mà bạn dự định thực thi, đặc biệt những cái kích hoạt hành động như chạy mã, cập nhật cơ sở dữ liệu, hoặc gửi thông báo. Với các hàm thực hiện hành động, rất nên triển khai một bước để người dùng xác nhận trước khi thực thi.

Nếu một cuộc gọi hàm có thể xóa dữ liệu, gửi tiền, hoặc thay đổi trạng thái bên ngoài, cần có con người phê duyệt trước.

Cân nhắc về bảo mật và độ tin cậy

Function calling mở rộng những gì một LLM có thể làm. Nó cũng mở rộng những gì một kẻ tấn công có thể khiến nó làm.

Mối đe dọa chính ở đây là prompt injection.

Mục tiêu cuối cùng của prompt injection rất đa dạng nhưng có thể bao gồm rò rỉ dữ liệu riêng tư thông qua các tool call hạ nguồn, thực hiện hành động lệch mục tiêu, hoặc thay đổi hành vi mô hình theo cách không mong muốn.

Khi các function call của bạn có thể gửi email, truy vấn cơ sở dữ liệu, hoặc kích hoạt webhook, một cuộc tấn công injection không chỉ là chatbot lạc đề — đó là nguy cơ xâm phạm bảo mật.

Khi hệ thống AI vượt ra ngoài chat và bắt đầu gọi công cụ cũng như thực thi hành động, prompt injection trở thành vấn đề nghiêm trọng hơn nhiều. Một chỉ dẫn độc hại ẩn trong trang web, tài liệu, hoặc công cụ bên ngoài có thể cố gắng ghi đè hành vi hệ thống, lộ thông tin nhạy cảm, hoặc kích hoạt hành động mà mô hình không bao giờ nên làm.

Chiến lược giảm thiểu gồm một vài lớp cụ thể.

Thiết kế quy trình sao cho dữ liệu không tin cậy không bao giờ điều khiển trực tiếp hành vi của tác tử. Chỉ trích xuất các trường cấu trúc cụ thể — như enum hoặc JSON đã được xác thực — từ đầu vào bên ngoài để hạn chế rủi ro injection lan giữa các nút.

Bên cạnh đó,

luôn xác minh các function call do mô hình tạo. Bao gồm việc kiểm tra tham số, hàm được gọi, và đảm bảo cuộc gọi phù hợp với hành động dự định.

Một sự thật khó chịu:

“Prompt injection, giống như các trò lừa đảo và kỹ nghệ xã hội trên web, khó có thể bao giờ được ‘giải quyết’ triệt để.”

Đó là đánh giá của chính OpenAI. Hàm ý thực tiễn là bạn không nên thiết kế các hệ thống tác tử dùng function calling dựa trên giả định rằng mô hình sẽ luôn hành xử như mong đợi. Phòng thủ nhiều lớp — xác thực, quyền hạn phạm vi, con người trong vòng lặp đối với các thao tác hủy hoại — là tư thế duy nhất hợp lý.

Function Calling vs. Prompt Engineering — khi nào dùng cái nào

So sánh này xuất hiện liên tục. Câu trả lời ngắn: chúng giải quyết những vấn đề khác nhau, và việc nhập nhằng sẽ dẫn tới prompt bị làm quá mức trong khi function calling là đủ, hoặc lược đồ hàm dễ vỡ trong khi một system prompt được trau chuốt sẽ đơn giản hơn.

Prompt engineering liên quan tới việc soạn thảo đầu vào văn bản để định hướng tư duy nội tại của LLM — ví dụ yêu cầu nó “nghĩ từng bước”.

Nó định hình cách mô hình suy luận. Function calling, mặt khác, định hình những gì mô hình tạo ra dưới dạng đầu ra và định tuyến nó trực tiếp vào hệ thống của bạn.

Tool calling là khả năng cho phép LLM tương tác với các hệ thống bên ngoài. Trong khi bạn dùng prompt engineering để giúp mô hình quyết định nên dùng công cụ nào, tool calling là cơ chế thực sự thực thi hành động. Bạn có thể cần cả hai, nhưng chúng phục vụ những mục đích khác nhau.

Một lợi thế kỹ thuật then chốt của function calling so với đầu ra có cấu trúc dựa trên prompt:

tool calling là một khái niệm được tích hợp ngay trong mô hình. Không cần lãng phí token và công sức để giải thích với mô hình rằng nó nên trả về một định dạng cụ thể.

Khi bạn soạn prompt kiểu “trả lời của bạn ở dạng JSON với các trường X, Y và Z”, bạn đang tiêu tốn token cho các chỉ dẫn mà mô hình có thể tuân theo một cách không nhất quán. Với function calling, việc áp đặt lược đồ diễn ra ở cấp API.

Các API function-calling, hiện được hỗ trợ nguyên bản trên nhiều nền tảng LLM, cung cấp một giao diện dựa trên lược đồ chính quy cho phép xác thực dữ liệu nghiêm ngặt và tích hợp với các quy trình lập trình.

Đó là lý do thực tế để chọn nó thay vì prompt engineering cho bất kỳ dữ liệu nào phải chảy vào các hệ thống phía sau: độ tin cậy không phải tùy chọn khi bạn đưa vào sản xuất.

Kinh nghiệm thực tế: nếu đầu ra cần điều khiển một hệ thống phía sau — ghi cơ sở dữ liệu, gọi API, rẽ nhánh quyết định trong mã — hãy dùng function calling. Nếu đầu ra dành cho con người đọc, prompt engineering thường là đủ và rẻ hơn.

Những điều cần ghi nhớ

Nếu bạn muốn thử nghiệm function calling trên nhiều model khác nhau — GPT-5.4, claude opus 4.7, gemini 3.1 pro — mà không phải quản lý riêng lẻ thông tin xác thực API cho từng cái, CometAPI cung cấp cho bạn quyền truy cập tất cả qua một endpoint và một khóa duy nhất, giúp thử nghiệm xuyên model ít ma sát hơn đáng kể.

CometAPI giải quyết phần hạ tầng dư thừa:

✅ Cú pháp function calling thống nhất trên 15+ model

✅ Một API key duy nhất — không cần tài khoản riêng cho OpenAI/Anthropic/Google

✅ Tự động chuyển đổi lược đồ — viết một lần, thử ở mọi nơi

✅ Theo dõi chi phí tích hợp sẵn — so sánh mức dùng token theo thời gian thực giữa các model

Bắt đầu thử với tín dụng miễn phí → Nhận quyền truy cập