Tác giả: Rishi Srivastava, Scott Reynolds, Brian Halperin, Brian Yost, Parth Patwa, Smita Bailur, Shreya Mohanty, và Yingwei Yu
Ngày phát hành: 02 FEB 2026
Chuyên mục: Amazon Bedrock, Amazon Connect, Amazon Lex, Amazon Nova, AWS Lambda, Customer Solutions, Healthcare

Bài viết này được đồng tác giả bởi Rishi Srivastava và Scott Reynolds từ Clarus Care.

Nhiều cơ sở y tế hiện nay gặp khó khăn trong việc quản lý hiệu quả lượng lớn cuộc gọi của bệnh nhân. Từ việc lên lịch hẹn và cấp lại đơn thuốc đến các yêu cầu về hóa đơn và các vấn đề y tế khẩn cấp, các cơ sở phải đối mặt với thách thức là cung cấp phản hồi kịp thời trong khi vẫn duy trì chất lượng chăm sóc bệnh nhân. Các hệ thống điện thoại truyền thống thường dẫn đến thời gian chờ đợi lâu, bệnh nhân thất vọng và nhân viên quá tải phải xử lý và ưu tiên hàng trăm cuộc gọi mỗi ngày theo cách thủ công. Những tắc nghẽn giao tiếp này không chỉ ảnh hưởng đến sự hài lòng của bệnh nhân mà còn có thể trì hoãn việc phối hợp chăm sóc quan trọng.

Trong bài viết này, chúng tôi minh họa cách Clarus Care, một nhà cung cấp giải pháp trung tâm liên hệ chăm sóc sức khỏe, đã hợp tác với nhóm AWS Generative AI Innovation Center (GenAIIC) để phát triển một nguyên mẫu trung tâm liên hệ được hỗ trợ bởi AI tạo sinh. Giải pháp này cho phép tương tác đàm thoại và giải quyết đa ý định thông qua một voicebot tự động và giao diện trò chuyện. Nó cũng tích hợp một mô hình dịch vụ có khả năng mở rộng để hỗ trợ tăng trưởng, khả năng chuyển tiếp đến con người – khi được yêu cầu hoặc trong các trường hợp khẩn cấp – và một quy trình phân tích để có được thông tin chi tiết về hiệu suất.

Clarus Care là một công ty công nghệ chăm sóc sức khỏe giúp các cơ sở y tế quản lý giao tiếp với bệnh nhân thông qua hệ thống quản lý cuộc gọi được hỗ trợ bởi AI. Bằng cách tự động phiên âm, ưu tiên và định tuyến tin nhắn của bệnh nhân, Clarus cải thiện thời gian phản hồi, giảm khối lượng công việc của nhân viên và giảm thiểu thời gian chờ. Clarus là công ty quản lý cuộc gọi chăm sóc sức khỏe phát triển nhanh nhất, phục vụ hơn 16.000 người dùng trên hơn 40 chuyên khoa. Công ty xử lý 15 triệu cuộc gọi của bệnh nhân hàng năm và duy trì tỷ lệ giữ chân khách hàng 99%.

Tổng quan về trường hợp sử dụng

Clarus đang bắt tay vào một hành trình đổi mới để chuyển đổi hệ thống giao tiếp với bệnh nhân của họ từ hệ thống Phản hồi giọng nói tương tác (IVR) dựa trên menu truyền thống sang trải nghiệm đàm thoại tự nhiên hơn. Công ty đặt mục tiêu cách mạng hóa cách bệnh nhân tương tác với các nhà cung cấp dịch vụ chăm sóc sức khỏe bằng cách tạo ra một trung tâm liên hệ được hỗ trợ bởi AI tạo sinh có khả năng hiểu và giải quyết nhiều ý định của bệnh nhân trong một tương tác duy nhất. Trước đây, bệnh nhân điều hướng qua các tùy chọn menu cứng nhắc để để lại tin nhắn, sau đó được phiên âm và xử lý. Cách tiếp cận này, mặc dù có chức năng, nhưng hạn chế khả năng của hệ thống trong việc xử lý các nhu cầu phức tạp của bệnh nhân một cách hiệu quả. Nhận thấy nhu cầu về một giải pháp trực quan và linh hoạt hơn, Clarus đã hợp tác với GenAIIC để phát triển một trung tâm liên hệ được hỗ trợ bởi AI có thể hiểu cuộc trò chuyện bằng ngôn ngữ tự nhiên, quản lý nhiều ý định và cung cấp trải nghiệm liền mạch trên cả giao diện thoại và trò chuyện web. Các tiêu chí thành công chính cho dự án là:

• Giao diện thoại ngôn ngữ tự nhiên có khả năng hiểu và xử lý nhiều ý định của bệnh nhân như câu hỏi về hóa đơn, lên lịch và cấp lại đơn thuốc trong một cuộc gọi duy nhất
• Độ trễ ❤ giây cho quá trình xử lý backend và phản hồi cho người dùng
• Khả năng phiên âm, ghi âm và phân tích thông tin cuộc gọi
• Khả năng chuyển tiếp thông minh cho các cuộc gọi khẩn cấp hoặc khi bệnh nhân yêu cầu nói chuyện trực tiếp với nhà cung cấp
• Hỗ trợ cả cuộc gọi thoại và giao diện trò chuyện web để đáp ứng các sở thích khác nhau của bệnh nhân
• Nền tảng có khả năng mở rộng để hỗ trợ cơ sở khách hàng ngày càng tăng của Clarus và mạng lưới cơ sở chăm sóc sức khỏe đang mở rộng
• Tính sẵn sàng cao với yêu cầu SLA 99,99% để tạo điều kiện giao tiếp đáng tin cậy với bệnh nhân

Tổng quan & kiến trúc giải pháp

Nhóm GenAIIC đã hợp tác với Clarus để tạo ra một trung tâm liên hệ được hỗ trợ bởi AI tạo sinh sử dụng Amazon Connect và Amazon Lex, tích hợp với các mô hình nền tảng Amazon Nova và Claude 3.5 Sonnet của Anthropic thông qua Amazon Bedrock. Connect được chọn làm hệ thống cốt lõi nhờ khả năng duy trì tính sẵn sàng 99,99% đồng thời cung cấp các khả năng trung tâm liên hệ toàn diện trên các kênh thoại và trò chuyện.

Tính linh hoạt của mô hình Bedrock là trọng tâm của hệ thống, cho phép lựa chọn mô hình cụ thể theo tác vụ dựa trên độ chính xác và độ trễ. Claude 3.5 Sonnet được sử dụng cho khả năng hiểu ngôn ngữ tự nhiên chất lượng cao, và các mô hình Nova cung cấp khả năng tối ưu hóa cho độ trễ thấp và khả năng hiểu và tạo ngôn ngữ tự nhiên tương đương. Sơ đồ sau minh họa kiến trúc giải pháp cho giải pháp trung tâm liên hệ chính:

Quy trình làm việc bao gồm các bước cấp cao sau:

1. Bệnh nhân bắt đầu liên hệ thông qua giao diện cuộc gọi điện thoại hoặc trò chuyện web.
2. Connect xử lý liên hệ ban đầu và định tuyến nó thông qua một luồng liên hệ đã cấu hình.
3. Lex xử lý phiên âm và duy trì trạng thái cuộc trò chuyện.
4. Một hàm thực hiện AWS Lambda xử lý cuộc trò chuyện bằng cách sử dụng các mô hình Claude 3.5 Sonnet và Nova thông qua Bedrock để:
   a. Phân loại mức độ khẩn cấp và ý định
   b. Trích xuất thông tin cần thiết
   c. Tạo phản hồi tự nhiên
   d. Quản lý việc lên lịch hẹn khi áp dụng

Các mô hình được sử dụng cho mỗi chức năng cụ thể được mô tả trong các phần chi tiết giải pháp.

5. Việc chuyển tiếp thông minh đến nhân viên được bắt đầu khi phát hiện các trường hợp khẩn cấp hoặc khi bệnh nhân yêu cầu nói chuyện với nhà cung cấp.
6. Dữ liệu cuộc trò chuyện được xử lý thông qua một quy trình phân tích để giám sát và báo cáo (được mô tả sau trong bài viết này).

Một số thách thức mà nhóm đã giải quyết trong quá trình phát triển bao gồm:

• Định dạng luồng cuộc gọi trung tâm liên hệ và mô hình dịch vụ theo cách có thể hoán đổi cho các khách hàng khác nhau, với ít thay đổi về mã và cấu hình nhất
• Quản lý các yêu cầu về độ trễ cho trải nghiệm trò chuyện tự nhiên
• Phiên âm và hiểu tên bệnh nhân

Ngoài các cuộc gọi thoại, nhóm đã phát triển một giao diện web sử dụng Amazon CloudFront và Amazon S3 Static Website Hosting để minh họa khả năng đa kênh của hệ thống. Giao diện này cho thấy cách bệnh nhân có thể tham gia vào các cuộc trò chuyện được hỗ trợ bởi AI thông qua một widget trò chuyện, cung cấp cùng mức độ dịch vụ và chức năng như các cuộc gọi thoại. Mặc dù bản demo giao diện web sử dụng cùng một luồng liên hệ như cuộc gọi thoại, nhưng nó có thể được tùy chỉnh thêm cho ngôn ngữ cụ thể của trò chuyện.

Nhóm cũng xây dựng một quy trình phân tích xử lý nhật ký cuộc trò chuyện để cung cấp thông tin chi tiết có giá trị về hiệu suất hệ thống và tương tác của bệnh nhân. Một bảng điều khiển có thể tùy chỉnh cung cấp giao diện thân thiện với người dùng để trực quan hóa dữ liệu này, cho phép cả nhân viên kỹ thuật và phi kỹ thuật thu được thông tin chi tiết có thể hành động từ các giao tiếp của bệnh nhân. Quy trình phân tích và bảng điều khiển được xây dựng bằng cách sử dụng một tài sản trung tâm liên hệ GenAI có thể tái sử dụng đã được xuất bản trước đó.

Chi tiết xử lý cuộc trò chuyện

Giải pháp sử dụng một hệ thống quản lý cuộc trò chuyện tinh vi, điều phối các tương tác tự nhiên của bệnh nhân thông qua khả năng đa mô hình của Bedrock và việc phân lớp prompt được thiết kế cẩn thận. Trọng tâm của hệ thống này là khả năng của Bedrock trong việc cung cấp quyền truy cập vào nhiều mô hình nền tảng, cho phép nhóm chọn mô hình tối ưu cho từng tác vụ cụ thể dựa trên yêu cầu về độ chính xác, chi phí và độ trễ. Luồng của hệ thống quản lý cuộc trò chuyện được hiển thị trong hình ảnh sau; NLU là viết tắt của hiểu ngôn ngữ tự nhiên.

Luồng cuộc trò chuyện bắt đầu bằng lời chào và đánh giá mức độ khẩn cấp. Khi bệnh nhân gọi điện, hệ thống ngay lập tức đánh giá xem tình huống có yêu cầu sự chú ý khẩn cấp hay không bằng cách sử dụng các API của Bedrock. Bước đầu tiên này đảm bảo rằng các trường hợp khẩn cấp được nhanh chóng xác định và định tuyến phù hợp. Hệ thống sử dụng một prompt tập trung phân tích tuyên bố ban đầu của bệnh nhân dựa trên danh sách các danh mục ý định khẩn cấp được xác định trước, trả về “urgent” (khẩn cấp) hoặc “non_urgent” (không khẩn cấp) để hướng dẫn xử lý tiếp theo.

Sau đó, hệ thống chuyển sang phát hiện ý định. Một đổi mới quan trọng ở đây là khả năng của hệ thống trong việc xử lý nhiều ý định trong một tương tác duy nhất. Thay vì buộc bệnh nhân phải điều hướng qua các cây menu cứng nhắc, hệ thống có thể tận dụng các mô hình ngôn ngữ mạnh mẽ để hiểu khi bệnh nhân đề cập đến cả việc cấp lại đơn thuốc và câu hỏi về hóa đơn, xếp hàng các ý định này để xử lý tuần tự trong khi vẫn duy trì luồng trò chuyện tự nhiên. Trong quá trình trích xuất này, chúng tôi đảm bảo rằng cả ý định và trích dẫn từ đầu vào của người dùng đều được trích xuất. Điều này tạo ra hai kết quả:

• Suy luận mô hình tích hợp để đảm bảo ý định chính xác được trích xuất
• Tham chiếu lịch sử cuộc trò chuyện dẫn đến việc trích xuất ý định, để cùng một ý định không được trích xuất hai lần trừ khi được yêu cầu rõ ràng

Khi hệ thống bắt đầu xử lý các ý định theo trình tự, nó bắt đầu nhắc người dùng cung cấp dữ liệu cần thiết để phục vụ ý định hiện tại. Điều này xảy ra trong hai giai đoạn phụ thuộc lẫn nhau:

• Kiểm tra các trường thông tin bị thiếu và tạo một prompt ngôn ngữ tự nhiên để hỏi người dùng thông tin
• Phân tích các phát biểu của người dùng để phân tích và trích xuất các trường đã thu thập và các trường vẫn còn thiếu

Hai bước này diễn ra trong một vòng lặp cho đến khi thông tin cần thiết được thu thập. Hệ thống cũng xem xét các dịch vụ cụ thể của nhà cung cấp ở giai đoạn này, nơi các trường cần thiết cho mỗi nhà cung cấp được thu thập. Giải pháp tự động khớp tên nhà cung cấp được bệnh nhân đề cập với nhà cung cấp chính xác trong hệ thống. Điều này xử lý các biến thể như “Dr. Smith” khớp với “Dr. Jennifer Smith” hoặc “Jenny Smith”, loại bỏ các yêu cầu khớp tên hoặc tiện ích mở rộng cứng nhắc của các hệ thống IVR truyền thống. Giải pháp cũng bao gồm khả năng chuyển giao thông minh. Khi hệ thống cần xác định xem bệnh nhân có nên nói chuyện với một nhà cung cấp cụ thể hay không, nó sẽ phân tích ngữ cảnh cuộc trò chuyện để xem xét mức độ khẩn cấp và nhu cầu định tuyến cho ý định đã được thể hiện. Quá trình này bảo toàn ngữ cảnh cuộc trò chuyện và thông tin đã thu thập, tạo điều kiện cho trải nghiệm liền mạch khi yêu cầu sự can thiệp của con người. Trong suốt cuộc trò chuyện, hệ thống duy trì theo dõi trạng thái toàn diện thông qua các thuộc tính phiên Lex trong khi quá trình xử lý ngôn ngữ tự nhiên diễn ra thông qua các lời gọi mô hình Bedrock. Các thuộc tính này đóng vai trò là bộ nhớ của cuộc trò chuyện, lưu trữ mọi thứ từ thông tin đã thu thập của người dùng và lịch sử cuộc trò chuyện đến các ý định được phát hiện và thông tin đã thu thập. Quản lý trạng thái này cho phép hệ thống duy trì ngữ cảnh trên nhiều lời gọi API Bedrock, tạo ra một luồng đối thoại tự nhiên hơn.

Quản lý ý định

Hệ thống quản lý ý định được thiết kế thông qua cấu trúc mô hình dịch vụ phân cấp phản ánh cách bệnh nhân tự nhiên thể hiện nhu cầu của họ. Để điều hướng mô hình dịch vụ phân cấp này, các đầu vào của người dùng được phân tích cú pháp bằng cách sử dụng hiểu ngôn ngữ tự nhiên, được xử lý thông qua các lời gọi API của Bedrock.

Mô hình dịch vụ phân cấp tổ chức các ý định thành ba cấp độ chính:

1. Cấp độ khẩn cấp: Tách biệt các dịch vụ khẩn cấp khỏi không khẩn cấp để tạo điều kiện xử lý và định tuyến phù hợp.
2. Cấp độ dịch vụ: Nhóm các dịch vụ liên quan như cuộc hẹn, đơn thuốc và hóa đơn tạo ra các danh mục logic.
3. Cấp độ cụ thể của nhà cung cấp: Độ chi tiết hơn nữa để đáp ứng các yêu cầu và dịch vụ phụ cụ thể của nhà cung cấp.

Cấu trúc này cho phép hệ thống điều hướng hiệu quả qua các ý định có thể có trong khi vẫn duy trì tính linh hoạt để tùy chỉnh trên các cơ sở chăm sóc sức khỏe khác nhau. Mỗi ý định trong mô hình bao gồm các hướng dẫn tùy chỉnh có thể được chèn động vào các prompt của Bedrock, cho phép hành vi có thể cấu hình cao mà không cần thay đổi mã. Quá trình trích xuất ý định tận dụng khả năng hiểu ngôn ngữ nâng cao của Bedrock thông qua một prompt hướng dẫn mô hình xác định các ý định có trong đầu vào ngôn ngữ tự nhiên của bệnh nhân. Prompt bao gồm các hướng dẫn toàn diện về những gì cấu thành một ý định mới, danh sách đầy đủ các ý định có thể có và các yêu cầu định dạng cho phản hồi. Thay vì buộc phân loại thành một ý định duy nhất, chúng tôi dự định phát hiện nhiều nhu cầu được thể hiện đồng thời. Khi các ý định được xác định, chúng sẽ được thêm vào hàng đợi xử lý. Hệ thống sau đó xử lý từng ý định theo trình tự, thực hiện các lời gọi mô hình bổ sung trong nhiều lớp để thu thập thông tin cần thiết thông qua cuộc trò chuyện tự nhiên. Để tối ưu hóa cả chất lượng và độ trễ, giải pháp tận dụng tính linh hoạt lựa chọn mô hình của Bedrock cho các tác vụ trò chuyện khác nhau theo cách tương tự:

• Trích xuất ý định sử dụng Claude 3.5 Sonnet của Anthropic thông qua Bedrock để phân tích chi tiết có thể xác định nhiều ý định từ ngôn ngữ tự nhiên, đảm bảo bệnh nhân không cần lặp lại thông tin.
• Thu thập thông tin sử dụng một mô hình nhanh hơn, Amazon Nova Pro, thông qua Bedrock để trích xuất dữ liệu có cấu trúc trong khi vẫn duy trì giọng điệu đàm thoại.
• Tạo phản hồi sử dụng một mô hình nhỏ hơn, Nova Lite, thông qua Bedrock để tạo ra các phản hồi tự nhiên, đồng cảm và có độ trễ thấp dựa trên trạng thái cuộc trò chuyện.

Việc này giúp đảm bảo rằng giải pháp có thể:

• Duy trì giọng điệu đàm thoại và sự đồng cảm
• Chỉ hỏi thông tin cụ thể bị thiếu
• Xác nhận thông tin đã được cung cấp
• Xử lý các trường hợp đặc biệt như đánh vần tên

Toàn bộ quy trình quản lý ý định được hưởng lợi từ API Converse thống nhất của Bedrock, cung cấp:

• Giao diện nhất quán trên các lời gọi mô hình, đơn giản hóa việc phát triển và bảo trì
• Kiểm soát phiên bản mô hình tạo điều kiện cho hành vi ổn định trên các triển khai
• Kiến trúc chống lỗi thời cho phép áp dụng liền mạch các mô hình mới khi chúng có sẵn

Bằng cách triển khai hệ thống quản lý ý định phân cấp này, Clarus có thể cung cấp cho bệnh nhân trải nghiệm giao tiếp tự nhiên và hiệu quả hơn trong khi vẫn duy trì cấu trúc cần thiết để định tuyến và thu thập thông tin phù hợp. Tính linh hoạt của việc kết hợp khả năng đa mô hình của Bedrock với mô hình dịch vụ có thể cấu hình cho phép tùy chỉnh đơn giản cho mỗi cơ sở chăm sóc sức khỏe trong khi vẫn giữ logic cuộc trò chuyện cốt lõi nhất quán và dễ bảo trì. Khi các mô hình mới có sẵn trong Bedrock, hệ thống có thể được cập nhật để tận dụng các khả năng được cải thiện mà không cần thay đổi kiến trúc lớn, tạo điều kiện cho khả năng mở rộng và tối ưu hóa hiệu suất lâu dài.

Lên lịch

Thành phần lên lịch của giải pháp được xử lý trong một mô-đun riêng biệt, được xây dựng có mục đích. Nếu một ý định ‘cuộc hẹn’ được phát hiện trong trình xử lý chính, quá trình xử lý sẽ được chuyển đến mô-đun lên lịch. Mô-đun hoạt động như một máy trạng thái bao gồm các trạng thái cuộc trò chuyện và các bước tiếp theo. Luồng tổng thể của hệ thống lên lịch được hiển thị bên dưới:

Scheduling System Flow
1. Initial State
   - Mention office hours
   - Ask for scheduling preferences
   - Move to GATHERING_PREFERENCES
2. GATHERING_PREFERENCES State
   - Extract and process time preferences using LLM
   - Check time preferences against existing scheduling database
   - Three possible outcomes:
     a. Specific time available
        - Present time for confirmation
        - Move to CONFIRMATION
     b. Range preference
        - Find earliest available time in range
        - Present this time for confirmation
        - Move to CONFIRMATION
     c. No availability (specific or range)
        - Find alternative times (±1 days from requested time)
        - Present available time blocks
        - Ask for preference
        - Stay in GATHERING_PREFERENCES
        - Increment attempt counter
3. CONFIRMATION State
   - Two possible outcomes:
     a. User confirms (Yes)
        - Book appointment
        - Send confirmation message
        - Move to END
     b. User declines (No)
        - Ask for new preferences
        - Move to GATHERING_PREFERENCES
        - Increment attempt counter
4. Additional Features
   - Maximum attempts tracking (default MAX_ATTEMPTS = 3)
   - When max attempts reached:
     - Apologize and escalate to office staff
     - Move to END
5. END State
   - Conversation completed
   - Either with successful booking or escalation to staff

Có ba prompt LLM chính được sử dụng trong luồng lên lịch:

• Trích xuất tùy chọn thời gian (Nova Lite được sử dụng cho độ trễ thấp và hiểu tùy chọn người dùng)

Extract current scheduling preferences from the conversation. The response must be in this format:<reasoning>
Explain:
- What type of preferences were expressed (specific or range)
- How you interpreted any relative dates or times
- Why you structured and prioritized the preferences as you did
- Any assumptions you made
</reasoning>
<json>
[
  {{
    "type": "specific",
    "priority": n,
    "specificSlots": [
      {{
        "date": "YYYY-MM-DD",
        "startTime": "HH:mm",
        "endTime": "HH:mm"
      }}
    ]
  }},
  <!-- Repeat for each distinct preference -->
  {{
    "type": "range",
    "priority": n,
    "dateRange": {{
      "startDate": "YYYY-MM-DD",
      "endDate": "YYYY-MM-DD",
      "daysOfWeek": [], // "m", "t", "w", "th", "f"
      "timeRanges": [
        {{
          "startTime": "HH:mm",
          "endTime": "HH:mm"
        }}
      ]
    }}
  }}
  <!-- Repeat for each distinct preference -->
]
</json>
Guidelines:
- If time preferences have changed throughout the conversation, only extract current preferences
- You may have multiple of the same type of preference if needed
- Ensure proper JSON formatting, the JSON portion of the output should work correctly with json.loads(). Do not include comments in JSON.
- Convert relative dates (tomorrow, next Tuesday) to specific dates
- Keywords:
    * morning: 09:00-12:00
    * afternoon: 12:00-17:00
- Convert time descriptions to specific ranges (e.g. "morning before 11": 09:00-11:00, "2-4 pm": 14:00-16:00)
- Appointments are only available on weekdays from 9:00-17:00
- If no end time is specified for a slot, assume a 30-minute duration
Example:
(Example section removed for brevity)
Now, extract the scheduling preferences from the given conversation.
Current time: {current_time}
Today is {current_day}
Conversation:
<conversation>
{conversation_history}
</conversation>

• Xác định xem người dùng đang xác nhận hay từ chối thời gian (Nova Micro được sử dụng cho độ trễ thấp trên một tác vụ đơn giản)

Determine if the user is confirming or declining the suggested appointment time. Return "true" if they are clearly confirming, "false" otherwise.
<confirm>true|false</confirm>
User message: {user_message}

• Tạo phản hồi tự nhiên dựa trên bước tiếp theo (Nova Lite được sử dụng cho độ trễ thấp và tạo phản hồi)

Given the conversation history and the next step, generate a natural and contextually appropriate response to the user.
Output your response in <response> tags:
<response>Your response here</response>
Conversation history:
{conversation_history}
Next step:
{next_step_prompt}

Các bước có thể là:

• Lời chào ban đầu

Ask the user when they would like to schedule their appointment with {provider}. Do not say Hi or Hello, this is mid-conversation.
Mention that our office hours are {office_hours}.

• Xác nhận thời gian

The time {time} is available with {provider}.
Ask the user to confirm yes or no if this time works for them before proceeding with the booking.
Do not say the appointment is already confirmed.

• Hiển thị các thời gian thay thế

Inform the user that their requested time {requested_time} is not available.
Offer these alternative time or time ranges with {provider}: {blocks}
Ask which time would work best for them.

• Hỏi về các tùy chọn mới

Acknowledge that the suggested time doesn't work for them.
Ask what other day or time they would prefer for their appointment with {provider}.
Remind them that our office hours are {office_hours}.

• Cho người dùng biết bạn sẽ chuyển tiếp đến văn phòng

Apologize that you haven't been able to find a suitable time.
Inform the user that you'll have our office staff reach out to help find an appointment time that works for them.
Thank them for their patience.

• Kết thúc cuộc trò chuyện với xác nhận đặt lịch

VERY BRIEFLY confirm that their appointment is confirmed with {provider} for {time}.
Do not say anything else.
Example: Appointment confirmed for June 5th with Dr. Wolf

Các mở rộng hệ thống

Trong tương lai, Clarus có thể tích hợp voicebot của trung tâm liên hệ với Amazon Nova Sonic. Nova Sonic là một LLM chuyển đổi giọng nói thành giọng nói (speech-to-speech) cung cấp các cuộc trò chuyện thoại giống con người, thời gian thực với hiệu suất giá hàng đầu và độ trễ thấp. Nova Sonic hiện đã được tích hợp trực tiếp với Connect.

Bedrock có một số dịch vụ bổ sung giúp mở rộng giải pháp và triển khai nó vào sản xuất, bao gồm:

• Hỗ trợ gốc cho Retrieval Augmented Generation (RAG) và truy xuất dữ liệu có cấu trúc thông qua Bedrock Knowledge Bases
• Bedrock Guardrails để triển khai các biện pháp bảo vệ nội dung và PII/PHI
• Bedrock Evaluations để đánh giá cuộc trò chuyện tự động và dựa trên con người

Kết luận

Trong bài viết này, chúng tôi đã trình bày cách nhóm GenAIIC hợp tác với Clarus Care để phát triển một trung tâm liên hệ chăm sóc sức khỏe được hỗ trợ bởi AI tạo sinh sử dụng Amazon Connect, Amazon Lex và Amazon Bedrock. Giải pháp này giới thiệu một giao diện thoại đàm thoại có khả năng xử lý nhiều ý định của bệnh nhân, quản lý việc lên lịch hẹn và cung cấp khả năng chuyển tiếp thông minh. Bằng cách tận dụng các mô hình ngôn ngữ Amazon Nova và Claude 3.5 Sonnet của Anthropic cùng các dịch vụ AWS, hệ thống đạt được tính sẵn sàng cao trong khi mang lại trải nghiệm giao tiếp bệnh nhân trực quan và hiệu quả hơn. Giải pháp cũng tích hợp một quy trình phân tích để giám sát chất lượng cuộc gọi và các chỉ số, cũng như một giao diện web minh họa hỗ trợ đa kênh. Kiến trúc của giải pháp cung cấp một nền tảng có khả năng mở rộng có thể thích ứng với cơ sở khách hàng ngày càng tăng của Clarus Care và các dịch vụ trong tương lai. Việc chuyển đổi từ IVR truyền thống dựa trên menu sang giao diện đàm thoại được hỗ trợ bởi AI cho phép Clarus giúp nâng cao trải nghiệm bệnh nhân, tăng khả năng tự động hóa và hợp lý hóa giao tiếp chăm sóc sức khỏe. Khi họ tiến tới triển khai, giải pháp này sẽ trao quyền cho Clarus Care để đáp ứng nhu cầu ngày càng phát triển của cả bệnh nhân và nhà cung cấp dịch vụ chăm sóc sức khỏe trong bối cảnh chăm sóc sức khỏe ngày càng số hóa.

Nếu bạn muốn triển khai một giải pháp tương tự cho trường hợp sử dụng của mình, hãy tham khảo bài viết blog Triển khai các tác nhân AI tạo sinh trong trung tâm liên hệ của bạn cho thoại và trò chuyện bằng Amazon Connect, Amazon Lex và Bedrock Knowledge Bases để thiết lập cơ sở hạ tầng.

Về tác giả

Rishi Srivastava là Phó Chủ tịch Kỹ thuật tại Clarus Care. Ông là một nhà lãnh đạo dày dạn kinh nghiệm trong ngành với hơn 20 năm trong lĩnh vực kỹ thuật phần mềm doanh nghiệp, chuyên về thiết kế kiến trúc SaaS dựa trên Cloud đa người thuê và các giải pháp tác nhân AI đàm thoại liên quan đến tương tác với bệnh nhân. Trước đây, ông làm việc trong lĩnh vực dịch vụ tài chính và tài chính định lượng, xây dựng các mô hình yếu tố tiềm ẩn cho phân tích danh mục đầu tư phức tạp để thúc đẩy các chiến lược đầu tư dựa trên dữ liệu.

Scott Reynolds là Phó Chủ tịch Sản phẩm tại Clarus Care, một nền tảng giao tiếp SaaS chăm sóc sức khỏe và tương tác với bệnh nhân được hỗ trợ bởi AI. Ông đã dành hơn 25 năm trong thị trường công nghệ và phần mềm để tạo ra các nền tảng an toàn, có khả năng tương tác giúp hợp lý hóa quy trình làm việc lâm sàng và vận hành. Ông đã thành lập nhiều công ty khởi nghiệp và sở hữu bằng sáng chế của Hoa Kỳ về công nghệ giao tiếp lấy bệnh nhân làm trung tâm.

Brian Halperin gia nhập AWS vào năm 2024 với tư cách là Chiến lược gia GenAI tại Generative AI Innovation Center, nơi ông giúp khách hàng doanh nghiệp khai thác giá trị kinh doanh mang tính chuyển đổi thông qua trí tuệ nhân tạo. Với hơn 9 năm kinh nghiệm trải dài từ triển khai AI doanh nghiệp đến chuyển đổi công nghệ số, ông mang đến một hồ sơ theo dõi đã được chứng minh về việc chuyển đổi các khả năng AI phức tạp thành kết quả kinh doanh có thể đo lường được. Brian trước đây từng là Phó Chủ tịch trong một nhóm điều hành tại một công ty đầu tư thay thế toàn cầu, dẫn dắt các sáng kiến AI trên các công ty danh mục đầu tư.

Brian Yost là Kiến trúc sư Học sâu Chính tại AWS Generative AI Innovation Center. Ông chuyên áp dụng các khả năng AI tác nhân trong các kịch bản hỗ trợ khách hàng, bao gồm các giải pháp trung tâm liên hệ.

Parth Patwa là Nhà khoa học dữ liệu tại Generative AI Innovation Center thuộc Amazon Web Services. Ông là đồng tác giả của các bài báo nghiên cứu tại các hội nghị AI/ML hàng đầu và có hơn 1500 trích dẫn.

Smita Bailur là Nhà khoa học ứng dụng cấp cao tại AWS Generative AI Innovation Center, nơi cô mang đến hơn 10 năm kinh nghiệm chuyên môn về AI/ML truyền thống, học sâu và AI tạo sinh để giúp khách hàng mở khóa các giải pháp mang tính chuyển đổi. Cô có bằng thạc sĩ Kỹ thuật Điện từ Đại học Pennsylvania.

Shreya Mohanty là Chiến lược gia tại AWS Generative AI Innovation Center, nơi cô chuyên về tùy chỉnh và tối ưu hóa mô hình. Trước đây, cô là Kiến trúc sư Học sâu, tập trung vào việc xây dựng các giải pháp GenAI cho khách hàng. Cô sử dụng nền tảng đa chức năng của mình để chuyển đổi mục tiêu của khách hàng thành các kết quả hữu hình và tác động có thể đo lường được.

Yingwei Yu là Giám đốc Khoa học Ứng dụng tại Generative AI Innovation Center (GenAIIC) thuộc Amazon Web Services (AWS), có trụ sở tại Houston, Texas. Với kinh nghiệm về học máy ứng dụng và AI tạo sinh, Yu dẫn dắt việc phát triển các giải pháp đổi mới trên nhiều ngành công nghiệp khác nhau. Ông có nhiều bằng sáng chế và các ấn phẩm được bình duyệt tại các hội nghị chuyên nghiệp. Yingwei lấy bằng Tiến sĩ Khoa học Máy tính từ Đại học Texas A&M – College Station.