Hành trình xây dựng AI receptionist cho xưởng sửa xe sang - Phần 1

• Đã phát triển AI receptionist ‘Axle’ có thể nghe điện thoại thật để giải quyết tổn thất doanh thu do không trả lời điện thoại tại các xưởng sửa xe cao cấp
• AI được xây dựng dựa trên Retrieval-Augmented Generation (RAG), cung cấp câu trả lời chính xác dựa trên thông tin thực tế về dịch vụ và giá cả được thu thập từ website
• Tích hợp Vapi, Deepgram, ElevenLabs, FastAPI, MongoDB Atlas... để triển khai kết nối điện thoại, nhận dạng/tổng hợp giọng nói và lưu lịch sử hội thoại
• Chất lượng giọng nói được tinh chỉnh với tông tự nhiên và cấu trúc câu ngắn, mang đến phản hồi thân thiện nhưng vẫn chuyên nghiệp cho khách hàng
• Trong tương lai sẽ mở rộng sang hệ thống đặt lịch, thông báo SMS, dashboard callback; với voice agent chuyên biệt cho doanh nghiệp, nền tảng tri thức và thiết kế escalation là yếu tố cốt lõi

---

Quá trình xây dựng AI receptionist

• Đã xây dựng AI receptionist ‘Axle’ tùy chỉnh để giải quyết vấn đề người anh vận hành một xưởng sửa ô tô cao cấp bị mất hàng nghìn USD mỗi tháng vì lỡ cuộc gọi
• Không phải chatbot đơn thuần mà được thiết kế như một voice-based agent có thể nghe điện thoại thật, trả lời các câu hỏi của khách dựa trên thông tin thực tế như giá cả, giờ hoạt động, chính sách...
• Dự án gồm ba giai đoạn: xây dựng knowledge base (pipeline RAG) → kết nối điện thoại và tích hợp server → tinh chỉnh chất lượng giọng nói và tông hội thoại

Bước 1: Xây dựng bộ não (pipeline RAG)

• Sử dụng phương pháp Retrieval-Augmented Generation (RAG) để AI trả lời dựa trên dữ liệu thực tế
  • Nếu chỉ dùng LLM đơn thuần sẽ có nguy cơ hallucination như báo sai giá, nên bị giới hạn chỉ được trả lời dựa trên thông tin thật
• Thu thập hơn 21 tài liệu bằng cách scrape dữ liệu website, bao gồm loại dịch vụ, giá, thời gian thực hiện, giờ hoạt động, phương thức thanh toán, bảo hành, chính sách xe thay thế...
• Lưu knowledge base trong MongoDB Atlas và tạo vector embedding 1024 chiều bằng mô hình Voyage AI (voyage-3-large)
  • Thực hiện tìm kiếm ngữ nghĩa thông qua chỉ mục Atlas Vector Search
• Khi có câu hỏi từ khách, truy vấn được chuyển đổi bằng cùng mô hình embedding để tìm 3 tài liệu tương đồng ngữ nghĩa nhất
• Dùng mô hình Anthropic Claude (claude-sonnet-4-6) để sinh câu trả lời với các tài liệu truy xuất được làm ngữ cảnh
  • Trong system prompt có các quy tắc như “không dùng thông tin ngoài knowledge base, giữ ngắn gọn và mang tính hội thoại, nếu không biết thì đề nghị callback”
• Kết quả là ngay trong terminal, hệ thống có thể trả lời chính xác các câu như “Thay dầu hết bao nhiêu?” bằng giá thực tế và nội dung dịch vụ

Bước 2: Kết nối với số điện thoại thật

• Sử dụng nền tảng Vapi để kết nối bộ não AI với hệ thống điện thoại thật
  • Cung cấp mua số điện thoại, nhận dạng giọng nói dựa trên Deepgram, tổng hợp giọng nói dựa trên ElevenLabs và khả năng gọi hàm theo thời gian thực
• Xây dựng FastAPI webhook server
  • Vapi gửi câu hỏi của khách đến endpoint /webhook dưới dạng yêu cầu tool-calls
  • Server chuyển tiếp yêu cầu này tới pipeline RAG, nhận phản hồi từ Claude rồi gửi lại cho Vapi
  • Cần giảm độ trễ tối đa để duy trì tốc độ hội thoại tự nhiên
• Dùng Ngrok để expose server local ra URL HTTPS bên ngoài, cho phép test thời gian thực ngay trong quá trình phát triển

• Cấu hình Vapi assistant

  • Kết nối lời chào và hai công cụ (answerQuestion, saveCallback) với webhook
  • Có thể trả lời câu hỏi hoặc, nếu không biết, nhận tên và số điện thoại để lưu callback
  • Duy trì ngữ cảnh hội thoại trước đó bằng tính năng conversation memory
  • Có thể xử lý các truy vấn nối tiếp như “Giờ làm việc là thế nào?” → “Vậy thay lốp hết bao nhiêu?”

• Lưu log cuộc gọi vào MongoDB

  • Ghi lại số gọi đến, câu hỏi, câu trả lời, việc có chuyển sang tư vấn viên con người hay không và timestamp
  • Yêu cầu callback được lưu trong collection callbacks riêng để có thể liên hệ lại sau
  • Nhờ đó có thể phân tích mẫu hỏi của khách và lưu lượng cuộc gọi

Bước 3: Tinh chỉnh chất lượng giọng nói

• Cần tối ưu riêng cho truyền đạt bằng giọng nói vì phản hồi dạng văn bản và phản hồi bằng giọng có khác biệt
  • Những câu nghe tự nhiên khi viết ra chưa chắc tự nhiên khi đọc thành tiếng

• Chọn giọng ElevenLabs

  • Sau khi thử khoảng 20 giọng, giọng ‘Christopher’ cho cảm giác tự nhiên nhất và phù hợp với bầu không khí của xưởng sửa xe
  • Những giọng quá giống robot hoặc quá tươi sáng đều không phù hợp

• Chỉnh sửa system prompt

  • Dùng câu ngắn, bỏ Markdown, xóa các cụm không cần thiết như “Câu hỏi hay đấy!”
  • Giá được đọc theo ngôn ngữ tự nhiên (“forty-five dollars”)
  • Mỗi phản hồi bị giới hạn trong 2–4 câu
  • Mục tiêu là tạo ra giọng người thân thiện nhưng chuyên nghiệp

• Test luồng escalation (callback)

  • Với câu hỏi không có trong knowledge base, AI sẽ nói là không biết, xin tên và số điện thoại rồi lưu vào MongoDB
  • Chủ xưởng có thể trực tiếp liên hệ lại sau đó

• Viết kiểm thử tích hợp

  • Kiểm tra pipeline RAG, xử lý webhook và toàn bộ flow
  • Bao gồm cả xử lý edge case như yêu cầu sai, không có kết quả tìm kiếm, thiếu số callback...

Cấu hình tech stack

• Vapi (tích hợp Deepgram & ElevenLabs) — số điện thoại, nhận dạng giọng nói, tổng hợp giọng nói, function calling
• Ngrok — HTTPS tunnel cho phát triển local
• FastAPI + Uvicorn — webhook server
• MongoDB Atlas — knowledge base, vector search, log cuộc gọi, hàng đợi callback
• Voyage AI (voyage-3-large) — text embedding ngữ nghĩa
• Anthropic Claude (claude-sonnet-4-6) — sinh phản hồi dựa trên knowledge base
• Python — cấu thành từ pymongo, voyageai, anthropic, fastapi
• Copilot CLI — công cụ tự động hóa build

Bước tiếp theo

• Hiện AI đã hoàn thành chức năng trả lời câu hỏi và thu thập callback
• Mục tiêu tiếp theo là đặt lịch thời gian thực thông qua tích hợp calendar, thông báo SMS, dashboard quản lý callback, tăng cường bảo mật, triển khai trên Railway
• Khi hoàn thiện, hệ thống có thể hoạt động 24/7 và ngăn thất thoát doanh thu do bỏ lỡ cuộc gọi
• Phần khó nhất không phải code mà là tạo ra tông giọng phù hợp với xưởng sửa xe
• Bài học cốt lõi: không nên dùng raw LLM nguyên trạng cho voice agent chuyên biệt theo doanh nghiệp
  • Bắt buộc phải dựa trên knowledge base thực tế và thiết kế luồng xử lý khi không biết (escalation)
  • Đây không phải ngoại lệ mà là chức năng cốt lõi

[GN⁺]

Ý kiến Hacker News

• Trước đây tôi từng làm service advisor (nhân viên tiếp nhận). Hệ thống trong bài viết nghe có vẻ sẽ không hoạt động được ngoài thực tế

  1. Nếu không có lịch sử sửa chữa tương tự, khả năng báo giá sai là rất cao. Ở một số bang, báo giá sai còn có thể gây rắc rối về mặt pháp lý
  2. Tồn kho và giá phụ tùng thay đổi liên tục. Nếu hệ thống không phản ánh được điều đó thì chỉ gây thêm hỗn loạn
  3. Các công việc mới vốn đã phức tạp ngay từ khâu chọn phụ tùng. Xe càng cao cấp thì càng khó
  4. Phần hữu ích nhất có lẽ chỉ là thông báo nhận xe. Tức là tự động báo khi xe hoàn tất hoặc cập nhật tiến độ
     Kiểu phát triển này không chỉ là ngạo mạn mà còn nguy hiểm. Nếu xây dựng dựa trên giả định mà không kiểm chứng, bạn đang đe dọa kế sinh nhai của người khác
  • Tôi cũng không phải chuyên gia, nhưng rất đồng cảm với kiểu làm màu này. Nếu cần lễ tân thì thuê người có vẻ tự nhiên hơn. Giao công việc kinh doanh cho một giải pháp AI chưa được kiểm chứng là điều khó hiểu. Không rõ là vì ngại quản lý con người hay chỉ đang chạy theo trào lưu
  • Thực ra có một cách đơn giản hơn nhiều. Chỉ cần để người đang làm việc dưới gầm xe có thể nghe điện thoại bằng loa ngoài rảnh tay. Nếu dùng mô hình nhận dạng giọng nói cục bộ thì vẫn có thể nhắc đến công nghệ mạng nơ-ron, mà chi phí kể cả micro cũng chỉ khoảng 200~300 USD
  • Nhưng đọc bài gốc thì có vẻ gara này đã có sẵn các dịch vụ cố định và bảng giá. Vì vậy nếu không cần báo giá tùy chỉnh thì những vấn đề ở trên không áp dụng
  • Gọi nó là “nguy hiểm” có vẻ hơi quá. Tác giả chỉ đang giúp việc kinh doanh của anh trai mình, và dù không hoàn hảo, chỉ cần tăng tỷ lệ chuyển đổi khách hàng thêm 10% thôi cũng đã rất đáng giá
  • Thông báo xe hoàn tất hay cập nhật tiến độ thì các hệ thống TTS đã làm được từ nhiều năm trước rồi. Không nhất thiết phải dùng LLM

• Đại lý Subaru ở khu vực tôi khi đặt lịch qua điện thoại có cho chọn AI assistant. Tôi đã thử và thấy nó hoạt động chính xác, nhanh hơn cả con người. AI đặt món của Taco Bell cũng tốt tương tự. Trong những trường hợp như vậy, không nói chuyện với người thật cũng chẳng thiệt gì, mà nếu cần thì lúc nào cũng có thể chuyển sang người thật

• Những bài blog kiểu này chỉ kể một nửa câu chuyện. Tôi muốn biết doanh thu có tăng thật không, khách hàng có để ý đó là bot không, và đã từng có ca thất bại nào chưa

  • Thực ra những vấn đề này ngay cả trước thời AI cũng đã có thể giải quyết bằng dịch vụ trợ lý ảo. Chỉ khoảng 200~1000 USD mỗi tháng là đủ, và về bản chất là lấy lại doanh thu vốn đang mất. AI chỉ là một cái bẫy chuột phức tạp hơn, còn với dịch vụ cao cấp thì tương tác với con người tạo cảm giác tin cậy hơn nhiều
  • Có lẽ họ vẫn chưa thử nghiệm thực chiến đủ nhiều. Những thứ như địa chỉ email thì LLM khó ghi chép chính xác. Trong phản hồi thoại thời gian thực, Anthropic bị chậm, còn Groq thì rất nhanh, dưới 200ms
  • Trước đây tôi từng cần thay kính xe ô tô gấp, nhưng hệ thống thoại tự động cứ liên tục đòi những thông tin không cần thiết nên tôi cúp máy. Nếu chỉ là đặt lịch đơn giản thì ổn, nhưng trong tình huống đặc biệt thì cuối cùng vẫn phải nói chuyện với con người
  • Cố gắng kiểu này là hợp lý. Chỉ là hiệu năng thực tế vẫn còn chưa rõ. Nó giống một bài thử giấy quỳ để phân biệt người lạc quan AI và người bi quan AI

• Dạo này tôi có cái nhìn khá tích cực với trợ lý điện thoại dùng LLM. Khi gọi lên bộ phận chăm sóc khách hàng của Mint Mobile, LLM hiểu tự nhiên và giải quyết vấn đề cho tôi chỉ trong 1 phút. Bình thường chuyện đó có khi phải đợi hơn 20 phút

  • LLM phát âm rõ ràng, không có tiếng ồn từ tai nghe, và rất dễ hiểu. Tất nhiên cũng có những trường hợp tệ hại như chatbot LLM của eBay, nhưng hệ thống được triển khai tốt thì hoạt động rất xuất sắc
  • Hỗ trợ chat của Amazon cũng tương tự. LLM sắp xếp trước thông tin đơn hàng, còn con người chỉ làm bước phê duyệt cuối cùng. Khá hiệu quả
  • Tuy nhiên, tôi vẫn thắc mắc vì sao những việc đó không giải quyết được ngay trong app mà lại phải dùng LLM. Cuối cùng nó trông giống một thất bại trong quy trình phát triển hơn
  • Tôi cũng từng có trải nghiệm tương tự. Tôi hỏi một câu kỹ thuật thì LLM trả lời chính xác, sau đó nhân viên tư vấn thật tiếp quản nhưng lại kém chuyên môn hơn. Dù vậy vẫn tiết kiệm thời gian
  • Nó tốt hơn rất nhiều so với robot đời cũ, và chatbot dựa trên RAG đủ hữu ích để thay thế việc tra tài liệu. Ví dụ chatbot của manager.io rất tiện vì trả lời ngay thay vì bắt mình đọc tài liệu

• Theo bài viết, gara đang bị mất hàng nghìn USD mỗi tháng vì không nghe máy được. Nếu vậy thì thuê một lễ tân outsourced khoảng 500 USD/tháng sẽ có ROI cao hơn nhiều

  • Thực ra chỉ cần hộp thư thoại cũng có thể giải quyết một phần vấn đề. Dù là AI hay hộp thư thoại thì một số khách hàng vốn dĩ vẫn sẽ cúp máy thôi
  • Hơn nữa, nếu họ đã quá bận đến mức không nghe nổi điện thoại thì rất có thể ngay cả khi có thêm khách cũng không đủ năng lực xử lý
  • Bạn tôi dùng dịch vụ lễ tân outsourced, chỉ 150 bảng/tháng là họ trực từ 9 giờ đến 5 giờ. Tối đến thì bạn tôi chỉ việc sắp xếp lịch. Nếu những gì bài viết nói là đúng thì gara đó hẳn đã hoạt động ở 100% công suất rồi
  • Một service writer giỏi thì đắt thật, nhưng hoàn toàn xứng đáng. Họ xây dựng được niềm tin với khách hàng, và về sau thậm chí còn có thể tiếp quản luôn doanh nghiệp
  • Cuối cùng thì ROI ở đây có vẻ chỉ là hiệu ứng quảng bá cho khóa học AI mà blog đang muốn bán

• Giờ mà tôi cảm thấy mình đang nói chuyện với robot là tôi cúp máy ngay. Nhưng chắc chẳng bao lâu nữa giọng AI sẽ đạt đến mức không phân biệt được với người thật. Khi đó niềm tin vào điện thoại có thể sụp đổ. Email và LinkedIn đã tràn ngập spam do AI tạo ra nên người ta mới chuyển sang điện thoại, nhưng có lẽ rồi kênh này cũng sẽ mất luôn

  • Dù sao nếu bị chuyển sang hộp thư thoại thì tôi cũng sẽ cúp máy, nên cũng chẳng khác gì
  • Nếu AI hiểu sai ý tôi rồi cuối cùng vẫn phải chuyển sang người thật, tôi sẽ phải kể lại cùng một câu chuyện hai lần, rất mệt
  • Gần đây tôi có tìm hiểu mua xe và liên hệ với vài đại lý, đến sau này mới nhận ra tất cả đều là nhân viên tư vấn tên giả dùng LLM. Tốc độ phản hồi nhanh quá nên thấy rất lạ

• Họ nói “đây không phải chatbot đa dụng”, nhưng thực chất nó chỉ là chatbot đa dụng phiên bản năm 2026 mà thôi

• Tôi vào trang “About” của blog thì thấy tác giả nói mình được truyền cảm hứng từ một influencer kiểu học code rồi giàu lên. Nhưng thái độ như vậy khá xa với hướng đi của văn hóa kỹ sư mà tôi mong muốn

• Việc mọi người dùng AI để viết blog cá nhân khiến tôi thấy hơi buồn

  • Dù vậy tôi vẫn đánh giá cao việc họ nói thẳng điều đó. Phần lớn mọi người vốn không có nhiều kinh nghiệm viết lách, và nghĩ rằng dùng LLM sẽ cho ra “bài viết hay”. Có thể với họ, văn bản do AI viết không hề mang lại cảm giác tệ

• Ở đây có thật sự cần RAG không? Nếu chỉ là bảng giá và giờ mở cửa thì hoàn toàn nằm gọn trong context window

  • Có lẽ đây là một dự án để học tập. Tôi cũng từng học bằng cách dùng kiến trúc quá mức cần thiết trong các dự án cá nhân
  • Với hội thoại giọng nói thì độ trễ (latency) mới là vấn đề lớn hơn. Nếu website có nhiều trang thì dùng RAG để tải nhanh một phần rồi để LLM tạo câu trả lời chi tiết có thể sẽ hiệu quả hơn
  • Cứ đưa toàn bộ website và bảng giá vào context có khi còn đơn giản hơn
  • Tôi cũng đồng ý. Lượng thông tin cỡ này hoàn toàn xử lý một lần được
  • Nhìn chung thì kiến trúc này là quá đà