Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch.

Trả lời ngắn: Function calling là cơ chế để model tạo một đề xuất có cấu trúc gồm tên function và các tham số. Model không tự chạy function. Ứng dụng nhận đề xuất, kiểm schema, nghiệp vụ và quyền, chạy code tương ứng, rồi gửi kết quả lại để model soạn câu trả lời.

Đọc xong, bạn sẽ hiểu:

  • Function declaration khác code implementation ở điểm nào.
  • name, description, parameters và strict giữ vai trò gì.
  • Vì sao arguments đúng schema vẫn cần kiểm nghiệp vụ và quyền.

1. Function Calling là gì? Contract không phải code chạy

Ở bài Tool Calling hoạt động như thế nào? #23, bạn đã thấy model chỉ viết “phiếu gọi tool”; ứng dụng mới là bên kiểm và thực thi. Function calling là trường hợp cụ thể hơn: tool được trình bày cho model như một function có tên, mô tả và input có cấu trúc.

OpenAI mô tả function là một loại tool được định nghĩa bằng JSON Schema. Function giúp model chuyển dữ liệu có cấu trúc sang ứng dụng, còn code ứng dụng mới đọc dữ liệu hoặc thực hiện hành động. OpenAI Function Calling

a. Model nhìn declaration, ứng dụng giữ implementation

Function declaration là bản mô tả mà model nhìn thấy: function tên gì, dùng khi nào và cần những ô input nào. Implementation là code thật phía ứng dụng: gọi database, tính toán, đọc file hoặc gọi dịch vụ khác.

Hãy hình dung quầy gọi món. Tờ menu ghi tên món, kích cỡ và lựa chọn cay hay không. Menu giúp khách điền yêu cầu, nhưng menu không phải căn bếp. Căn bếp mới kiểm nguyên liệu, nấu món và trả kết quả.

Function declaration giống menu. Implementation giống căn bếp. Model đề xuất function call; ứng dụng quyết định có chạy implementation hay không.

b. Không phải việc nào cũng cần model chọn function

Nếu input đã có form cố định và flow chỉ có một bước, code thường rõ hơn. Function calling hữu ích khi người dùng nói tự nhiên theo nhiều cách; model ánh xạ câu hỏi thành function cùng parameters, còn code làm công việc thật.

2. Một function declaration tốt có những phần nào?

Ta dùng function demo chỉ đọc dữ liệu: get_delivery_quote_demo. Function nhận thành phố, cân nặng và loại dịch vụ rồi trả báo giá giả. Không có địa chỉ thật, đơn hàng thật hay thanh toán.

{
  "type": "function",
  "name":
    "get_delivery_quote_demo",
  "description":
    "Lấy báo giá giao hàng demo cho city, weight_kg và service; chỉ đọc, không tạo hoặc thanh toán đơn.",
  "parameters": {
    "type": "object",
    "properties": {
      "city": {
        "type": "string"
      },
      "weight_kg": {
        "type": "number"
      },
      "service": {
        "type": "string",
        "enum": [
          "standard",
          "express"
        ]
      }
    },
    "required": [
      "city",
      "weight_kg",
      "service"
    ],
    "additionalProperties": false
  },
  "strict": true
}

Hình 1 — Schema nói cách model đề xuất một call; implementation mới là nơi công việc thật diễn ra.

a. Name nói function nào

name nên ngắn và cụ thể. get_delivery_quote_demo nói rõ đây là thao tác lấy báo giá demo, không phải tạo hay hủy đơn. Tên mơ hồ như delivery khiến model khó chọn đúng.

b. Description nói lúc dùng và không dùng

description nói function làm gì và ranh giới quan trọng. Cụm “chỉ đọc; không tạo đơn” tách function báo giá khỏi function gây tác động. Get data quá rộng vì không nói dữ liệu nào hoặc khi nào cần gọi.

c. Parameters đặt các ô và luật input

Parameter là một ô dữ liệu function cần nhận. JSON Schema là bộ quy tắc mô tả các ô đó: kiểu dữ liệu, field bắt buộc, giới hạn và giá trị được phép.

Trong schema trên:

  • city là chuỗi; ứng dụng còn phải từ chối chuỗi rỗng.
  • weight_kg là số; ứng dụng còn phải kiểm số đó lớn hơn 0.
  • service dùng enum, tức danh sách hữu hạn gồm standard hoặc express.
  • required yêu cầu đủ ba field.
  • additionalProperties: false từ chối field lạ.

d. Strict giữ đúng hình dạng, không giữ đúng quyết định

Strict mode buộc dữ liệu AI khớp đúng mẫu. Ví dụ, mẫu luôn cần order_id; trường note vẫn xuất hiện nhưng có thể nhận null, nghĩa là chưa có ghi chú. Với OpenAI, mẫu tương thích còn phải chặn thuộc tính ngoài và đánh dấu các trường trong properties là required. OpenAI Function Calling — Strict mode

Strict giúp giảm lỗi hình dạng. Strict không chứng minh city được hỗ trợ, mức cân có hợp lệ theo bảng giá hay người dùng có quyền thực hiện hành động. Ba câu đó thuộc lớp kiểm phía ứng dụng.

3. Từ câu người dùng đến function result

Người dùng viết: “Gói 2 kg gửi thường tới Đà Nẵng hết bao nhiêu?” Ứng dụng gửi câu hỏi cùng declaration get_delivery_quote_demo cho model.

Model có thể tạo đề xuất:

{
  "call_id": "call_quote_01",
  "name":
    "get_delivery_quote_demo",
  "arguments": {
    "city": "Đà Nẵng",
    "weight_kg": 2,
    "service": "standard"
  }
}

Google mô tả vòng gồm khai báo function, gửi declaration cùng prompt, ứng dụng chạy code rồi gửi result lại model. Google Gemini Function Calling

Hình 2 — Function call mang arguments tới ứng dụng; function result mang dữ liệu hoặc lỗi trở lại model.

a. Ứng dụng kiểm trước khi gọi code

Ứng dụng kiểm ba lớp: schema, nghiệp vụ và quyền.

Nếu pass, implementation có thể trả:

{
  "call_id": "call_quote_01",
  "currency": "VND",
  "amount": 32000,
  "note": "Báo giá demo"
}

Function result là kết quả hoặc lỗi ứng dụng gửi lại model; result cần gắn đúng call mà nó trả lời.

b. Model dùng result để viết câu dễ đọc

Model có thể trả: “Theo bảng demo, gói 2 kg gửi thường tới Đà Nẵng có mức 32.000 VND.” Không được thêm ngày giao vì result không có dữ liệu đó.

c. Thiếu input thì hỏi lại

Nếu người dùng chỉ viết “Gửi tới Đà Nẵng hết bao nhiêu?”, schema thiếu weight_kg và service. Nhánh đúng là hỏi thêm, không tự đoán.

Anthropic cũng mô tả client tool theo vòng: model trả một structured tool_use, ứng dụng chạy tool rồi gửi tool_result để model trả lời tiếp. Anthropic Tool Use

4. Schema đúng vẫn chưa đủ an toàn

Một call có JSON hợp lệ và đúng schema vẫn có thể sai mục đích. Case weight_kg: 2 ở trên là hợp lệ trong demo. Một request weight_kg: 20 vẫn phải bị từ chối nếu bảng demo chỉ hỗ trợ tối đa 10 kg. city: "Atlantis" là chuỗi không rỗng nhưng không có trong danh sách phục vụ.

Hình 3 — Qua schema mới chỉ đúng hình dạng; ứng dụng còn phải kiểm nghiệp vụ, quyền và xác nhận.

a. Business validation kiểm đúng việc

Business validation là kiểm dữ liệu có hợp lệ trong nghiệp vụ thật hay không. Schema nói weight_kg là số dương; business rule có thể nói dịch vụ express chỉ nhận tối đa 10 kg ở một khu vực cụ thể.

Hai lớp không thay nhau. Schema kiểm tuổi là số; business validation kiểm chương trình có nhận nhóm tuổi đó hay không.

b. Quyền và xác nhận kiểm được phép

Function đọc báo giá có thể dùng quyền hẹp. Function create_delivery_order lưu dữ liệu nên cần preview, xác nhận, quyền tối thiểu và chống gọi trùng. strict: true không thay authorization.

c. Description tốt vẫn không phải security boundary

Description giúp model chọn đúng hơn, nhưng không phải cổng bảo mật. Rủi ro phụ thuộc implementation và quyền credential; security phải nằm trong code và hạ tầng.

d. Checklist trước khi đưa function vào agent

  1. Function chỉ làm một việc rõ hay đang gom quá nhiều hành động?
  2. Name và description có nói cả mục đích lẫn ranh giới không?
  3. Parameters có kiểu hẹp, enum, required và chặn field lạ không?
  4. Ứng dụng có business validation và allowlist không?
  5. Hành động gây tác động có preview, xác nhận và chống chạy trùng không?
  6. Lỗi có mã rõ, retry giới hạn và không làm lộ secret không?

5. Bài tập 15 phút: sửa một function contract

Dùng giấy hoặc Markdown, không cần API key. Bắt đầu từ contract yếu: tên delivery, description Get data, ba parameters đều nhận chuỗi bất kỳ.

a. Mẫu đối chiếu đã điền

Điểm kiểm Schema yếu Schema đã sửa
Tên delivery get_delivery_quote_demo
Mục đích Get data Báo giá demo, chỉ đọc
Thành phố chuỗi bất kỳ chuỗi; app kiểm không rỗng
Cân nặng chuỗi số; app kiểm lớn hơn 0
Dịch vụ chuỗi bất kỳ standard hoặc express
Field lạ nhận từ chối

b. Tự kiểm ba tình huống

  1. city: "Đà Nẵng", weight_kg: 2, service: "standard" → qua schema, chuyển sang business validation.
  2. city: "", weight_kg: -2, service: "fast" → schema chặn service; app còn phải chặn thành phố rỗng và cân nặng âm.
  3. Call có thêm create_order: true → dừng vì field lạ không thuộc contract.

Đổi yêu cầu thành “tạo đơn luôn”. Kết luận: không dùng function báo giá read-only; cần function, quyền và bước xác nhận khác.

c. Kết quả đạt

Sau 15 phút, bạn cần giải thích được từng field dùng để làm gì và lỗi nào schema không thể chặn. Chưa gửi request thật, chưa dùng địa chỉ thật. Mục tiêu là hỏi: model được đề xuất gì, code kiểm gì, quyền nằm ở đâu?

6. Tổng kết: schema rõ, code kiểm, quyền hẹp

Function calling giúp biến câu tự nhiên thành tên function cùng arguments có cấu trúc. Chất lượng không đến từ JSON đẹp một mình. Declaration phải rõ, schema phải hẹp, implementation phải kiểm dữ liệu và quyền phải phù hợp tác động.

a. Năm ý chính

  • Function calling để model đề xuất function và arguments; ứng dụng mới thực thi code.
  • Function declaration là contract model nhìn thấy, còn implementation nằm phía ứng dụng.
  • Name, description và parameters càng rõ thì model càng dễ tạo call đúng ý.
  • Strict mode giữ arguments bám schema, nhưng không thay business validation hay authorization.
  • Function gây tác động cần quyền tối thiểu, preview, xác nhận và chống chạy trùng.

b. Câu hỏi tự kiểm tra

  • Function declaration khác implementation như thế nào?
  • enum giúp thu hẹp parameter bằng cách nào?
  • Vì sao call đúng strict schema vẫn có thể bị từ chối?
  • Khi nào nên dùng code thường thay vì function calling?

c. Gợi ý đáp án

Xem gợi ý câu 1

Declaration mô tả function cho model; implementation là code thật ứng dụng kiểm và chạy. → xem mục 1.

Xem gợi ý câu 2

Enum chỉ cho phép một giá trị thuộc danh sách hữu hạn đã định nghĩa. → xem mục 2.

Xem gợi ý câu 3

Schema chỉ kiểm hình dạng; business validation và quyền còn có thể không đạt. → xem mục 4.

Xem gợi ý câu 4

Dùng code thường khi flow cố định, input đã có cấu trúc và không cần model chọn function. → xem mục 1.

d. Thuật ngữ cần nhớ

Thuật ngữ Giải thích ngắn
Function calling Cơ chế model đề xuất function và arguments có cấu trúc.
Function declaration Bản mô tả function model được nhìn thấy.
Implementation Code thật phía ứng dụng thực hiện công việc.
Parameter Ô dữ liệu function cần nhận.
JSON Schema Quy tắc mô tả hình dạng input.
Enum Danh sách hữu hạn các giá trị hợp lệ.
Strict mode Chế độ ép arguments bám schema tương thích.
Business validation Kiểm dữ liệu có đúng nghiệp vụ thật.
Function result Kết quả hoặc lỗi gửi lại model.

e. Nguồn tham khảo

Xem lại Tool Calling hoạt động như thế nào? #23 nếu còn nhầm model với executor. Bài tiếp theo: MCP (Model Context Protocol) #25; liên kết sẽ được thêm khi canonical tồn tại.

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch. Mọi function có tác động đều cần kiểm dữ liệu, quyền và xác nhận trước khi thực thi.