Menu
Học tập
Khóa học Lộ trình nghề nghiệp Roadmap BA → CPO BA → Product Manager Tài liệu & Sách
Cộng đồng
Cộng đồng Interview Questions
Công cụ
Phân tích CV Theo dõi ứng tuyển Hiring Pipeline Luyện phỏng vấn Tối ưu LinkedIn Đàm phán lương
Tài khoản
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Bài 16 — Function Calling và Tool Use

AI Product Manager Bài 16/60

Mở đầu — vì sao bài này quan trọng

Hãy thử hỏi một mô hình ngôn ngữ thuần túy (LLM) một câu rất đơn giản: "Bây giờ 1 USD đổi được bao nhiêu VND?". Câu trả lời bạn nhận được thường là một con số nghe có vẻ hợp lý — ví dụ "khoảng 24.500 VND" — nhưng đó là con số mô hình nhớ từ dữ liệu huấn luyện cách đây nhiều tháng, chứ không phải tỷ giá thật của hôm nay. Tệ hơn, mô hình nói ra con số đó với giọng điệu cực kỳ tự tin. Đây chính là giới hạn căn bản của LLM: nó giỏi suy luận và diễn đạt ngôn ngữ, nhưng nó không có khả năng biết những gì xảy ra ngoài thế giới thực, không tính toán chính xác, và không tự truy vấn được cơ sở dữ liệu của bạn.

Function Calling (gọi hàm) — hay còn gọi là Tool Use (sử dụng công cụ) — là cây cầu nối giữa khả năng suy luận của LLM và khả năng hành động trong thế giới thật. Đây là một trong những kỹ thuật quan trọng nhất biến một con chatbot "biết nói chuyện" thành một sản phẩm AI thực sự có ích: tra cứu được tỷ giá thật, đặt được lịch hẹn, truy vấn được tồn kho, gửi được email. Với vai trò một AI Product Manager, nếu bạn không hiểu rõ Function Calling, bạn sẽ không thể thiết kế được những sản phẩm AI vượt qua giới hạn của một hộp chat đơn thuần. Bài này sẽ giúp bạn nắm vững cơ chế, ranh giới trách nhiệm giữa LLM và hệ thống của bạn, cùng cách thiết kế tool sao cho mô hình dùng đúng.

Khái niệm cốt lõi

Function Calling thực chất là gì

Một hiểu lầm phổ biến cần xóa bỏ ngay: LLM không tự thực thi hàm. Khi bạn bật Function Calling, mô hình không hề chạy code, không gọi API, không đụng vào database của bạn. Việc duy nhất mô hình làm là: đọc câu hỏi của người dùng, nhìn vào danh sách các "công cụ" mà bạn khai báo, rồi quyết định công cụ nào nên được gọi và điền các tham số phù hợp dưới dạng dữ liệu có cấu trúc (thường là JSON).

Nói cách khác, output của bước Function Calling không phải là kết quả, mà là một yêu cầu: "Tôi muốn gọi hàm get_exchange_rate với tham số {from: 'USD', to: 'VND'}". Phần code của bạn — phía backend — mới là nơi thực sự nhận yêu cầu đó, chạy hàm, gọi API ngân hàng, lấy về tỷ giá thật, rồi đưa kết quả ngược lại cho mô hình. Hiểu đúng ranh giới này là chìa khóa: LLM là bộ não điều phối, hệ thống của bạn là đôi tay thực thi.

Vì sao LLM cần đến tool

Có bốn nhóm việc mà LLM thuần làm rất kém, và đây chính là lý do Function Calling tồn tại:

  • Thông tin thời gian thực: tỷ giá hối đoái, thời tiết Đà Nẵng hôm nay, giá cổ phiếu, trạng thái đơn hàng. Mô hình bị "đóng băng" tại thời điểm huấn luyện nên không thể biết.
  • Tính toán chính xác: LLM dự đoán token tiếp theo theo xác suất, nên với phép nhân nhiều chữ số hay tính lãi kép, nó thường sai. Một máy tính (calculator tool) cho kết quả đúng tuyệt đối.
  • Truy vấn dữ liệu riêng: thông tin tồn kho, lịch sử mua hàng của khách, danh sách nhân viên — những thứ chỉ nằm trong database của bạn và mô hình chưa từng thấy.
  • Thực hiện hành động (side effect): gửi email, tạo ticket, đặt lịch, cập nhật trạng thái đơn. Đây là những việc thay đổi thế giới thật, chứ không chỉ trả lời.

Tool schema — bản hợp đồng giữa bạn và mô hình

Để mô hình biết có công cụ nào và dùng ra sao, bạn cung cấp cho nó một bản mô tả công cụ gọi là tool schema. Một schema điển hình gồm ba phần: tên hàm (name), mô tả công năng (description), và danh sách tham số kèm kiểu dữ liệu (thường theo chuẩn JSON Schema). Ví dụ:

{
  "name": "get_exchange_rate",
  "description": "Lấy tỷ giá hối đoái thời gian thực giữa hai loại tiền tệ",
  "parameters": {
    "type": "object",
    "properties": {
      "from_currency": { "type": "string", "description": "Mã tiền nguồn, ví dụ USD" },
      "to_currency": { "type": "string", "description": "Mã tiền đích, ví dụ VND" }
    },
    "required": ["from_currency", "to_currency"]
  }
}

Điều quan trọng cần khắc cốt ghi tâm: phần description không phải để cho con người đọc, mà là để cho mô hình đọc. Mô hình dựa hoàn toàn vào mô tả này để quyết định khi nào dùng tool và điền tham số gì. Một mô tả mơ hồ sẽ khiến mô hình gọi sai tool hoặc gọi nhầm lúc. Mô tả tốt giống như viết tài liệu API rõ ràng cho một lập trình viên mới — chỉ khác là "lập trình viên" ở đây là LLM.

Vòng lặp tool calling (tool-use loop)

Một lượt sử dụng công cụ đầy đủ thường gồm các bước lặp:

  • Người dùng đặt câu hỏi.
  • Mô hình nhìn câu hỏi + danh sách tool, quyết định gọi tool nào (hoặc không gọi gì cả nếu tự trả lời được).
  • Hệ thống của bạn nhận yêu cầu, thực thi hàm, lấy kết quả.
  • Bạn gửi kết quả đó ngược lại cho mô hình.
  • Mô hình đọc kết quả, có thể gọi tiếp tool khác, hoặc tổng hợp thành câu trả lời tự nhiên cho người dùng.
Vòng lặp này có thể chạy nhiều lần trong một lượt hội thoại — đây cũng chính là nền tảng cho các AI Agent phức tạp hơn ở các bài sau.

Tình huống thực tế

Tình huống 1 — Tiki và trợ lý tra cứu đơn hàng

Giả sử đội sản phẩm tại một sàn thương mại điện tử lớn như Tiki muốn xây trợ lý chăm sóc khách hàng. Khách gõ: "Đơn TIKI8829301 của tôi giờ tới đâu rồi?". Nếu chỉ dùng LLM thuần, mô hình sẽ bịa ra một câu vô nghĩa vì nó không hề biết đơn này tồn tại. Đội PM thiết kế một tool track_order(order_id) trỏ vào hệ thống logistics nội bộ.

Khi khách hỏi, mô hình trích xuất order_id = "TIKI8829301", gọi tool, backend truy vấn và trả về {status: "đang giao", eta: "2026-06-28", location: "kho Sóng Thần"}. Mô hình nhận dữ liệu thật này rồi diễn đạt: "Đơn của bạn đang được giao, dự kiến tới tay vào ngày mai 28/6, hiện ở kho Sóng Thần nhé." Bài học: giá trị thực sự không nằm ở việc mô hình "thông minh", mà ở việc nó biết khi nào cần gọi đúng tool và trích xuất đúng mã đơn từ câu nói tự nhiên của khách.

Tình huống 2 — Startup fintech và bài toán tính toán chính xác

Một startup fintech tại TP.HCM xây trợ lý tư vấn vay tiêu dùng. Khách hỏi: "Vay 50 triệu, lãi 1,5%/tháng, trả trong 18 tháng thì tổng lãi bao nhiêu?". Đội kỹ thuật ban đầu để LLM tự tính — và phát hiện ra mô hình đưa ra các con số lệch nhau mỗi lần hỏi, có lần sai tới vài triệu đồng. Trong lĩnh vực tài chính, sai số kiểu này là không thể chấp nhận, thậm chí rủi ro pháp lý.

Giải pháp: tạo tool calculate_loan_interest(principal, monthly_rate, months) chạy đúng công thức trong code. Mô hình chỉ làm nhiệm vụ nó giỏi — hiểu câu hỏi tiếng Việt và trích ba con số — còn phép tính do code lo, cho kết quả chính xác tuyệt đối. Bài học: hãy giao cho LLM phần "hiểu ngôn ngữ" và giao cho code phần "tính toán xác định". Đừng bao giờ tin tưởng LLM với những con số mà sai một chút cũng gây hậu quả.

Tình huống 3 — Khi tool description tồi gây gọi nhầm

Một đội sản phẩm SaaS xây trợ lý có hai tool: search_documents (tìm trong kho tài liệu nội bộ) và web_search (tìm trên internet). Ban đầu cả hai mô tả đều cụt lủn: "tìm kiếm thông tin". Kết quả là mô hình liên tục gọi web_search cho cả những câu hỏi về quy trình nội bộ công ty, làm lộ truy vấn ra ngoài và trả lời sai.

Sau khi sửa mô tả thành rõ ràng — search_documents: "Tìm trong tài liệu nội bộ, quy trình, chính sách của công ty. Dùng cho mọi câu hỏi về hoạt động bên trong tổ chức" và web_search: "Chỉ dùng cho thông tin công khai ngoài internet, tin tức, kiến thức chung" — tỷ lệ gọi đúng tool tăng vọt. Bài học: chất lượng description quyết định trực tiếp hành vi của mô hình. Phần lớn lỗi "AI dùng sai công cụ" thực ra là lỗi mô tả của con người, không phải lỗi của mô hình.

Hướng dẫn từng bước

Nếu bạn là PM đang triển khai Function Calling cho sản phẩm, đây là quy trình thực tế:

  • Liệt kê các giới hạn của LLM thuần trong use case của bạn. Chỗ nào cần dữ liệu thời gian thực, tính toán chính xác, truy vấn nội bộ, hay thực hiện hành động — đó là chỗ cần tool. Đừng tạo tool cho việc mà LLM tự làm tốt.
  • Định nghĩa từng tool như một hợp đồng. Đặt tên hàm rõ nghĩa (get_order_status tốt hơn func1). Viết description như viết cho một đồng nghiệp mới, nêu rõ khi nào nên dùng và khi nào không nên.
  • Thiết kế tham số chặt chẽ. Dùng kiểu dữ liệu cụ thể, đánh dấu trường bắt buộc, dùng enum nếu giá trị giới hạn (ví dụ status chỉ nhận pending | shipped | delivered). Tham số càng rõ, mô hình càng ít điền sai.
  • Xử lý phía backend cẩn thận. Code của bạn phải validate lại tham số mô hình gửi — đừng tin tuyệt đối. Mô hình có thể bịa ra một order_id không tồn tại; backend cần trả lỗi rõ ràng để mô hình hiểu và xin lại thông tin.
  • Trả kết quả về cho mô hình một cách có cấu trúc. Trả JSON gọn gàng, kèm cả trường hợp lỗi ({error: "không tìm thấy đơn"}) để mô hình diễn đạt lại cho người dùng một cách lịch sự.
  • Đo lường và quan sát. Log lại: mô hình gọi tool nào, bao nhiêu lần, có gọi nhầm không, tỷ lệ điền tham số sai. Đây là dữ liệu vàng để cải thiện schema.

Lỗi thường gặp & mẹo

  • Lỗi: tưởng LLM tự chạy hàm. Nhớ rằng mô hình chỉ đề xuất gọi hàm; việc thực thi và bảo mật hoàn toàn nằm ở phía bạn. Đừng bao giờ để mô hình "tự" thực hiện hành động nhạy cảm mà không có lớp kiểm soát.
  • Lỗi: description viết cho người, không viết cho mô hình. Mô tả phải đủ chi tiết để mô hình phân biệt được tool này với tool khác. Tránh các mô tả chung chung như "xử lý dữ liệu".
  • Lỗi: nhồi quá nhiều tool. Khi bạn khai báo 30-40 tool cùng lúc, mô hình dễ rối và chọn nhầm. Mẹo: nhóm tool theo ngữ cảnh, chỉ cung cấp những tool liên quan đến phiên hiện tại.
  • Lỗi: không xử lý trường hợp mô hình không gọi tool nào. Đôi khi mô hình tự trả lời mà lẽ ra nên gọi tool. Mẹo: với câu hỏi bắt buộc cần dữ liệu thật, có thể ép mô hình phải dùng tool (tool choice = required).
  • Mẹo bảo mật: mọi tham số mô hình sinh ra đều là "dữ liệu chưa tin cậy". Luôn validate, escape, và phân quyền ở backend như thể đó là input từ người dùng cuối — vì bản chất nó bị ảnh hưởng bởi input người dùng.
  • Mẹo về độ trễ: mỗi vòng lặp tool calling tốn thêm một lượt gọi mô hình. Với những tác vụ cần nhiều tool, hãy cân nhắc chạy song song các tool độc lập để giảm thời gian chờ của người dùng.

Bài tập thực hành

  • Phân loại use case. Lấy một sản phẩm AI bạn quan tâm (trợ lý ngân hàng, app đặt đồ ăn...). Liệt kê 5 câu hỏi người dùng có thể hỏi, rồi đánh dấu câu nào LLM thuần trả lời được, câu nào bắt buộc cần tool.
  • Viết tool schema. Thiết kế đầy đủ schema (name, description, parameters) cho một tool check_inventory(product_id, store_location) của một chuỗi bán lẻ. Đặc biệt chăm chút phần description để mô hình biết chính xác khi nào nên gọi.
  • Phát hiện lỗi mô tả. Cho hai tool send_email và send_notification với mô tả giống hệt nhau là "gửi thông báo cho người dùng". Hãy viết lại mô tả của cả hai để mô hình không bao giờ gọi nhầm.
  • Thiết kế xử lý lỗi. Vẽ luồng xử lý khi mô hình gọi track_order với một mã đơn không tồn tại: backend trả gì, mô hình nên nói gì với khách.

Tóm tắt

Function Calling / Tool Use là cơ chế cho phép LLM vượt qua bốn giới hạn cốt lõi của nó: thiếu thông tin thời gian thực, tính toán không chính xác, không truy vấn được dữ liệu riêng, và không thực hiện được hành động. Điểm mấu chốt cần nhớ là mô hình không tự chạy hàm — nó chỉ quyết định gọi hàm nào và điền tham số gì, còn hệ thống của bạn mới là nơi thực thi. Vì vậy, ranh giới trách nhiệm rất rõ ràng: LLM lo phần hiểu ngôn ngữ và điều phối, code của bạn lo phần thực thi, bảo mật và độ chính xác.

Chất lượng của một tính năng dùng tool phụ thuộc rất lớn vào chất lượng tool schema — đặc biệt là phần description, thứ được viết cho mô hình đọc chứ không phải cho con người. Là một AI Product Manager, kỹ năng thiết kế tool rõ ràng, xử lý lỗi chặt chẽ và đo lường hành vi gọi tool sẽ là nền tảng để bạn xây những sản phẩm AI thực sự hữu ích, đáng tin cậy — và là bước đệm trực tiếp cho các kiến trúc AI Agent phức tạp hơn ở phần sau của khóa học.

Trước Tiếp