Tác giả: Johann Wildgruber, Dr. Jens Kohl, Thilo Bindel, Luisa-Sophie Gloger, Aishwarya Lakshmi Krishnan, Huong Vu, Kim Robins, Otto Kruse, Satyam Saxena, và Tanrajbir Takher Ngày đăng: 06/03/2025 Danh mục: Advanced (300), Amazon Bedrock, Amazon Bedrock Agents, Amazon CloudWatch, Artificial Intelligence, AWS CloudTrail, Customer Enablement, Customer Solutions

Bài viết này được đồng tác giả bởi Johann Wildgruber, Dr. Jens Kohl, Thilo Bindel, và Luisa-Sophie Gloger từ Tập đoàn BMW.

Tập đoàn BMW—có trụ sở chính tại Munich, Đức—là nhà sản xuất xe hơi với hơn 154.000 nhân viên, 30 cơ sở sản xuất và lắp ráp trên toàn thế giới, cùng các địa điểm nghiên cứu và phát triển tại 17 quốc gia. Hiện nay, Tập đoàn BMW (BMW) là nhà sản xuất xe hơi và xe máy hạng sang hàng đầu thế giới, đồng thời cung cấp các dịch vụ tài chính và di động cao cấp.

BMW Connected Company là một bộ phận thuộc BMW chịu trách nhiệm phát triển và vận hành các dịch vụ kỹ thuật số cao cấp cho đội xe kết nối của BMW, hiện có số lượng hơn 23 triệu xe trên toàn thế giới. Các dịch vụ kỹ thuật số này được nhiều chủ xe BMW sử dụng hàng ngày; ví dụ: để khóa hoặc mở cửa xe từ xa bằng ứng dụng trên điện thoại, khởi động hệ thống sưởi kính từ xa, mua các bản cập nhật bản đồ định vị từ menu của xe, hoặc nghe nhạc trực tuyến trong xe.

Trong bài viết này, chúng tôi giải thích cách BMW sử dụng công nghệ AI tạo sinh trên AWS để giúp vận hành các dịch vụ kỹ thuật số này với tính sẵn sàng cao. Cụ thể, BMW sử dụng Amazon Bedrock Agents để giúp khắc phục các sự cố ngừng hoạt động dịch vụ (một phần) nhanh hơn bằng cách tăng tốc quá trình phân tích nguyên nhân gốc rễ (Root Cause Analysis – RCA) vốn rườm rà và tốn thời gian. Tác nhân RCA tự động hoàn toàn đã xác định chính xác nguyên nhân gốc rễ cho hầu hết các trường hợp (đo lường được ở mức 85%), và giúp các kỹ sư hiểu rõ hệ thống cũng như có được những thông tin chi tiết theo thời gian thực về các trường hợp của họ. Hiệu suất này đã được xác nhận thêm trong quá trình thử nghiệm (PoC), nơi việc áp dụng tác nhân RCA vào các trường hợp sử dụng tiêu biểu đã chứng minh rõ ràng lợi ích của giải pháp này, cho phép BMW giảm đáng kể thời gian chẩn đoán.

Những thách thức của việc phân tích nguyên nhân gốc rễ

Các dịch vụ kỹ thuật số thường được triển khai bằng cách liên kết nhiều thành phần phần mềm với nhau; những thành phần này có thể được xây dựng và vận hành bởi các đội ngũ khác nhau. Ví dụ, hãy xem xét dịch vụ mở và khóa cửa xe từ xa. Có thể có một đội phát triển xây dựng và vận hành ứng dụng iOS, một đội khác cho ứng dụng Android, một đội xây dựng và vận hành backend-for-frontend được cả ứng dụng iOS và Android sử dụng, v.v. Hơn nữa, các đội này có thể phân tán về mặt địa lý và vận hành tải công việc của họ ở các địa điểm và vùng (region) khác nhau; nhiều đội lưu trữ trên AWS, một số ở nơi khác.

Bây giờ hãy xem xét một kịch bản (giả định) khi có báo cáo từ các chủ xe phàn nàn rằng việc khóa cửa từ xa bằng ứng dụng không còn hoạt động. Ứng dụng iOS chịu trách nhiệm cho sự cố, hay backend-for-frontend? Có quy tắc tường lửa (firewall rule) nào bị thay đổi ở đâu đó không? Có chứng chỉ TLS nội bộ nào bị hết hạn không? Hệ thống MQTT có đang bị chậm trễ không? Có thay đổi gây lỗi (breaking change) vô ý nào trong các cập nhật API gần đây không? Họ thực sự đã triển khai (deploy) nó khi nào? Hay mật khẩu cơ sở dữ liệu cho dịch vụ đăng ký trung tâm lại vừa được thay đổi (rotate)?

Rất khó để xác định nguyên nhân gốc rễ của các vấn đề trong những tình huống như thế này. Nó đòi hỏi phải kiểm tra nhiều hệ thống và đội nhóm, nhiều trong số đó có thể đang gặp lỗi vì chúng phụ thuộc lẫn nhau. Các kỹ sư cần lập luận về kiến trúc hệ thống, đưa ra giả thuyết và lần theo chuỗi các thành phần cho đến khi tìm thấy thành phần gây ra lỗi. Họ thường phải quay lại từ đầu và đánh giá lại các giả thuyết của mình, rồi tiến hành điều tra trong một chuỗi các thành phần khác.

Việc hiểu rõ những thách thức trong các hệ thống phức tạp như vậy nhấn mạnh nhu cầu về một phương pháp phân tích nguyên nhân gốc rễ mạnh mẽ và hiệu quả. Với bối cảnh đó, hãy cùng khám phá cách BMW và AWS hợp tác để phát triển một giải pháp sử dụng Amazon Bedrock Agents nhằm tinh gọn và nâng cao quy trình RCA.

Tổng quan giải pháp

Ở mức độ tổng quát, giải pháp sử dụng một tác nhân Amazon Bedrock để thực hiện RCA tự động. Tác nhân này có sẵn một số công cụ được xây dựng tùy chỉnh để thực hiện nhiệm vụ của mình. Các công cụ này, được triển khai bởi các hàm AWS Lambda, sử dụng các dịch vụ như Amazon CloudWatch và AWS CloudTrail để phân tích log hệ thống và các chỉ số (metrics). Sơ đồ sau đây minh họa kiến trúc giải pháp.

Khi một sự cố xảy ra, một kỹ sư trực ca (on-call) sẽ đưa ra mô tả về vấn đề đang gặp phải cho tác nhân Amazon Bedrock. Sau đó, tác nhân sẽ bắt đầu điều tra nguyên nhân gốc rễ của vấn đề, sử dụng các công cụ của nó để thực hiện các nhiệm vụ mà kỹ sư trực ca thông thường phải làm thủ công, chẳng hạn như tìm kiếm qua các log. Dựa trên những manh mối tìm được, tác nhân sẽ đề xuất một vài giả thuyết khả thi nhất cho kỹ sư trực ca. Sau đó, kỹ sư có thể giải quyết vấn đề hoặc đưa ra các chỉ dẫn cho tác nhân để tiếp tục điều tra sâu hơn. Trong phần tiếp theo, chúng ta sẽ xem xét kỹ hơn các công cụ mà tác nhân sử dụng.

Các công cụ của tác nhân Amazon Bedrock

Hiệu quả của tác nhân Amazon Bedrock trong việc thực hiện RCA nằm ở khả năng tích hợp liền mạch với các công cụ tùy chỉnh. Các công cụ này, được thiết kế dưới dạng các hàm Lambda, sử dụng các dịch vụ AWS như CloudWatch và CloudTrail để tự động hóa các nhiệm vụ thường là thủ công và tốn thời gian đối với các kỹ sư. Bằng cách tổ chức các khả năng của mình vào các công cụ chuyên biệt, tác nhân Amazon Bedrock đảm bảo rằng quá trình RCA diễn ra hiệu quả và chính xác.

Công cụ Kiến trúc (Architecture Tool)

Công cụ Kiến trúc sử dụng sơ đồ C4 để cung cấp cái nhìn toàn diện về kiến trúc hệ thống. Các sơ đồ này, được tăng cường thông qua Structurizr, giúp tác nhân hiểu theo phân cấp về các mối quan hệ thành phần, sự phụ thuộc và quy trình làm việc. Điều này cho phép tác nhân nhắm mục tiêu vào các khu vực phù hợp nhất trong quá trình RCA, thu hẹp hiệu quả các nguyên nhân tiềm ẩn gây lỗi dựa trên cách các hệ thống khác nhau tương tác.

Ví dụ, nếu một vấn đề ảnh hưởng đến một dịch vụ cụ thể, Công cụ Kiến trúc có thể xác định các phụ thuộc ngược dòng (upstream) hoặc xuôi dòng (downstream) và gợi ý các giả thuyết tập trung vào các hệ thống đó. Điều này giúp đẩy nhanh quá trình chẩn đoán bằng cách cho phép tác nhân lập luận theo ngữ cảnh về kiến trúc thay vì tìm kiếm mù quáng qua các log hoặc chỉ số.

Công cụ Log (Logs Tool)

Công cụ Log sử dụng CloudWatch Logs Insights để phân tích dữ liệu log theo thời gian thực. Bằng cách tìm kiếm các mẫu (patterns), lỗi hoặc các điểm bất thường, cũng như so sánh xu hướng với giai đoạn trước đó, nó giúp tác nhân xác định các vấn đề liên quan đến các sự kiện cụ thể, chẳng hạn như xác thực thất bại hoặc treo hệ thống.

Ví dụ, trong một kịch bản liên quan đến lỗi truy cập cơ sở dữ liệu, Công cụ Log có thể xác định một sự gia tăng đột biến số lượng thông báo lỗi như “FATAL: password authentication failed” so với giờ trước đó. Thông tin này cho phép tác nhân nhanh chóng liên kết lỗi với các nguyên nhân gốc rễ tiềm ẩn, chẳng hạn như mật khẩu cơ sở dữ liệu được thay đổi không đúng cách.

Công cụ Chỉ số (Metrics Tool)

Công cụ Chỉ số cung cấp cho tác nhân những thông tin theo thời gian thực về sức khỏe của hệ thống bằng cách giám sát các chỉ số chính thông qua CloudWatch. Công cụ này xác định các điểm bất thường về thống kê trong các chỉ số hiệu suất quan trọng như độ trễ (latency), tỷ lệ lỗi (error rates), việc sử dụng tài nguyên hoặc các đợt tăng đột biến bất thường trong mô hình sử dụng, những dấu hiệu thường báo hiệu các vấn đề tiềm ẩn hoặc sự sai lệch so với hành vi bình thường.

Chẳng hạn, trong kịch bản quá tải bộ nhớ Kubernetes, Công cụ Chỉ số có thể phát hiện sự gia tăng mạnh trong tiêu thụ bộ nhớ hoặc phân bổ tài nguyên bất thường trước khi xảy ra lỗi. Bằng cách hiển thị các cảnh báo (alarms) chỉ số CloudWatch cho những điểm bất thường đó, công cụ cho phép tác nhân ưu tiên các giả thuyết liên quan đến việc quản lý tài nguyên sai, cấu hình ngưỡng không đúng hoặc tải hệ thống ngoài dự kiến, hướng dẫn cuộc điều tra hiệu quả hơn về phía giải quyết vấn đề.

Công cụ Cơ sở hạ tầng (Infrastructure Tool)

Công cụ Cơ sở hạ tầng sử dụng dữ liệu CloudTrail để phân tích các sự kiện mặt bằng điều khiển (control-plane) quan trọng, chẳng hạn như thay đổi cấu hình, cập nhật nhóm bảo mật (security group) hoặc các lệnh gọi API. Công cụ này đặc biệt hiệu quả trong việc xác định các lỗi cấu hình hoặc các thay đổi gây lỗi có thể kích hoạt các thất bại liên tiếp (cascading failures).

Hãy xem xét trường hợp một quy tắc đầu vào (ingress rule) của nhóm bảo mật bị vô ý xóa bỏ, gây ra các vấn đề kết nối giữa các dịch vụ. Công cụ Cơ sở hạ tầng có thể phát hiện và liên kết sự kiện này với sự cố được báo cáo, cung cấp cho tác nhân các thông tin chi tiết có thể hành động để dẫn dắt quy trình RCA của nó.

Bằng cách kết hợp các công cụ này, tác nhân Amazon Bedrock mô phỏng quá trình lập luận từng bước của một kỹ sư dày dạn kinh nghiệm trong khi thực hiện các nhiệm vụ với tốc độ của máy móc. Tính mô-đun của các công cụ cho phép sự linh hoạt và tùy chỉnh, đảm bảo rằng RCA được điều chỉnh phù hợp với nhu cầu độc nhất của cơ sở hạ tầng đám mây đa vùng, phức tạp của BMW.

Trong phần tiếp theo, chúng ta sẽ thảo luận về cách các công cụ này phối hợp với nhau trong quy trình làm việc của tác nhân.

Amazon Bedrock Agents: Khung làm việc ReAct trong thực tế

Trọng tâm của quy trình RCA nhanh chóng của BMW nằm ở khung làm việc tác nhân ReAct (Reasoning and Action – Lập luận và Hành động), một phương pháp sáng tạo kết hợp linh hoạt lập luận logic với thực thi nhiệm vụ. Bằng cách tích hợp ReAct với Amazon Bedrock, BMW có được một giải pháp linh hoạt để chẩn đoán và giải quyết các sự cố phức tạp trên đám mây. Khác với các phương pháp truyền thống dựa trên các quy trình làm việc được xác định trước, các tác nhân ReAct sử dụng dữ liệu đầu vào theo thời gian thực và việc ra quyết định lặp lại để thích ứng với hoàn cảnh cụ thể của một sự cố.

Tác nhân ReAct trong giải pháp RCA của BMW sử dụng một quy trình làm việc có cấu trúc nhưng dễ thích nghi để chẩn đoán và giải quyết vấn đề. Đầu tiên, nó diễn giải mô tả văn bản của một sự cố (ví dụ: “Không thể khóa cửa xe qua ứng dụng”) để xác định bộ phận nào của hệ thống có khả năng bị ảnh hưởng cao nhất. Được hướng dẫn bởi lập luận lặp lại của khung làm việc ReAct, tác nhân sau đó thu thập bằng chứng bằng cách gọi các công cụ chuyên dụng, sử dụng dữ liệu được tập hợp tập trung trong một thiết lập khả năng quan sát xuyên tài khoản (cross-account observability setup). Bằng cách liên tục đánh giá lại kết quả của mỗi lần gọi công cụ, tác nhân tập trung vào các nguyên nhân tiềm ẩn—cho dù là chứng chỉ hết hạn, quy tắc tường lửa bị thu hồi hay lưu lượng truy cập tăng đột biến—cho đến khi cô lập được nguyên nhân gốc rễ. Sơ đồ sau đây minh họa quy trình làm việc này.

Khung làm việc ReAct mang lại các lợi ích sau:

• Năng động và thích ứng – Tác nhân ReAct điều chỉnh phương pháp của mình cho phù hợp với sự cố cụ thể, thay vì sử dụng một phương pháp chung cho tất cả. Khả năng thích ứng này đặc biệt quan trọng trong kiến trúc đa vùng, đa dịch vụ của BMW.
• Sử dụng công cụ hiệu quả – Bằng cách lập luận về việc nên gọi công cụ nào và khi nào, tác nhân ReAct giảm thiểu các truy vấn dư thừa, cung cấp chẩn đoán nhanh hơn mà không làm quá tải các dịch vụ AWS như CloudWatch hoặc CloudTrail.
• Lập luận giống con người – Tác nhân ReAct mô phỏng quá trình suy nghĩ logic của một kỹ sư dày dạn kinh nghiệm, lặp đi lặp lại việc khám phá các giả thuyết cho đến khi xác định được nguyên nhân gốc rễ. Khả năng này lấp đầy khoảng cách giữa tự động hóa và chuyên môn của con người.

Bằng cách sử dụng các tác nhân Amazon Bedrock ReAct, thời gian chẩn đoán đạt được thấp hơn đáng kể. Các tác nhân này không chỉ nâng cao hiệu quả vận hành mà còn giúp các kỹ sư tập trung vào các cải tiến chiến lược thay vì các chẩn đoán tốn nhiều công sức.

Nghiên cứu điển hình: Phân tích nguyên nhân gốc rễ “Mở khóa xe qua ứng dụng iOS”

Để minh họa sức mạnh của các tác nhân Amazon Bedrock trong thực tế, hãy cùng khám phá một kịch bản thực tế có thể xảy ra liên quan đến sự tương tác giữa đội xe kết nối của BMW và các dịch vụ kỹ thuật số chạy trên backend đám mây.

Chúng tôi cố ý thay đổi nhóm bảo mật cho tài khoản mạng trung tâm trong một môi trường thử nghiệm. Điều này có tác dụng là các yêu cầu từ đội xe bị chặn (một cách chính xác) bởi nhóm bảo mật đã thay đổi và không đến được các dịch vụ được lưu trữ ở backend. Do đó, một người dùng thử nghiệm không thể khóa hoặc mở khóa cửa xe của mình từ xa.

Chi tiết sự cố

Các kỹ sư BMW nhận được báo cáo từ một người thử nghiệm cho biết chức năng khóa/mở khóa từ xa trên ứng dụng di động không hoạt động. Báo cáo này đặt ra những câu hỏi tức thì: vấn đề nằm ở bản thân ứng dụng, dịch vụ backend-for-frontend, hay sâu hơn trong hệ thống, chẳng hạn như trong kết nối MQTT hoặc các cơ chế xác thực?

Cách tác nhân ReAct giải quyết vấn đề

Vấn đề được mô tả cho tác nhân Amazon Bedrock ReAct: “Người dùng ứng dụng iOS không thể mở khóa cửa xe từ xa.” Tác nhân ngay lập tức bắt đầu phân tích:

1. Tác nhân bắt đầu bằng việc tìm hiểu kiến trúc hệ thống tổng thể, gọi Công cụ Kiến trúc. Đầu ra của công cụ kiến trúc tiết lộ rằng ứng dụng iOS, giống như ứng dụng Android, được kết nối với một API backend-for-frontend, và bản thân API backend-for-frontend này được kết nối với một vài API nội bộ khác, chẳng hạn như API Remote Vehicle Management. API Remote Vehicle Management chịu trách nhiệm gửi các lệnh đến xe bằng cách sử dụng tin nhắn MQTT.
2. Tác nhân sử dụng các công cụ khác theo cách có mục tiêu: nó quét các log, chỉ số và hoạt động mặt bằng điều khiển chỉ của những thành phần liên quan đến việc mở khóa xe từ xa: log từ xa của ứng dụng iOS, log API backend-for-frontend, v.v. Tác nhân tìm thấy một số manh mối:
   • Log bất thường chỉ ra các vấn đề kết nối (timeout mạng).
   • Sự sụt giảm mạnh số lượng các lần gọi thành công API Remote Vehicle Management.
   • Hoạt động mặt bằng điều khiển: một số nhóm bảo mật trong tài khoản mạng trung tâm được lưu trữ trên môi trường thử nghiệm đã bị thay đổi.

3. Dựa trên những phát hiện đó, tác nhân suy luận và xác định một vài giả thuyết và trình bày chúng cho người dùng, sắp xếp theo khả năng xảy ra. Trong trường hợp này, giả thuyết đầu tiên chính là nguyên nhân gốc rễ thực sự: một nhóm bảo mật đã vô ý bị thay đổi trong tài khoản mạng trung tâm, điều đó có nghĩa là lưu lượng mạng giữa backend-for-frontend và API Remote Vehicle Management hiện đã bị chặn. Tác nhân đã liên kết chính xác các log (“lỗi fetch timeout”), chỉ số (giảm số lần gọi) và các thay đổi mặt bằng điều khiển (quy tắc ingress của nhóm bảo mật bị xóa) để đi đến kết luận này.

4. Nếu kỹ sư trực ca muốn biết thêm thông tin, họ có thể đặt các câu hỏi tiếp theo cho tác nhân, hoặc hướng dẫn tác nhân điều tra thêm ở những nơi khác.

Toàn bộ quy trình—từ phát hiện sự cố đến giải quyết—mất vài phút, so với hàng giờ nếu sử dụng các phương pháp RCA truyền thống. Khả năng lập luận linh hoạt của tác nhân ReAct, truy cập dữ liệu quan sát xuyên tài khoản và lặp lại trên các giả thuyết của nó đã giảm bớt nhu cầu cho các cuộc điều tra thủ công tẻ nhạt.

Kết luận

Bằng cách sử dụng các tác nhân Amazon Bedrock ReAct, BMW đã cho thấy cách cải thiện phương pháp phân tích nguyên nhân gốc rễ, biến một quy trình phức tạp và thủ công thành một quy trình làm việc tự động và hiệu quả. Các công cụ tích hợp trong khung làm việc ReAct thu hẹp đáng kể không gian lập luận tiềm ẩn, đồng thời cho phép tạo giả thuyết linh hoạt và chẩn đoán có mục tiêu, mô phỏng quá trình lập luận của các kỹ sư dày dạn kinh nghiệm trong khi vận hành với tốc độ máy móc. Sự đổi mới này đã giảm thời gian cần thiết để xác định và giải quyết các gián đoạn dịch vụ, nâng cao hơn nữa độ tin cậy của các dịch vụ kết nối của BMW và cải thiện trải nghiệm cho hàng triệu khách hàng trên toàn thế giới.

Giải pháp đã chứng minh được thành công có thể đo lường, với việc tác nhân xác định được nguyên nhân gốc rễ trong 85% các trường hợp thử nghiệm và cung cấp thông tin chi tiết trong các trường hợp còn lại, giúp đẩy nhanh đáng kể các cuộc điều tra của kỹ sư. Bằng cách hạ thấp rào cản gia nhập cho các kỹ sư trẻ, nó đã cho phép các thành viên có ít kinh nghiệm hơn trong đội ngũ chẩn đoán các vấn đề một cách hiệu quả, duy trì độ tin cậy và khả năng mở rộng trên toàn bộ hoạt động của BMW.

Việc kết hợp AI tạo sinh vào các quy trình RCA cho thấy tiềm năng thay đổi của AI trong các hoạt động trên đám mây hiện đại. Khả năng thích ứng linh hoạt, lập luận theo ngữ cảnh và xử lý các cơ sở hạ tầng đa vùng phức tạp khiến Amazon Bedrock Agents trở thành một yếu tố thay đổi cuộc chơi cho các tổ chức mong muốn duy trì tính sẵn sàng cao trong các dịch vụ kỹ thuật số của họ.

Khi BMW tiếp tục mở rộng đội xe kết nối và các dịch vụ kỹ thuật số, việc áp dụng các giải pháp thúc đẩy bởi AI tạo sinh như Amazon Bedrock sẽ đóng vai trò quan trọng trong việc duy trì sự vận hành xuất sắc và mang lại trải nghiệm liền mạch cho khách hàng. Bằng cách làm theo ví dụ của BMW, tổ chức của bạn cũng có thể hưởng lợi từ Amazon Bedrock Agents cho việc phân tích nguyên nhân gốc rễ để nâng cao độ tin cậy của dịch vụ.

Hãy bắt đầu bằng cách khám phá Amazon Bedrock Agents để tối ưu hóa chẩn đoán sự cố của bạn hoặc sử dụng CloudWatch Logs Insights để xác định các điểm bất thường trong log hệ thống. Nếu bạn muốn có một phần giới thiệu thực hành về việc tạo các tác nhân Amazon Bedrock của riêng mình—kèm theo các ví dụ mã và thực hành tốt nhất—hãy xem kho lưu trữ GitHub sau. Những công cụ này đang thiết lập một tiêu chuẩn công nghiệp mới cho RCA hiệu quả và vận hành xuất sắc.

---

Tác giả

Johann Wildgruber là kỹ sư trưởng về chuyển đổi độ tin cậy tại Tập đoàn BMW, hiện đang làm việc để thiết lập một nền tảng quan sát nhằm tăng cường độ tin cậy cho các dịch vụ ConnectedDrive. Johann có nhiều năm kinh nghiệm với tư cách là chủ sở hữu sản phẩm trong việc vận hành và phát triển các giải pháp đám mây lớn và phức tạp. Anh quan tâm đến việc áp dụng các công nghệ và phương pháp mới trong phát triển phần mềm.

Dr. Jens Kohl là một nhà lãnh đạo công nghệ và nhà xây dựng với hơn 13 năm kinh nghiệm tại Tập đoàn BMW. Anh chịu trách nhiệm định hình kiến trúc và tối ưu hóa liên tục backend đám mây cho Xe kết nối (Connected Vehicle). Jens đã dẫn dắt các đội phát triển phần mềm và machine learning tập trung vào các hệ thống nhúng, phân tán và machine learning trong hơn 10 năm.

Thilo Bindel đang dẫn dắt đội ngũ Offboard Reliability & Data Engineering tại Tập đoàn BMW. Anh chịu trách nhiệm xác định và thực hiện các chiến lược để đảm bảo độ tin cậy, tính sẵn sàng và khả năng bảo trì của các dịch vụ backend BMW trong lĩnh vực Xe kết nối. Mục tiêu của anh là thiết lập các thực hành tốt nhất về độ tin cậy và kỹ thuật dữ liệu một cách nhất quán trong toàn tổ chức và đưa Tập đoàn BMW trở thành người dẫn đầu về khả năng quan sát dựa trên dữ liệu trong ngành ô tô và xa hơn nữa.

Luisa-Sophie Gloger là một Nhà khoa học Dữ liệu (Data Scientist) tại Tập đoàn BMW tập trung vào Machine Learning. Với tư cách là nhà phát triển chính trong đội ngũ nền tảng AI kết nối của Connected Company, cô thích giúp đỡ các đội ngũ cải thiện sản phẩm và quy trình làm việc của họ bằng AI tạo sinh. Cô cũng có nền tảng làm việc về Xử lý Ngôn ngữ Tự nhiên (NLP) và bằng cấp về tâm lý học.

Tanrajbir Takher là một Nhà khoa học Dữ liệu tại Trung tâm Đổi mới AI tạo sinh của AWS, nơi anh làm việc với các khách hàng doanh nghiệp để triển khai các giải pháp AI tạo sinh có tác động cao. Trước khi gia nhập AWS, anh đã dẫn dắt nghiên cứu cho các sản phẩm mới tại một công ty kỳ lân về thị giác máy tính và sáng lập một startup về AI tạo sinh giai đoạn đầu.

Otto Kruse là một Nhà phát triển Giải pháp Chính (Principal Solutions Developer) tại AWS Industries – Prototyping and Customer Engineering (PACE), một đội ngũ đa ngành chuyên giúp đỡ các công ty lớn tận dụng tiềm năng của đám mây AWS bằng cách khám phá và triển khai các ý tưởng đổi mới. Otto tập trung vào phát triển ứng dụng và bảo mật.

Huong Vu là một Nhà khoa học Dữ liệu tại Trung tâm Đổi mới AI tạo sinh AWS. Cô thúc đẩy các dự án cung cấp các ứng dụng AI tạo sinh cho các khách hàng doanh nghiệp từ nhiều ngành công nghiệp khác nhau. Trước khi gia nhập AWS, cô đã làm việc cải thiện các mô hình NLP cho trợ lý mua sắm Alexa cả trên trang web Amazon.com và trên các thiết bị Echo.

Aishwarya là Quản lý Giải pháp Khách hàng Cấp cao (Senior Customer Solutions Manager) tại AWS Automotive. Cô đam mê giải quyết các vấn đề kinh doanh bằng cách sử dụng AI tạo sinh và các công nghệ dựa trên đám mây.

Satyam Saxena là Quản lý Khoa học Ứng dụng (Applied Science Manager) tại đội ngũ Trung tâm Đổi mới AI tạo sinh AWS. Anh dẫn dắt các hoạt động hợp tác với khách hàng về AI tạo sinh, thúc đẩy các sáng kiến ML/AI đổi mới từ ý tưởng đến thực tế với hơn một thập kỷ kinh nghiệm trong machine learning và khoa học dữ liệu. Mối quan tâm nghiên cứu của anh bao gồm deep learning, thị giác máy tính, NLP, hệ thống gợi ý và AI tạo sinh.

Kim Robins , một Chiến lược gia AI Cấp cao tại Trung tâm Đổi mới AI tạo sinh của AWS, tận dụng chuyên môn sâu rộng về trí tuệ nhân tạo và machine learning của mình để giúp các tổ chức phát triển các sản phẩm đổi mới và tinh chỉnh các chiến lược AI, mang lại giá trị kinh doanh hữu hình.