Cách xây dựng Voice Agent bằng AI (Hướng dẫn đầy đủ)

đây là sự thật mà không ai nói với những người xây dựng AI. Voice agent không cần

mô hình tốt nhất. Tất cả những gì chúng cần là

TLDR; Nếu bạn thấy việc đọc chán hoặc khả năng tập trung của bạn đã bị ảnh hưởng, bạn có thể dùng file kỹ năng tôi đã làm để lấy toàn bộ bài viết và dán vào agent của bạn ➡️https://github.com/codejunkie99/voice-agent-builder

tất cả những gì bạn cần xây dựng là:

• một pipeline thời gian thực với ngân sách độ trễ thực tế
• năm thành phần được kết nối theo đúng thứ tự
• grounding đủ mạnh để giữ mô hình trung thực
• một vòng lặp đánh giá hàng tuần để tích lũy cải thiện

OpenAI đã ra mắt GPT-Realtime-2 vào ngày 7 tháng 5 năm 2026. Salesforce AI Research đã công bố bài báo VoiceAgentRAG vào ngày 1 tháng 3, cùng tuần Deepgram Flux chuyển từ beta sang GA. Các mảnh ghép không còn là vấn đề nữa.

Điều vẫn còn là vấn đề là cách bạn kết nối chúng và nội dung bạn viết cho agent để nói.

Tôi đã dành ba tháng qua để xây dựng các voice agent thực sự trả lời điện thoại. Tôi sẽ không giả vờ rằng mọi thứ đều suôn sẻ.

• Bản build đầu tiên nghe như một ki-ốt. Tôi đã loại bỏ nó trong hai ngày.
• Bản build thứ hai "đặt" bốn cuộc hẹn ảo trong giờ đầu tiên trước khi tôi nhận ra.
• Bản build thứ ba bị rò rỉ bộ nhớ vì tôi quên xóa cache ngữ cảnh sau khi trình trích xuất nền ghi thông tin mới.
• Đến khi có thứ gì đó hoạt động, hệ thống đã là lần viết lại thứ tư.

Phiên bản mà tôi sẽ bảo vệ bây giờ có một tập hợp nhỏ các thuộc tính mà tôi sẽ dành 6.000 từ tiếp theo để giải thích.

• Pipeline có một nhiệm vụ duy nhất trong một ngân sách duy nhất. Năm thành phần, end-to-end dưới 700ms, không có ngoại lệ.
• Kiến thức nằm trong tài liệu của bạn và được truy xuất bằng dual-agent cache, không phải được lấy từ đầu của mô hình.
• Thiết kế hội thoại là kỷ luật viết cho tai, không phải mắt. Hầu hết các đội coi đây là việc làm đẹp. Nhưng không phải vậy.
• Mỗi lượt tương tác đều ghi một log có cấu trúc mà tôi có thể phát lại với cấu hình hiện tại 90 ngày sau.

Bài viết này là những gì 90 ngày đó thực sự dạy tôi, cùng với hai hoặc ba lựa chọn ưu tiên mà tôi sẽ thực hiện đầu tiên nếu bắt đầu lại từ hôm nay.🔽🔽

Voice agent thực sự là gì

Voice agent không phải là chatbot với micro gắn thêm. Nó không phải là lớp bọc TTS quanh một API văn bản.

Nó là một hệ thống âm thanh thời gian thực. Bị giới hạn bởi độ trễ. Năm thành phần phối hợp trong cửa sổ 300 đến 800 mili giây.

Pipeline theo thứ tự các sự kiện thực tế diễn ra:

1. Người dùng nói
2. Âm thanh được thu
3. Streaming STT phiên âm từng từ, trong khi người đó vẫn đang nói
4. Agent đọc bản phiên âm và truy xuất kiến thức liên quan từ tài liệu của bạn
5. LLM tạo ra phản hồi
6. TTS đọc phản hồi bằng giọng nói
7. Người dùng nghe thấy

Mỗi một mũi tên trong số đó là một thành phần bạn có thể chọn, tinh chỉnh và thay thế.

Tôi đã thử xây dựng nó theo cách chatbot trước. STT hoàn tất, gửi đến LLM, chờ phản hồi đầy đủ, gửi đến TTS, chờ âm thanh đầy đủ, phát.

Nó rất tệ. Giống như nói chuyện với một ki-ốt. Hai ngày sau tôi đã xóa nó.

Lý do nó tệ không phải vì số liệu độ trễ tồi. Trên giấy tờ chúng ổn. Lý do là con người không trò chuyện theo lượt. Họ trò chuyện theo luồng chồng lấn.

• Agent phải bắt đầu hình thành phản hồi trong khi người dùng vẫn đang hoàn thành câu.
• TTS phải bắt đầu nói trước khi LLM viết xong.
• STT phải tiếp tục lắng nghe trong khi agent đang nói, để nó biết khi nào im lặng.

Một voice agent không thể bị ngắt lời không phải là voice agent. Nó là hộp thư thoại.

Ba kiến trúc

Chỉ có ba. Hãy chọn dựa trên những gì bạn cần kiểm soát.

Pipeline chuỗi (Chained pipeline)

• Các dịch vụ STT, LLM, TTS riêng biệt được kết nối với nhau
• Ba mô hình độc lập, mỗi mô hình chuyên trách nhiệm vụ của nó
• Văn bản chảy giữa chúng
• Độ trễ khoảng 600 đến 700ms trên nền tảng quản lý được tối ưu tốt
• Dễ kiểm soát nhất, dễ gỡ lỗi nhất, dễ nâng cấp từng lớp một

Bán song song (Half-cascade)

• Âm thanh đi trực tiếp vào mô hình đa phương thức nghe âm thanh, không phải bản phiên âm
• Bắt được sự thất vọng trong giọng nói, một câu hỏi ngụ ý qua giọng điệu lên cao, chuyển đổi ngôn ngữ giữa câu
• Đầu ra vẫn đi qua TTS chuyên dụng để kiểm soát âm thanh
• Độ trễ giảm xuống 300 đến 500ms

Chuyển giọng nói gốc (Native speech-to-speech)

• Một mô hình, âm thanh vào, âm thanh ra
• Không có lớp phiên âm, không chuyển tiếp văn bản
• Mọi phòng thí nghiệm lớn đều phát hành mô hình giọng nói gốc vào năm 2026
• Độ trễ giảm xuống 200 đến 300ms, dưới ngưỡng mà người gọi ngừng nhận thấy họ đang nói chuyện với AI

Nên bắt đầu với cái nào

1. Bắt đầu với pipeline chuỗi. Công cụ tốt nhất tồn tại cho nó. Chuyển sang speech-to-speech khi bạn đã chứng minh sản phẩm của mình trên pipeline và muốn cải thiện độ trễ theo bước nhảy.
2. Tôi đã thử speech-to-speech trước cho mọi thứ. Nó rất xuất sắc cho các luồng đặt chỗ.
3. Nó thất bại với một biểu mẫu nhập liệu 12 bước vì mô hình đơn không thể giữ máy trạng thái trong đầu mà không làm phồng ngữ cảnh vào lượt thứ chín.
4. Tôi đã chuyển cái đó sang pipeline chuỗi với một lớp máy trạng thái thực sự và tỷ lệ hoàn thành tăng từ 61% lên 89% trong ba ngày.
5. Phạm vi công cụ theo từng trạng thái là toàn bộ giải pháp.

Năm thành phần bạn phải kết nối

Mọi pipeline chuỗi đều có cùng năm thành phần. Năm công việc cần được lấp đầy trước khi agent của bạn thực hiện cuộc gọi đầu tiên.

Tai (Streaming STT)

Mô hình STT chuyển đổi âm thanh đầu vào thành văn bản theo thời gian thực, từng từ một, trong khi người đó vẫn đang nói. Đây là thành phần quan trọng nhất trong stack của bạn. Một lỗi phiên âm ở đây sẽ lan truyền xuống mọi thứ bên dưới.

Những gì cần tìm kiếm vào năm 2026:

• Độ chính xác streaming. Chính xác trong khi người đó đang nói, không chỉ sau khi họ nói xong.
• Tỷ lệ lỗi từ (WER). 6 đến 8% trên âm thanh sản xuất thực tế là tốt. Trên 12% sẽ gây khó chịu cho người dùng trên mọi cuộc gọi thứ ba.
• Phát hiện kết thúc lượt nói tích hợp. Cải tiến UX lớn nhất duy nhất của năm 2026.

Tại sao phát hiện kết thúc lượt nói lại quan trọng:

• STT chung chung trả về bản phiên âm. Nó không cho bạn biết khi nào người nói đã kết thúc.
• Nếu không có nó, agent của bạn sẽ ngắt lời giữa câu hoặc chờ hai giây khó xử.
• Làn sóng mô hình STT streaming năm 2026 tích hợp sẵn tính năng phát hiện kết thúc lượt nói trong cùng mạng tạo ra bản phiên âm.
• Mô hình phát ra tín hiệu turn-complete khi nó quyết định người nói đã kết thúc.
• Tín hiệu sử dụng ngữ cảnh ngữ nghĩa, không chỉ im lặng âm thanh. Nó bắt được các câu nói lửng và bỏ qua các khoảng dừng thở.
• Chuyển sang tính năng này nếu nhà cung cấp của bạn đã phát hành nó. Khoảng dừng trước khi agent bắt đầu nói giảm 200 đến 400ms trên mỗi lượt.

Não (LLM)

LLM đọc bản phiên âm, lịch sử hội thoại, kiến thức đã truy xuất và quyết định sẽ nói gì. Nó cũng quyết định hành động, không chỉ lời nói.

Các quy tắc dành riêng cho giọng nói:

• Sử dụng mô hình nhỏ nhanh, không phải mô hình hàng đầu. Các mô hình lý luận tiên tiến mất 1500ms để tạo ra từ đầu tiên. Đó là khoảng lặng chết. Các mô hình nhỏ hơn trong cùng một dòng hầu như luôn thắng trên các lượt giọng nói.
• Chỉ chuyển lên mô hình lớn cho các lệnh gọi công cụ phức tạp cụ thể cần lập kế hoạch thực sự.
• Giới hạn prompt hệ thống ở 800 token. Nó được tải lại trên mỗi lượt. Prompt 4000 token thêm độ trễ cho mọi tin nhắn.

Function calling, bằng tiếng Việt đơn giản:

• Bạn định nghĩa từng hàm với mô tả về những gì nó làm và thông tin nó cần.
• LLM đọc mô tả và quyết định khi nào gọi nó dựa trên trạng thái hội thoại.
• Không có cây logic điều kiện. LLM khớp ý định với hàm từ ngôn ngữ tự nhiên.

Lỗi sản xuất phổ biến nhất với function calling không phải là những gì bạn nghĩ:

• LLM không báo lỗi khi không thể gọi một hàm. Thay vào đó, nó tường thuật hành động.
• "Tôi đã xác nhận đặt chỗ của bạn." Không có gì được gọi. Người dùng nghĩ họ đã được đặt. Nhưng họ không.
• Giải pháp là phạm vi công cụ cho trạng thái hiện tại. Trạng thái "thu thập tên" không được phép hiển thị book_appointment. Trạng thái "xác nhận chi tiết" không được phép hiển thị check_availability.
• Máy trạng thái là thanh ray an toàn, không phải prompt hệ thống.

Kiến thức (RAG)

RAG là cơ chế cho phép agent của bạn trả lời từ tài liệu của bạn thay vì dữ liệu huấn luyện của mô hình.

Tại sao bạn không thể bỏ qua điều này:

• LLM được huấn luyện trên internet công cộng đến một ngày cắt.
• Chúng biết nhiều về thế giới. Chúng không biết gì cụ thể về sản phẩm, giá cả, chính sách, khách hàng của bạn.
• Nếu không có RAG, một agent được hỏi "gói doanh nghiệp có gì?" sẽ ảo giác một cách tự tin.
• Với RAG, nó truy xuất câu trả lời thực tế từ tài liệu của bạn trước khi phản hồi.

Cơ chế cơ bản:

• Người dùng hỏi một câu.
• Hệ thống nhúng (embed) truy vấn.
• Cơ sở dữ liệu vector trả về các đoạn tài liệu liên quan nhất.
• Các đoạn được tiêm vào ngữ cảnh của LLM.
• LLM được hướng dẫn chỉ trả lời từ ngữ cảnh đó.

Thách thức dành riêng cho giọng nói:

• Một truy vấn cơ sở dữ liệu vector điển hình thêm 50 đến 300ms vào pipeline.
• Kết hợp với STT, LLM và TTS, điều đó phá vỡ ngân sách độ trễ của bạn.
• Giải pháp là mẫu dual-agent cache. Toàn bộ phần về điều này ở dưới đây.

Miệng (TTS)

TTS chuyển đổi văn bản thành âm thanh giọng nói. Nghe có vẻ đơn giản. Nhưng thực sự là một yếu tố khác biệt lớn về chất lượng cảm nhận.

Điều quan trọng:

• Thời gian đến âm thanh đầu tiên. Một TTS mất 200ms để bắt đầu nói sẽ đốt một phần ba ngân sách độ trễ của bạn chỉ riêng ở lớp đầu ra.
• Chất lượng giọng nói. Con người cực kỳ nhạy cảm với giọng nói tổng hợp. Các hiệu ứng tinh vi, nhịp điệu không tự nhiên, trọng âm sai vị trí đều bị coi là phán quyết về toàn bộ hệ thống.
• Chọn giọng nói có chủ đích. Đó là tín hiệu tin cậy trước khi người dùng nghe thấy một câu.

Tay (Hàm và Tích hợp)

Hàm là các hành động LLM có thể thực hiện giữa cuộc trò chuyện:

• Đặt lịch hẹn
• Tra cứu trạng thái đơn hàng
• Gửi SMS xác nhận
• Chuyển sang người thật
• Cập nhật hồ sơ trong CRM của bạn

Đây là sự thay đổi kiến trúc làm cho các voice agent hiện đại mạnh mẽ hơn đáng kể so với các hệ thống nhấn-1-để-thanh-toán.

Ngân sách độ trễ bạn phải nằm trong

Điều quan trọng nhất không hiển nhiên về voice agent: mỗi mili giây xử lý là một mili giây im lặng mà người gọi phải chịu.

Toán học:

• Con người mong đợi một phản hồi hội thoại trong vòng 500 đến 700ms sau khi kết thúc một câu
• Quá một giây có cảm giác hệ thống đang vật lộn
• Quá hai giây, người gọi bắt đầu nói đè lên agent

700ms đó là toàn bộ ngân sách của bạn, được chia cho mọi thành phần.

Ngân sách mỗi thành phần, làn nhanh so với làn chậm:

• Transport: 20-50ms peer-to-peer. 50-100ms qua relay.
• STT lần đầu: 100-150ms khi cache hit. 150-250ms khi miss.
• Phát hiện kết thúc lượt: Tích hợp mô hình, ~50ms. Ngưỡng im lặng, 300-600ms.
• Truy xuất RAG: Dưới mili giây khi cache hit. 80-150ms với BM25 local + rerank.
• LLM thời gian đến token đầu tiên: 150-250ms với mô hình nhỏ. 400-600ms với mô hình tiên tiến.
• TTS thời gian đến âm thanh đầu tiên: 60-100ms trên bậc nhanh. 150-250ms trên bậc chất lượng.
• Chi phí mạng: 40-80ms tổng trong cùng một khu vực. 100-160ms tổng qua các khu vực.
• End-to-end: ~440ms trên làn nhanh. ~700-900ms trên làn chậm.

Hai thành tựu lớn nhất trong năm 2026:

1. Phát hiện kết thúc lượt nói tích hợp mô hình. Loại bỏ 200 đến 400ms khỏi mỗi lượt. Nâng cấp duy nhất lớn nhất bạn có thể thực hiện trong năm nay.
2. Speculative prefetch với dual-agent cache. Chuyển truy xuất từ "miss với tìm kiếm vector" thành "hit với tra cứu cache" trên khoảng 40% số lượt.

Mọi thứ khác chỉ là sai số so với hai điều này.

Mẫu dual-agent RAG

RAG tiêu chuẩn bên trong vòng lặp giọng nói là một vấn đề. Truy vấn cơ sở dữ liệu vector mất 80 đến 300ms và phá vỡ ngân sách độ trễ của bạn trên mỗi lượt.

Câu trả lời nghiên cứu năm 2026 đến từ bài báo VoiceAgentRAG của Salesforce AI Research, được công bố vào tháng 3. Ý tưởng rất đơn giản.

• Trong một cuộc trò chuyện thực tế, câu hỏi tiếp theo thường có thể dự đoán được từ câu hỏi hiện tại.
• Ai đó hỏi về giá cả có thể sẽ hỏi tiếp về gói doanh nghiệp.
• Ai đó hỏi về cài đặt có thể sẽ hỏi về khả năng tương thích tiếp theo.

Vì vậy, bạn chạy hai agent cùng một lúc.

Agent nền (Slow Thinker)

• Chạy trong khi người dùng đang nghe phản hồi hiện tại
• Dự đoán ba đến năm câu hỏi tiếp theo có khả năng nhất bằng cách sử dụng LLM
• Tìm nạp trước các đoạn tài liệu liên quan cho mỗi dự đoán
• Lưu trữ chúng trong bộ nhớ cache trong bộ nhớ cục bộ trước khi người dùng nghe xong câu trả lời hiện tại

Agent tiền cảnh (Fast Talker)

• Xử lý câu hỏi trực tiếp tiếp theo bằng cách kiểm tra bộ nhớ cache trong bộ nhớ trước
• Tra cứu cache mất thời gian dưới mili giây so với 110ms cho một cuộc gọi cơ sở dữ liệu vector từ xa
• Nếu cache có câu trả lời, bỏ qua cơ sở dữ liệu hoàn toàn
• Nếu cache miss, dự phòng đến cơ sở dữ liệu và lưu kết quả đó vào cache cho lần sau

Số liệu điểm chuẩn từ bài báo

• 75% truy vấn hit cache
• Tăng tốc truy xuất gấp 316 lần khi cache hit (0,35ms so với 110ms)
• Tiết kiệm 16 giây độ trễ tích lũy trên 200 truy vấn

Nguyên tắc cần nhớ: sử dụng thời gian người dùng lắng nghe làm thời gian tính toán của bạn. Khoảnh khắc họ bắt đầu nghe phản hồi hiện tại là khoảnh khắc bạn bắt đầu chuẩn bị cho câu hỏi tiếp theo của họ.

Tôi đã thử vector RAG đơn thuần bên trong vòng lặp giọng nói trong bản build đầu tiên. Thêm 110ms mỗi lượt.

Giết chết cảm giác hội thoại. Tôi chuyển sang mẫu dual-agent cache vào tuần thứ sáu. 40% số lượt hit cache cảm thấy nhanh hơn so với các tổng đài viên con người mà agent thay thế.

Thiết kế hội thoại là kỷ luật mà hầu hết những người xây dựng bỏ qua

Bạn có thể có STT nhanh nhất, LLM nhỏ nhất, RAG cache thông minh nhất. Nếu agent của bạn không biết cách nói chuyện, người gọi sẽ cúp máy.

Thiết kế hội thoại là kỷ luật viết cho tai, không phải mắt.

Các quy tắc tôi tuân theo bây giờ mà tôi đã học được bằng cách làm sai trước

• Nói bằng câu ngắn. Khoảng chú ý trung bình của con người đối với thông tin bằng lời nói là 8 đến 10 giây. Một phản hồi 15 giây là quá dài. Chia nó thành hai lượt.
• Không bao giờ hỏi hai câu hỏi trong một lượt. Người gọi chỉ có thể giữ một câu trong bộ nhớ làm việc. Hỏi một câu, chờ, sau đó hỏi câu tiếp theo.
• Sử dụng các cụm từ xác nhận. "Rồi." "Được rồi." "Để tôi kiểm tra cho bạn." Những điều này lấp đầy khoảng lặng giữa lúc người dùng kết thúc và phản hồi sẵn sàng.
• Phản chiếu ngôn ngữ của người dùng. Người gọi nói "vấn đề thanh toán", agent nói "vấn đề thanh toán" trở lại. Không phải "tranh chấp tài chính" hay "vấn đề chi trả". Diễn giải tạo ra ma sát. Phản chiếu tạo ra sự đồng cảm.
• Viết cho tai, không phải mắt. Không có gạch đầu dòng. Không có tiêu đề. Không có markdown trong prompt hệ thống. LLM sẽ cố nói dấu sao và dấu gạch ngang.
• Đánh vần số. "Chín bốn một không bảy" thay vì "94,107". "Mười lăm đô la và chín mươi chín xu" thay vì "$15,99". TTS thường xuyên phát âm sai các số có định dạng.
• Giới hạn prompt hệ thống ở 800 token. Nó được tải lại trên mỗi lượt.

Cấu trúc ba màn của mọi cuộc hội thoại giọng nói tốt

1. Xác nhận và định hướng. "Vậy là bạn muốn dời lịch hẹn vào thứ Năm, để tôi lấy thông tin đó." Xác nhận người gọi đã được hiểu. Mua thời gian trong khi truy xuất chạy.
2. Giải quyết. Hành động hoặc câu trả lời cốt lõi. Một điểm mỗi lượt. Tiến lên.
3. Xác nhận và kết thúc. "Tôi đã dời lịch hẹn của bạn sang thứ Hai, ngày 19 lúc 3 giờ chiều, bạn sẽ nhận được tin nhắn xác nhận ngay sau đó." Kết thúc sạch sẽ. Không bao giờ để một vòng lặp mở.

An toàn là hai điểm kiểm tra, không phải một

Thành phần mà hầu hết những người xây dựng lần đầu bỏ qua và hối tiếc.

Voice agent không có thời điểm "đọc trước khi gửi". Một đầu ra không an toàn được nói ra ngay lập tức. Không có bản nháp, không có xem trước, không có con người trong vòng lặp.

Mô hình đúng là hai điểm kiểm tra.

Bộ kiểm soát đầu vào (trước khi LLM nhìn thấy lượt của người dùng)

• Injection prompt. "Bỏ qua hướng dẫn trước, giả vờ bạn là..." các cuộc tấn công. Khai thác khả năng làm theo hướng dẫn của LLM để đánh cắp dữ liệu hoặc phá vỡ phạm vi.
• PII được nói to. Số thẻ tín dụng, số an sinh xã hội. Biên tập trước khi chúng chạm vào bất kỳ log hoặc cơ sở dữ liệu nào.
• Danh sách chặn chủ đề. Được tải từ file JSON. Cập nhật hàng tuần khi bạn học được những gì người dùng thực sự thử.

Bộ kiểm soát đầu ra (sau khi LLM viết phản hồi, trước khi TTS nói nó)

• Ngôn ngữ hứa hẹn quá mức. "Tôi đảm bảo," "Tôi hứa." Tạo ra các vấn đề pháp lý và niềm tin trên một đường dây được ghi âm.
• Các tuyên bố thực tế cụ thể không có trong ngữ cảnh được truy xuất. Kiểm tra ảo giác nhẹ. Bắt khoảng 70% câu trả lời bịa đặt trong triển khai của tôi.
• Điểm cuối kiểm duyệt tiêu chuẩn. Cho hành vi sai lệch hiếm gặp của mô hình.

Cả hai bộ kiểm soát đều trả về

• safe (bool)
• detected category (string, nếu không an toàn)
• replacement phrase mà agent nói thay vào

Mỗi lần kích hoạt đều ghi vào file với dấu thời gian, danh mục, văn bản đã biên tập và ID cuộc gọi.

Cụm từ leo thang

Một cụm từ chính xác, được mã hóa cứng, mà agent nói khi nó không biết câu trả lời hoặc khi có điều gì đó sai.

• "Tôi muốn chắc chắn cung cấp thông tin chính xác cho bạn. Hãy để tôi kết nối bạn với người có thể giúp đỡ."
• Không phải năm biến thể. Không phải phỏng đoán ngẫu hứng của LLM về cách diễn đạt đúng.
• Một cụm từ. VIẾT HOA trong prompt hệ thống. Fall-through khi bất kỳ kiểm tra an toàn nào kích hoạt.

Tôi đã phát hành mà không có bộ kiểm soát đầu ra trong bản build đầu tiên. Agent tự tin báo giá thấp hơn 30% so với giá thực tế.

Giá đó nằm trong một tài liệu cũ trong cơ sở kiến ​​thức.

Kiểm tra ảo giác sẽ bắt được nó vì giá đúng không có trong ngữ cảnh được truy xuất.

Đánh giá, hay làm thế nào để biết nó có tốt không

Bạn không thể cải thiện những gì bạn không thể đo lường. Hầu hết các đội bỏ qua đánh giá và phát hành các agent hỏng.

Khung bốn lớp

Lớp 1: Hạ tầng. Đường ống dẫn.

• WER trên miền thực tế của bạn (không phải điểm chuẩn của nhà cung cấp)
• Độ trễ p50, p95, p99 của toàn bộ pipeline
• Thời gian đến âm thanh đầu tiên
• Chất lượng âm thanh trên transport của bạn

Lớp 2: Thực thi. Agent có làm những gì được yêu cầu không.

• Tỷ lệ thành công nhiệm vụ
• Độ chính xác gọi công cụ
• Độ chính xác tham số
• Tính căn cứ của phản hồi
• Sử dụng LLM-as-judge trên mô hình nhỏ nhanh. Bốn câu hỏi có/không: trả lời đúng, dựa trên thông tin, nghe tự nhiên đối với giọng nói, ngắn gọn phù hợp.

Lớp 3: Hành vi người dùng. Nó có cảm giác tự nhiên khi nói chuyện không.

• Tỷ lệ phục hồi barge-in
• Tỷ lệ nhắc lại
• Độ dài lượt trung bình
• Số lần sửa lỗi hội thoại
• Lấy mẫu 20 cuộc gọi một tuần. Đọc các bản ghi thực tế. Bạn sẽ thấy các mẫu trong vòng mười cuộc gọi.

Lớp 4: Kết quả kinh doanh. Nó có giải quyết vấn đề không.

• Tỷ lệ chứa (phần trăm cuộc gọi được giải quyết mà không có con người)
• Tỷ lệ chuyển
• CSAT
• Tỷ lệ giải quyết cuộc gọi đầu tiên
• Tối ưu hóa theo tỷ lệ chứa. Nó tương quan với mọi thứ khác và dễ đo lường nhất mà không cần thiết bị.

Thành phần bộ kiểm tra

Xây dựng nó trước khi bạn ra mắt. Tối thiểu 50 cuộc hội thoại.

• 40% đường hạnh phúc (happy path)
• 30% trường hợp cạnh
• 15% xử lý lỗi
• 10% đối kháng (injection prompt, cố gắng phá vỡ)
• 5% biến thể âm thanh (tiếng ồn nền, giọng nặng, loa ngoài)

Cho mỗi kịch bản:

• Công cụ nào đáng lẽ đã được gọi
• Với những tham số nào
• Agent nên nói gì

Vòng lặp đánh giá hàng tuần

Mỗi sáng thứ Hai. 30 phút.

1. Lấy metrics
2. Lấy mẫu 20 cuộc gọi (7 được chuyển, 7 được giải quyết, 6 ngẫu nhiên)
3. Đọc các bản ghi
4. Xác định loại lỗi phổ biến nhất duy nhất
5. Thực hiện một thay đổi (một biến mỗi lần, luôn luôn)
6. A/B test trong 48 giờ
7. Phát hành phiên bản thắng

Grounding là một hệ thống niềm tin

Hầu hết những người xây dựng nghĩ về RAG như một tính năng hiệu suất, một cách để có được câu trả lời chính xác hơn. Cách tiếp cận đó đánh giá thấp nó.

Trong một voice agent, độ chính xác của mọi câu trả lời là một tuyên bố trực tiếp về mức độ đáng tin cậy của sản phẩm của bạn. Một người gọi nghe thấy câu trả lời sai về giá cả hoặc phạm vi bảo hiểm hoặc chính sách, được nói một cách tự tin bằng giọng nói tự nhiên, sẽ không chỉ thất vọng. Họ sẽ cảm thấy bị lừa dối.

Việc thực hiện lời hứa niềm tin có bốn phần.

1. Nguồn sự thật

• Tài liệu của bạn, không phải dữ liệu huấn luyện của mô hình
• Prompt hệ thống phải nói điều này một cách rõ ràng, bằng chữ in hoa: CHỈ TRẢ LỜI TỪ NGỮ CẢNH ĐƯỢC CUNG CẤP
• Mô hình vẫn sẽ trôi về kiến thức chung đôi khi, nhưng hướng dẫn rõ ràng cắt giảm tỷ lệ đó một bậc độ lớn

1. Từ chối nhẹ nhàng

• Khi agent không thể tìm thấy câu trả lời, nó nói trực tiếp
• Cụm từ chính xác rất quan trọng
• "Tôi muốn chắc chắn cung cấp thông tin chính xác cho bạn, hãy để tôi kiểm tra điều đó" mua cho bạn một sự chuyển giao nhẹ nhàng
• "Tôi không chắc" nghe có vẻ kém năng lực
• "Dựa trên thông tin của tôi" nghe có vẻ như một lời lách luật từ luật sư
• Chọn một cụm từ, mã hóa cứng nó, không bao giờ để LLM ứng biến ở đây

1. Phản hồi dựa trên độ tin cậy

• Điểm BM25 cao nhất trên các đoạn được truy xuất là một proxy hữu ích cho độ tin cậy
• Điểm trên 0,6: agent trả lời với sự tự tin
• Điểm 0,3 đến 0,6: agent trả lời nhưng thêm "tôi nghĩ" để thận trọng
• Điểm dưới 0,3: agent không trả lời, đề nghị chuyển
• Thay đổi 20 dòng trong code xây dựng prompt hệ thống. Giảm ảo giác khoảng một nửa.

1. Vệ sinh cơ sở kiến ​​thức

• Tài liệu lỗi thời tạo ra câu trả lời lỗi thời, đó là những câu trả lời nguy hiểm
• Tôi chạy một cuộc kiểm tra vào thứ Sáu: đọc 5% dưới cùng các phản hồi được chấm điểm độ tin cậy trong tuần
• Một nửa thời gian câu trả lời đúng nhưng truy xuất tìm thấy một đoạn lỗi thời
• Cập nhật đoạn đó, nhúng lại, tuần sau yên tĩnh hơn

Những điều cần chú ý

Sáu chế độ thất bại sẽ xảy ra với bạn.

VAD trong pipeline thay vì trong transport

• Vấn đề. Agent kích hoạt trên đầu ra TTS của chính nó, tham gia vào vòng lặp barge-in, hoặc không phát hiện được kết thúc lượt nói hoàn toàn.
• Giải pháp. VAD analyzer đi trên transport. Luôn luôn. Kết hợp nó với một bộ bảo vệ tiếng vang bỏ qua các bản phiên âm STT khớp với đầu ra trợ lý gần đây.

Công cụ có sẵn ở sai trạng thái

• Vấn đề. LLM gọi book_appointment trong trạng thái vẫn đang thu thập tên bệnh nhân. Hoặc tạo ra một đặt chỗ không bao giờ xảy ra.
• Giải pháp. Phạm vi công cụ theo trạng thái. Một trạng thái, chỉ các chức năng của riêng nó. Máy trạng thái là thanh ray an toàn, không phải prompt hệ thống.

Trình xử lý hàm ném lỗi và không bao giờ gọi callback kết quả

• Vấn đề. LLM treo chờ kết quả công cụ không bao giờ đến. Hoặc ảo giác một cái.
• Giải pháp. Mọi trình xử lý đều bọc trong try/except. Mọi nhánh đều gửi kết quả trở lại. Mọi thất bại đều có dự phòng bằng lời nói. Không bao giờ có kết quả trống.

Xác thực dữ liệu người dùng trong prompt thay vì trong code

• Vấn đề. LLM chấp nhận "john@" là email thực trên cuộc gọi 12. Từ chối một email hợp lệ có dấu cộng trên cuộc gọi 47.
• Giải pháp. Xác thực nằm trong Python. Regex cho email, trình phân tích ngày cho ngày tháng, kiểm tra độ dài tên, phản hồi yêu cầu lại khi xác thực thất bại.

Cửa sổ ngữ cảnh phát triển không giới hạn qua một cuộc gọi dài

• Vấn đề. Độ trễ p95 trôi dần lên trong tuần mà không có thay đổi code. Đến lượt 20, bạn đang gửi 12K token mỗi lượt.
• Giải pháp. Cửa sổ trượt N lượt cuối cùng cộng với prompt hệ thống. Hoặc đặt lại ngữ cảnh dựa trên các mốc quan trọng ở cuối mỗi giai đoạn rời rạc.

TTS đọc mã và ID theo nghĩa đen

• Vấn đề. Mã xác nhận "A3X7" được phát âm thành "ay ba ex seven" không có khoảng dừng. Bệnh nhân yêu cầu nhắc lại dù sao.
• Giải pháp. Mở rộng bảng chữ cái ngữ âm NATO với các thẻ ngắt SSML. Nghe chậm hơn. Đọc đúng ngay lần đầu tiên.

Những điều tôi sẽ làm khác đi

• Xây dựng lược đồ turn log vào ngày đầu tiên, không phải tuần thứ tư. Điểm cuối phát lại là công cụ có giá trị nhất tôi đã xây dựng và tôi đã xây dựng nó sau khi tôi cần nó.
• Sử dụng phát hiện kết thúc lượt nói ngữ nghĩa từ đầu thay vì vật lộn với ngưỡng im lặng.
• Chuyển sang máy trạng thái thực sự vào ngày prompt hệ thống vượt quá 300 từ. Đừng cố mã hóa máy trạng thái trong văn xuôi.
• Ngừng xác thực trong prompt. LLM không phải là trình phân tích cú pháp. Python là trình phân tích cú pháp. Sử dụng Python.
• Lưu cache năm tài liệu RAG có khả năng nhất khi bắt đầu cuộc gọi. Bỏ qua tìm kiếm vector trong vòng lặp hội thoại.
• Xây dựng cổng nhỏ (small-talk gate) trước khi bạn xây dựng truy xuất. "Chào" là khoản lợi 200ms rẻ nhất trong hệ thống.
• Chạy bộ đánh giá trước cuộc gọi sản xuất đầu tiên. Tối thiểu 50 cuộc hội thoại.
• Đặt hàng đợi trích xuất bền từ ngày đầu tiên. Một bảng Postgres pending_extractions với một worker retry duy nhất mất 200 dòng và cứu bạn khỏi một sự cố thực sự.
• Chạy một LLM judge không đồng bộ trên mỗi cuộc gọi thứ 50. Cho điểm về tính căn cứ, mức độ liên quan, sự ngắn gọn. Dẫn nó đến một dashboard. Sự trôi dạt là có thật.
• Chạy vòng lặp đánh giá hàng tuần. Lấy mẫu 20 cuộc gọi mỗi thứ Hai. Thực hiện một thay đổi. A/B test. Phát hành phiên bản thắng.

Kết luận

Voice agent trông giống như AI. Chúng chạy như hệ thống thời gian thực.

Các đội phát hành coi chúng như vậy. Các đội phát hành muộn sáu tháng nghĩ rằng một prompt tốt hơn sẽ sửa được vấn đề hệ thống.

Làm chủ pipeline của bạn. Làm chủ log của bạn. Giữ chúng trong các file đơn giản, nơi mọi thất bại chỉ cần phát lại một lần.

Tác nhân đầu tiên tốn của tôi một ngày cuối tuần. Hệ thống sản xuất mất mười tuần. Kể từ đó, nó ngày càng tốt hơn mà tôi không cần động tay vào. Người dùng không đo lường điều đó. Họ nhận thấy tác nhân trả lời "cảm ơn" mà không bắt họ phải chờ đợi.

Tuyên bố miễn trừ và Tiết lộ

Bài viết này do tác giả nghiên cứu và viết, sau đó được chỉnh sửa bởi một mô hình AI. Ảnh bìa được lấy từ Pinterest.

Bài viết này được tác giả nghiên cứu và viết trong quá trình làm việc với các tác nhân giọng nói trên cơ sở hạ tầng sâu hơn.

Nó dựa trên các ghi chú đang phát triển và nghiên cứu chuyên sâu sử dụng Perplexity, Claude và ChatGPT, cùng với thiết kế hệ thống và thiết kế API từ một vài cuốn sách đại học cấp cơ sở.

Nó đã được chỉnh sửa kỹ lưỡng bởi Minimax M2.7 và Claude Opus 4.7 về lỗi ngữ pháp và định dạng.