Các nguyên tắc thiết kế hệ thống AI đàm thoại trong ElevenLabs

Việc thiết lập câu lệnh (prompt) hiệu quả sẽ giúp ElevenLabs Agents chuyển từ phong cách máy móc sang tự nhiên, sống động như người thật.

Câu lệnh hệ thống (system prompt) đóng vai trò là bản thiết kế về tính cách và các quy tắc vận hành cho AI agent của bạn. Trong môi trường doanh nghiệp, câu lệnh này thường rất chi tiết - xác định vai trò, mục tiêu, các công cụ được phép sử dụng, hướng dẫn từng bước cho những tác vụ cụ thể và các giới hạn quy định những điều agent không được phép làm. Cách bạn cấu trúc câu lệnh này ảnh hưởng trực tiếp đến độ tin cậy của hệ thống.

Câu lệnh hệ thống kiểm soát hành vi hội thoại và phong cách phản hồi, nhưng không kiểm soát cơ chế luồng hội thoại (như quy tắc luân phiên lượt nói) hay các cài đặt của agent (như ngôn ngữ hỗ trợ). Những khía cạnh này được quản lý ở cấp độ nền tảng.

Các nguyên tắc cơ bản về kỹ thuật thiết lập câu lệnh (prompt engineering)

Câu lệnh hệ thống đóng vai trò là bản thiết kế về tính cách và các quy tắc vận hành cho AI agent của bạn. Trong môi trường doanh nghiệp, câu lệnh này thường rất chi tiết - xác định vai trò, mục tiêu, các công cụ được phép sử dụng, hướng dẫn từng bước cho những tác vụ cụ thể và các giới hạn quy định những điều agent không được phép làm. Cách bạn cấu trúc câu lệnh này ảnh hưởng trực tiếp đến độ tin cậy của hệ thống.

Các nguyên tắc sau đây tạo nên nền tảng cho kỹ thuật thiết lập câu lệnh đạt chuẩn triển khai thực tế:

Phân chia hướng dẫn thành các phần rõ ràng

Việc chia nhỏ hướng dẫn thành các phần riêng biệt với tiêu đề định dạng Markdown giúp mô hình ưu tiên và diễn giải chúng một cách chính xác. Hãy sử dụng khoảng trắng và ngắt dòng để phân tách các hướng dẫn.

Tại sao điều này quan trọng đối với độ tin cậy: Các mô hình được tinh chỉnh để đặc biệt chú ý đến một số tiêu đề nhất định (đặc biệt là # Guardrails), đồng thời ranh giới rõ ràng giữa các phần giúp ngăn chặn tình trạng "nhiễu chéo", nơi quy tắc của ngữ cảnh này vô tình ảnh hưởng đến ngữ cảnh khác.

Cách tiếp cận kém hiệu quả

Bạn là nhân viên dịch vụ khách hàng. Hãy lịch sự và nhiệt tình hỗ trợ. Tuyệt đối không chia sẻ dữ liệu nhạy cảm. Bạn có thể tra cứu đơn hàng và xử lý hoàn tiền. Luôn xác minh danh tính trước tiên. Giữ câu trả lời ngắn gọn (dưới 3 câu) trừ khi người dùng yêu cầu thông tin chi tiết. 

Cách tiếp cận được khuyến nghị

# Tính cách

Bạn là nhân viên dịch vụ khách hàng của Acme Corp. Bạn lịch sự, làm việc hiệu quả và luôn chú trọng tìm giải pháp.

# Mục tiêu

Hỗ trợ khách hàng giải quyết vấn đề nhanh chóng bằng cách tra cứu đơn hàng và xử lý hoàn tiền khi phù hợp.

# Nguyên tắc

Tuyệt đối không chia sẻ dữ liệu nhạy cảm của khách hàng giữa các cuộc hội thoại.
Luôn xác minh danh tính khách hàng trước khi truy cập thông tin tài khoản.

# Giọng điệu

Phản hồi ngắn gọn (dưới 3 câu) trừ khi người dùng yêu cầu giải thích chi tiết.

Mỗi hướng dẫn cần ngắn gọn, rõ ràng và tập trung vào hành động cụ thể. Loại bỏ các từ ngữ thừa thãi và chỉ nêu lại những thông tin thiết yếu để mô hình thực hiện đúng nhiệm vụ.

Hãy diễn đạt ngắn gọn nhất có thể

Tại sao điều này quan trọng đối với độ tin cậy: Các hướng dẫn súc tích giúp giảm thiểu sự mơ hồ và mức tiêu thụ token. Mỗi từ ngữ thừa thãi đều là một nguồn tiềm ẩn gây hiểu lầm.

Cách tiếp cận kém hiệu quả hơn

# Giọng điệu

Khi giao tiếp với khách hàng, bạn nên cố gắng tỏ ra thật thân thiện và dễ gần, đảm bảo cách nói chuyện tự nhiên và gần gũi như đang trò chuyện với bạn bè, nhưng vẫn giữ được phong thái chuyên nghiệp đại diện cho công ty.

Cách tiếp cận được khuyến nghị

# Giọng điệu

Sử dụng giọng điệu thân thiện, gần gũi như đang trò chuyện nhưng vẫn giữ được sự chuyên nghiệp.

Nếu bạn cần agent duy trì một giọng điệu cụ thể, hãy xác định rõ ràng và súc tích trong phần # Personality (Tính cách) hoặc # Tone (Giọng điệu). Tránh lặp lại các hướng dẫn về giọng điệu ở nhiều nơi trong câu lệnh (prompt).

Nhấn mạnh các hướng dẫn quan trọng

Làm nổi bật các bước quan trọng bằng cách thêm cụm từ “Bước này rất quan trọng" vào cuối dòng. Việc lặp lại 1-2 hướng dẫn quan trọng nhất hai lần trong câu lệnh có thể giúp củng cố các hướng dẫn đó.

Tại sao điều này quan trọng đối với độ tin cậy: Trong các câu lệnh phức tạp, những mô hình có thể ưu tiên ngữ cảnh gần đây hơn là các hướng dẫn đã đưa ra trước đó. Việc nhấn mạnh và lặp lại giúp đảm bảo các quy tắc quan trọng không bị bỏ sót.

Cách tiếp cận kém hiệu quả hơn

# Mục tiêu

Xác minh danh tính khách hàng trước khi truy cập tài khoản của họ.
Tra cứu thông tin chi tiết đơn hàng và cung cấp thông tin cập nhật về trạng thái.
Xử lý các yêu cầu hoàn tiền khi đủ điều kiện.

Cách tiếp cận được khuyến nghị

# Mục tiêu

Xác minh danh tính khách hàng trước khi truy cập vào tài khoản của họ. Đây là bước quan trọng.
Tra cứu thông tin chi tiết đơn hàng và cập nhật trạng thái đơn hàng.
Xử lý các yêu cầu hoàn tiền khi đủ điều kiện.

# Nguyên tắc bắt buộc

Tuyệt đối không truy cập thông tin tài khoản nếu chưa xác minh danh tính khách hàng. Đây là bước quan trọng.

Chuẩn hóa văn bản

Các mô hình chuyển đổi văn bản thành giọng nói (TTS), đặc biệt là những mô hình tốc độ cao, hoạt động hiệu quả nhất khi tạo giọng nói từ văn bản dạng chữ cái. Do đó, các chữ số và ký hiệu như ”@” hoặc ”£” dễ gây ra lỗi phát âm hoặc hiện tượng "ảo giác giọng nói" (voice hallucinations).

Để khắc phục vấn đề này, hãy chuẩn hóa văn bản không phải dạng chữ cái thành dạng từ ngữ trước khi gửi đến mô hình TTS (ví dụ: 123 -> one-hundred and twenty three, john@gmail.com -> john at gmail dot com), đồng thời cho phép bạn lựa chọn giữa các chiến lược chuẩn hóa khác nhau với những ưu và nhược điểm riêng.

Các chiến lược chuẩn hóa

ElevenLabs hỗ trợ hai chiến lược chuẩn hóa thông qua cấu hình agent text_normalisation_type:

system_prompt (mặc định) - Thêm hướng dẫn vào câu lệnh hệ thống (system prompt), yêu cầu LLM viết các con số và ký hiệu thành từ ngữ trước khi văn bản được gửi đến mô hình TTS.

• Không phát sinh thêm độ trễ.
• Các mô hình ngôn ngữ lớn (LLM) đôi khi có thể không thực hiện chuẩn hóa văn bản một cách chính xác.
• Các bản transcript hiển thị đầy đủ nội dung dưới dạng từ ngữ (ví dụ: viết là “one thousand dollars” thay vì “$1,000”).

Nếu bạn không muốn sử dụng bộ chuẩn hóa TTS mà vẫn thấy LLM thỉnh thoảng phản hồi bằng văn bản chưa được chuẩn hóa, hãy cân nhắc chuyển sang một LLM thông minh hơn hoặc bổ sung các hướng dẫn chuẩn hóa vào câu lệnh hệ thống (system prompt).

elevenlabs - Sử dụng bộ chuẩn hóa TTS của ElevenLabs để chuẩn hóa văn bản sau khi LLM tạo ra nội dung và trước khi văn bản đó được chuyển đến mô hình TTS.

• Đáng tin cậy hơn so với phương pháp chuẩn hóa dựa trên LLM
• Không làm thay đổi system prompt (câu lệnh hệ thống)
• Văn bản giữ được định dạng tự nhiên với các ký hiệu và con số (ví dụ: “$1,000”)
• Gây ra độ trễ nhỏ

Nếu khả năng đọc của văn bản là yếu tố quan trọng đối với trường hợp sử dụng của bạn, hãy cân nhắc dùng bộ chuẩn hóa elevenlabs. Nó giúp văn bản gọn gàng, giữ nguyên các ký hiệu và con số tự nhiên mà vẫn đảm bảo âm thanh được phát ra chính xác.

Bạn có thể tìm thấy cấu hình này trên nền tảng của ElevenLabs trong tab Agent bằng cách nhấp vào biểu tượng bánh răng ở mục Voices để mở bảng cài đặt giọng nói chung, sau đó cấu hình ở phần cuối trang.

Dữ liệu có cấu trúc cho đầu vào của công cụ

Khi sử dụng cài đặt chuẩn hóa system_prompt, LLM sẽ viết các ký hiệu và con số dưới dạng từ ngữ trong phản hồi (ví dụ: "john at gmail dot com" thay vì "john@gmail.com"). Văn bản chuyển đổi từ giọng nói sang văn bản cũng có thể ở dạng không chuẩn. Điều này có nghĩa là khi sử dụng các thông tin này làm tham số cho các lệnh gọi công cụ, LLM có thể sẽ sử dụng phiên bản chưa được chuẩn hóa có trong ngữ cảnh cuộc trò chuyện.

Nếu tham số của công cụ yêu cầu giá trị được định dạng chính xác (ví dụ: john@gmail.com chứ không phải john at gmail dot com), LLM cần phải biết điều này. Hãy đưa định dạng mong muốn trực tiếp vào phần mô tả tham số công cụ kèm theo ví dụ.

Ít hiệu quả: mô tả tham số mơ hồ

## Các tham số của công cụ `lookupAccount`

- `email` (bắt buộc): "Email của người dùng."
- `phone` (bắt buộc): "Số điện thoại của người dùng."
- `confirmation_code` (bắt buộc): "Mã xác nhận của người dùng."

Khuyên dùng: định dạng rõ ràng trong mô tả tham số

## Các tham số của công cụ `lookupAccount`

- `email` (bắt buộc): "Email của người dùng theo định dạng chuẩn, ví dụ: 'john@gmail.com'."
- `phone` (bắt buộc): "Số điện thoại của người dùng chỉ bao gồm các chữ số, ví dụ: '5551234567'."
- `confirmation_code` (bắt buộc): "Mã xác nhận của người dùng dưới dạng chuỗi ký tự chữ và số liền nhau, không có khoảng trắng, ví dụ: 'ABC123'."

Dành riêng một phần cho các quy tắc kiểm soát

Liệt kê tất cả các quy tắc bắt buộc mà mô hình phải tuân thủ trong một phần riêng biệt có tiêu đề # Guardrails. Các mô hình được tinh chỉnh để đặc biệt chú ý đến tiêu đề này.

Tại sao điều này quan trọng đối với độ tin cậy: Các quy tắc kiểm soát giúp ngăn chặn phản hồi không phù hợp và đảm bảo tuân thủ chính sách. Việc tập hợp chúng vào một phần riêng biệt giúp việc kiểm tra và cập nhật trở nên dễ dàng hơn.

Cách tiếp cận được khuyến nghị

# Các quy tắc kiểm soát

Không bao giờ chia sẻ dữ liệu khách hàng giữa các cuộc hội thoại hoặc tiết lộ thông tin tài khoản nhạy cảm khi chưa xác minh đầy đủ.
Không bao giờ xử lý hoàn tiền trên 500 USD nếu chưa có sự phê duyệt của cấp quản lý.
Không bao giờ cam kết về ngày giao hàng nếu chưa được xác nhận trong hệ thống đơn hàng.
Hãy thừa nhận khi bạn không biết câu trả lời thay vì đoán mò.
Nếu khách hàng có thái độ thô lỗ hoặc xúc phạm, hãy lịch sự kết thúc cuộc hội thoại và đề nghị chuyển vấn đề lên cấp quản lý.

Cấu hình công cụ để đảm bảo độ tin cậy

Các agent có khả năng xử lý quy trình giao dịch có thể mang lại hiệu quả rất cao. Để làm được điều này, chúng cần được trang bị các công cụ cho phép thực hiện thao tác trên những hệ thống khác hoặc truy xuất dữ liệu thời gian thực từ các hệ thống đó.

Cách bạn mô tả các công cụ có sẵn cho agent cũng quan trọng không kém gì cấu trúc câu lệnh (prompt). Các định nghĩa công cụ rõ ràng, tập trung vào hành động sẽ giúp mô hình gọi công cụ chính xác và xử lý lỗi một cách suôn sẻ.

Mô tả công cụ một cách chính xác với các tham số chi tiết

Khi tạo một công cụ, hãy thêm mô tả cho tất cả các tham số. Việc này giúp mô hình ngôn ngữ lớn (LLM) xây dựng các lệnh gọi công cụ một cách chính xác.

Mô tả công cụ: “Tra cứu trạng thái đơn hàng của khách hàng dựa trên mã đơn hàng và trả về trạng thái hiện tại, ngày giao hàng dự kiến ​​cùng mã vận đơn”.

Mô tả tham số:

• order_id (bắt buộc): “Mã định danh duy nhất của đơn hàng, được định dạng dưới dạng chuỗi ký tự (ví dụ: ‘ORD123456’)”
• include_history (tùy chọn): “Nếu là true, sẽ trả về toàn bộ lịch sử đơn hàng bao gồm các thay đổi về trạng thái”

Tại sao điều này quan trọng đối với độ tin cậy: Các mô tả tham số đóng vai trò như tài liệu hướng dẫn ngay trong code dành cho mô hình. Chúng làm rõ các yêu cầu về định dạng, phân biệt giữa trường bắt buộc và trường tùy chọn, cũng như những giá trị hợp lệ.

Giải thích thời điểm và cách sử dụng từng công cụ trong câu lệnh hệ thống

Hãy xác định rõ ràng trong system prompt về thời điểm và cách thức sử dụng từng công cụ. Đừng chỉ dựa vào phần mô tả công cụ - hãy cung cấp ngữ cảnh sử dụng và logic về trình tự thực hiện.

Cách tiếp cận được khuyến nghị

# Các công cụ

Bạn có quyền truy cập vào các công cụ sau:

## `getOrderStatus`

Sử dụng công cụ này khi khách hàng hỏi về đơn hàng của họ. Luôn gọi công cụ này trước khi cung cấp thông tin đơn hàng - tuyệt đối không dựa vào trí nhớ hay phỏng đoán.

**Khi nào cần sử dụng:**

- Khách hàng hỏi "Đơn hàng của tôi đang ở đâu?"
- Khách hàng cung cấp mã số đơn hàng
- Khách hàng hỏi về thời gian giao hàng dự kiến

**Cách sử dụng:**

1. Lấy mã đơn hàng (order ID) từ khách hàng
2. Gọi `getOrderStatus` với mã đơn hàng đó
3. Trình bày kết quả cho khách hàng bằng ngôn ngữ tự nhiên

**Xử lý lỗi:**
Nếu công cụ trả về kết quả "Order not found" (Không tìm thấy đơn hàng), hãy yêu cầu khách hàng kiểm tra lại mã số đơn hàng và thử lại.

## `processRefund`

Chỉ sử dụng công cụ này sau khi đã xác minh:

1. Danh tính khách hàng đã được xác nhận
2. Đơn hàng đủ điều kiện hoàn tiền (trong vòng 30 ngày, chưa được hoàn tiền trước đó)
3. Số tiền hoàn lại dưới 500 USD (chuyển cho cấp quản lý nếu trên 500 USD)

**Thông tin cần thiết trước khi gọi:**

- Mã đơn hàng (từ `getOrderStatus`)
- Mã lý do hoàn tiền
- Sự xác nhận của khách hàng

Bước này rất quan trọng: Luôn xác nhận chi tiết hoàn tiền với khách hàng trước khi gọi công cụ này.

Quy định rõ định dạng mong muốn trong phần mô tả tham số công cụ

Khi các công cụ yêu cầu các định dạng dữ liệu cụ thể (email, số điện thoại, code), hãy nêu rõ định dạng mong muốn trong phần mô tả tham số kèm theo ví dụ. Điều này đặc biệt quan trọng vì quá trình chuẩn hóa dữ liệu và chuyển đổi giọng nói thành văn bản có thể tạo ra các giá trị ở dạng văn nói trong ngữ cảnh hội thoại. 

Kém hiệu quả: mô tả tham số mơ hồ

## Các tham số của công cụ `lookupAccount`

- `email` (bắt buộc): "Địa chỉ email của khách hàng."

Khuyến nghị: định dạng rõ ràng kèm ví dụ

## Các tham số của công cụ `lookupAccount`

- `email` (bắt buộc): "Địa chỉ email của khách hàng theo định dạng chuẩn, ví dụ: 'john.smith@company.com'."

Xử lý lỗi khi gọi công cụ một cách khéo léo

Đôi khi công cụ có thể gặp lỗi do sự cố mạng, thiếu dữ liệu hoặc các lỗi khác. Hãy đưa ra hướng dẫn rõ ràng trong system prompt về cách khắc phục các tình huống này.

Tại sao điều này quan trọng đối với độ tin cậy: Lỗi công cụ là điều khó tránh khỏi trong môi trường vận hành thực tế (production). Nếu thiếu hướng dẫn xử lý cụ thể, các agent có thể tự tạo ra câu trả lời sai lệch hoặc cung cấp thông tin không chính xác.

Phương pháp đề xuất

# Xử lý lỗi công cụ

Nếu việc gọi công cụ gặp lỗi hoặc trả về thông báo lỗi:

1. Thông báo cho khách hàng về vấn đề: "Hiện tại tôi đang gặp khó khăn khi truy cập thông tin đó."
2. Tuyệt đối không tự đoán hoặc bịa đặt thông tin.
3. Đưa ra các phương án thay thế:
  - Thử lại công cụ nếu có thể đây chỉ là sự cố tạm thời.
  - Đề nghị chuyển yêu cầu cho nhân viên hỗ trợ (con người).
  - Cung cấp tùy chọn gọi lại cho khách hàng.
4. Nếu lỗi vẫn tiếp diễn sau 2 lần thử, hãy chuyển vấn đề cho cấp quản lý.

**Ví dụ về cách phản hồi:**

- "Hiện tại tôi đang gặp khó khăn khi tra cứu đơn hàng đó. Để tôi thử lại xem sao... [thử lại]"
- "Lúc này tôi không thể truy cập vào hệ thống đơn hàng. Tôi có thể chuyển máy cho chuyên viên hỗ trợ giúp bạn, hoặc chúng ta có thể hẹn lịch gọi lại. Bạn muốn chọn phương án nào?"

Các mô hình kiến ​​trúc cho agent cấp doanh nghiệp

Mặc dù các câu lệnh (prompt) mạnh mẽ và công cụ hiệu quả tạo nên nền tảng cho độ tin cậy của agent, nhưng những hệ thống vận hành thực tế đòi hỏi thiết kế kiến ​​trúc kỹ lưỡng. Các agent cấp doanh nghiệp thường xử lý những quy trình phức tạp, vượt quá phạm vi của một câu lệnh đơn lẻ và monolithic prompt.

Duy trì tính chuyên biệt cho các agent

Các hướng dẫn quá bao quát hoặc cửa sổ ngữ cảnh quá lớn sẽ làm tăng độ trễ và giảm độ chính xác. Mỗi agent cần có phạm vi kiến ​​thức và tập hợp trách nhiệm hẹp, được xác định rõ ràng.

Tại sao điều này quan trọng đối với độ tin cậy: Các agent chuyên biệt có ít trường hợp ngoại lệ cần xử lý hơn, tiêu chí thành công rõ ràng hơn và thời gian phản hồi nhanh hơn. Chúng cũng dễ kiểm thử, gỡ lỗi và cải tiến hơn.

Một agent đa năng "làm tất cả mọi việc" sẽ khó bảo trì và dễ gặp lỗi khi vận hành thực tế hơn so với một mạng lưới các agent chuyên biệt có quy trình chuyển giao nhiệm vụ rõ ràng.

Sử dụng mô hình điều phối (orchestrator) và chuyên gia (specialist)

Đối với các tác vụ phức tạp, hãy thiết kế workflow multi-agent, trong đó nhiệm vụ được chuyển giao giữa các agent chuyên biệt - và chuyển giao cho nhân viên (người thực) khi cần thiết.

Mô hình kiến ​​trúc:

• Orchestrator agent: Định hướng các yêu cầu đến đúng agent chuyên gia dựa trên việc phân loại ý định.
• Specialist agent: Xử lý các tác vụ thuộc lĩnh vực cụ thể (thanh toán, đặt lịch, hỗ trợ kỹ thuật, v.v...).
• Chuyển giao cho con người: Xác định rõ tiêu chí chuyển giao đối với các trường hợp phức tạp hoặc nhạy cảm.

Lợi ích của mô hình này:

• Mỗi chuyên gia có câu lệnh (prompt) tập trung và phạm vi ngữ cảnh nhỏ gọn hơn.
• Dễ dàng cập nhật từng chuyên gia riêng lẻ mà không ảnh hưởng đến toàn bộ hệ thống.
• Có các chỉ số rõ ràng cho từng lĩnh vực (tỷ lệ giải quyết vấn đề thanh toán, tỷ lệ đặt lịch thành công, v.v...).
• Giảm độ trễ trong mỗi lần tương tác (câu lệnh ngắn hơn, suy luận nhanh hơn).

Xác định rõ tiêu chí chuyển giao

Khi thiết kế workflow multi-agent, cần quy định chính xác thời điểm và cách thức chuyển giao quyền kiểm soát giữa các agent hoặc sang nhân viên con người.

Ví dụ về Orchestrator agent

# Mục tiêu

Điều phối yêu cầu của khách hàng đến chuyên viên phù hợp dựa trên mục đích của yêu cầu.

## Quy tắc điều phối

**Chuyên viên thanh toán:** Khách hàng đề cập đến thanh toán, hóa đơn, hoàn tiền, khoản phí, gói đăng ký hoặc số dư tài khoản.
**Chuyên viên hỗ trợ kỹ thuật:** Khách hàng báo cáo lỗi, sự cố, vấn đề kỹ thuật, hoặc tình trạng hệ thống/thiết bị không hoạt động/bị hỏng.
**Chuyên viên đặt lịch:** Khách hàng muốn đặt lịch, đổi lịch, hủy lịch hoặc kiểm tra thông tin cuộc hẹn.
**Chuyển tiếp cho nhân sự cấp cao:** Khách hàng tỏ thái độ tức giận, yêu cầu gặp quản lý, hoặc vấn đề chưa được giải quyết sau 2 lần hỗ trợ bởi chuyên viên.

## Quy trình chuyển tiếp

1. Phân loại mục đích của khách hàng dựa trên tin nhắn đầu tiên.
2. Phản hồi xác nhận ngắn gọn: "Tôi sẽ kết nối bạn với bộ phận [thanh toán/kỹ thuật/đặt lịch] của chúng tôi."
3. Chuyển tiếp cuộc hội thoại kèm tóm tắt thông tin:
  - Tên khách hàng
  - Vấn đề chính
  - Các thông tin định danh tài khoản đã thu thập được
4. Không yêu cầu khách hàng cung cấp lại những thông tin đã được thu thập trước đó.

Ví dụ về Specialist agent

# Vai trò

Bạn là chuyên viên thanh toán của Acme Corp. Bạn phụ trách xử lý các vấn đề về thanh toán, hoàn tiền và thay đổi gói đăng ký.

# Mục tiêu

Giải quyết các thắc mắc về thanh toán bằng cách:

1. Xác minh danh tính khách hàng
2. Tra cứu thông tin tài khoản và lịch sử thanh toán
3. Xử lý hoàn tiền (dưới 500 USD) hoặc chuyển lên cấp trên xử lý (trên 500 USD)
4. Cập nhật cài đặt gói đăng ký khi có yêu cầu

# Quy tắc bắt buộc

Tuyệt đối không truy cập thông tin tài khoản khi chưa xác minh danh tính.
Tuyệt đối không xử lý hoàn tiền trên 500 USD nếu chưa được cấp trên phê duyệt.
Nếu vấn đề của khách hàng không liên quan đến thanh toán, hãy chuyển lại cho orchestrator agent.

Lựa chọn mô hình đảm bảo độ tin cậy cho doanh nghiệp

Việc chọn đúng mô hình phụ thuộc vào các yêu cầu về hiệu suất của bạn - đặc biệt là độ trễ, độ chính xác và độ tin cậy khi gọi công cụ. Các mô hình khác nhau mang lại sự cân bằng khác nhau giữa tốc độ, khả năng suy luận và chi phí.

Hiểu rõ các yếu tố đánh đổi

Độ trễ: Các mô hình nhỏ hơn (ít tham số hơn) thường phản hồi nhanh hơn, phù hợp cho những tương tác tần suất cao và độ phức tạp thấp.

Độ chính xác: Các mô hình lớn hơn cung cấp khả năng suy luận mạnh mẽ hơn và xử lý tốt hơn những tác vụ phức tạp, gồm nhiều bước, nhưng đi kèm với độ trễ và chi phí cao hơn.

Độ tin cậy khi gọi công cụ: Không phải tất cả các mô hình đều xử lý việc gọi công cụ/hàm với độ chính xác như nhau. Một số mô hình vượt trội trong việc tạo đầu ra có cấu trúc, trong khi số khác có thể cần các câu lệnh (prompt) chi tiết và rõ ràng hơn.

Khuyến nghị mô hình theo trường hợp sử dụng

Dựa trên dữ liệu triển khai qua hàng triệu tương tác của AI agent, các xu hướng sau đây đã được ghi nhận:

• GPT-4o hoặc GLM 4.5 Air (điểm khởi đầu được khuyến nghị): Tốt nhất cho các AI agent doanh nghiệp đa năng, nơi cần cân bằng giữa độ trễ, độ chính xác và chi phí. Cung cấp độ trễ từ thấp đến trung bình, hiệu suất gọi công cụ mạnh mẽ và chi phí hợp lý cho mỗi tương tác. Lý tưởng cho hỗ trợ khách hàng, lên lịch trình, quản lý đơn hàng và xử lý các yêu cầu thông tin chung.
• Gemini 2.5 Flash Lite (độ trễ cực thấp): Tốt nhất cho các tương tác đơn giản, tần suất cao, nơi tốc độ là yếu tố then chốt. Mang lại độ trễ thấp nhất cùng kiến ​​thức tổng quát phong phú, mặc dù hiệu suất gọi công cụ phức tạp thấp hơn. Hiệu quả về chi phí khi triển khai quy mô lớn cho các tác vụ như định hướng/phân loại ban đầu, giải đáp câu hỏi thường gặp (FAQ) đơn giản, xác nhận cuộc hẹn và thu thập dữ liệu cơ bản.
• Claude Sonnet 4 hoặc 4.5 (suy luận phức tạp): Tốt nhất cho việc giải quyết vấn đề nhiều bước, đưa ra phán đoán tinh tế và điều phối công cụ phức tạp. Cung cấp độ chính xác và khả năng suy luận cao nhất cùng độ tin cậy tuyệt vời khi gọi công cụ, dù chi phí và độ trễ cao hơn. Lý tưởng cho các tác vụ mà sai sót gây hậu quả lớn, chẳng hạn như khắc phục sự cố kỹ thuật, tư vấn tài chính, quy trình tuân thủ nghiêm ngặt và các quyết định phức tạp về hoàn tiền hoặc leo thang xử lý.

Đánh giá hiệu năng với các câu lệnh thực tế của bạn

Hiệu suất của mô hình thay đổi đáng kể tùy thuộc vào cấu trúc câu lệnh và độ phức tạp của tác vụ. Trước khi quyết định chọn một mô hình:

1. Thử nghiệm 2-3 mô hình ứng viên với câu lệnh hệ thống (system prompt) thực tế của bạn
2. Đánh giá dựa trên các truy vấn của người dùng thực hoặc những trường hợp kiểm thử giả lập
3. Đo lường độ trễ, độ chính xác và tỷ lệ thành công khi gọi công cụ
4. Tối ưu hóa để đạt được sự cân bằng tốt nhất dựa trên các yêu cầu cụ thể của bạn