Xử lý tài liệu thông minh với dịch vụ AWS AI và Analytics trong ngành bảo hiểm: Phần 2

In Phần 1 Trong loạt bài này, chúng ta đã thảo luận về quy trình xử lý tài liệu thông minh (IDP) và cách IDP có thể đẩy nhanh các trường hợp sử dụng xử lý yêu cầu bồi thường trong ngành bảo hiểm. Chúng tôi đã thảo luận về cách có thể sử dụng dịch vụ AI của AWS để phân loại chính xác các tài liệu khiếu nại cùng với các tài liệu hỗ trợ. Chúng tôi cũng đã thảo luận về cách trích xuất các loại tài liệu khác nhau trong gói yêu cầu bồi thường bảo hiểm, chẳng hạn như biểu mẫu, bảng hoặc tài liệu chuyên ngành như hóa đơn, biên lai hoặc tài liệu ID. Chúng tôi đã xem xét những thách thức trong các quy trình xử lý tài liệu cũ vốn tốn thời gian, dễ xảy ra lỗi, tốn kém và khó xử lý trên quy mô lớn cũng như cách bạn có thể sử dụng các dịch vụ AI của AWS để giúp triển khai quy trình IDP của mình.

Trong bài đăng này, chúng tôi sẽ hướng dẫn bạn các tính năng IDP nâng cao để trích xuất, truy vấn và làm phong phú tài liệu. Chúng tôi cũng xem xét cách sử dụng thêm thông tin có cấu trúc được trích xuất từ ​​dữ liệu xác nhận quyền sở hữu để hiểu rõ hơn bằng cách sử dụng AWS Analytics và các dịch vụ trực quan hóa. Chúng tôi nêu bật cách dữ liệu có cấu trúc được trích xuất từ ​​IDP có thể giúp chống lại các khiếu nại gian lận bằng cách sử dụng dịch vụ AWS Analytics.

Tổng quan về giải pháp

Sơ đồ sau minh họa các giai đoạn nếu IDP sử dụng dịch vụ AWS AI. Trong Phần 1, chúng ta đã thảo luận về ba giai đoạn đầu tiên của quy trình làm việc IDP. Trong bài đăng này, chúng tôi sẽ mở rộng bước trích xuất và các giai đoạn còn lại, bao gồm việc tích hợp IDP với các dịch vụ AWS Analytics.

Chúng tôi sử dụng các dịch vụ phân tích này để có thêm thông tin chi tiết và hình ảnh trực quan, đồng thời phát hiện các khiếu nại gian lận bằng cách sử dụng dữ liệu chuẩn hóa, có cấu trúc từ IDP. Sơ đồ sau minh họa kiến ​​trúc giải pháp.

Các giai đoạn chúng tôi thảo luận trong bài đăng này sử dụng các dịch vụ chính sau:

• Amazon hiểu y tế là dịch vụ xử lý ngôn ngữ tự nhiên (NLP) đủ điều kiện HIPAA sử dụng mô hình học máy (ML) đã được đào tạo trước để hiểu và trích xuất dữ liệu sức khỏe từ văn bản y tế, chẳng hạn như đơn thuốc, quy trình hoặc chẩn đoán.
• Keo AWS là một phần của nhóm dịch vụ AWS Analytics và là dịch vụ tích hợp dữ liệu phi máy chủ giúp dễ dàng khám phá, chuẩn bị và kết hợp dữ liệu để phân tích, ML và phát triển ứng dụng.
• Amazon RedShift là một dịch vụ khác trong ngăn xếp Analytics. Amazon Redshift là dịch vụ kho dữ liệu có quy mô petabyte được quản lý toàn phần trên đám mây.

Điều kiện tiên quyết

Trước khi bắt đầu, hãy tham khảo Phần 1 để có cái nhìn tổng quan cấp cao về trường hợp sử dụng bảo hiểm với IDP cũng như thông tin chi tiết về các giai đoạn thu thập và phân loại dữ liệu.

Để biết thêm thông tin về các mẫu mã, hãy tham khảo Kho lưu trữ GitHub.

Giai đoạn khai thác

Trong Phần 1, chúng ta đã biết cách sử dụng API Amazon Textract để trích xuất thông tin như biểu mẫu và bảng từ tài liệu cũng như cách phân tích hóa đơn và tài liệu nhận dạng. Trong bài đăng này, chúng tôi nâng cao giai đoạn trích xuất bằng Amazon Comprehend để trích xuất các thực thể mặc định và tùy chỉnh dành riêng cho các trường hợp sử dụng tùy chỉnh.

Các hãng bảo hiểm thường gặp văn bản dày đặc trong đơn yêu cầu bồi thường bảo hiểm, chẳng hạn như thư tóm tắt xuất viện của bệnh nhân (xem hình ảnh ví dụ sau). Có thể khó có thể tự động trích xuất thông tin từ những loại tài liệu không có cấu trúc xác định. Để giải quyết vấn đề này, chúng ta có thể sử dụng các phương pháp sau để trích xuất thông tin kinh doanh chính từ tài liệu:

Trích xuất các thực thể mặc định bằng API Amazon Comprehend DetectEntities

Chúng tôi chạy đoạn mã sau trên tài liệu phiên âm y tế mẫu:

comprehend = boto3.client('comprehend') 

response = comprehend.detect_entities( Text=text, LanguageCode='en')

#print enitities from the response JSON

for entity in response['Entities']:
    print(f'{entity["Type"]} : {entity["Text"]}')

Ảnh chụp màn hình sau đây hiển thị tập hợp các thực thể được xác định trong văn bản đầu vào. Đầu ra đã được rút ngắn cho mục đích của bài viết này. Tham khảo đến Repo GitHub để biết danh sách chi tiết các thực thể.

Trích xuất các thực thể tùy chỉnh bằng tính năng nhận dạng thực thể tùy chỉnh của Amazon Comprehend

Phản hồi từ DetectEntities API bao gồm các thực thể mặc định. Tuy nhiên, chúng tôi muốn biết các giá trị thực thể cụ thể, chẳng hạn như tên của bệnh nhân (được biểu thị bằng thực thể mặc định PERSON) hoặc ID của bệnh nhân (được biểu thị bằng thực thể mặc định OTHER). Để nhận dạng các thực thể tùy chỉnh này, chúng tôi đào tạo mô hình trình nhận dạng thực thể tùy chỉnh Amazon Comprehend. Chúng tôi khuyên bạn nên làm theo các bước toàn diện về cách đào tạo và triển khai mô hình nhận dạng thực thể tùy chỉnh trong Kho lưu trữ GitHub.

Sau khi triển khai mô hình tùy chỉnh, chúng ta có thể sử dụng chức năng trợ giúp get_entities() để truy xuất các thực thể tùy chỉnh như PATIENT_NAME và PATIENT_D từ phản hồi API:

def get_entities(text):
try:
    #detect entities
    entities_custom = comprehend.detect_entities(LanguageCode="en",
                      Text=text, EndpointArn=ER_ENDPOINT_ARN) 
    df_custom = pd.DataFrame(entities_custom["Entities"], columns = ['Text',  
                'Type', 'Score'])
    df_custom = df_custom.drop_duplicates(subset=['Text']).reset_index()
    return df_custom
except Exception as e:
    print(e)

# call the get_entities() function 
response = get_entities(text) 
#print the response from the get_entities() function
print(response)

Ảnh chụp màn hình sau đây cho thấy kết quả của chúng tôi.

Giai đoạn làm giàu

Trong giai đoạn làm giàu tài liệu, chúng tôi thực hiện các chức năng làm giàu tài liệu liên quan đến chăm sóc sức khỏe để rút ra những hiểu biết có giá trị. Chúng tôi xem xét các loại làm giàu sau đây:

• Trích xuất ngôn ngữ dành riêng cho miền – Chúng tôi sử dụng Amazon Comprehend Medical để trích xuất các bản thể dành riêng cho y tế như ICD-10-CM, RxNorm và SNOMED CT
• Biên soạn lại thông tin nhạy cảm – Chúng tôi sử dụng Amazon Comprehend để biên tập thông tin nhận dạng cá nhân (PII) và Amazon Comprehend Medical để biên tập thông tin sức khỏe được bảo vệ (PHI)

Trích xuất thông tin y tế từ văn bản y tế phi cấu trúc

Các tài liệu như ghi chú của nhà cung cấp dịch vụ y tế và báo cáo thử nghiệm lâm sàng bao gồm văn bản y tế dày đặc. Các nhà cung cấp yêu cầu bồi thường bảo hiểm cần xác định mối quan hệ giữa các thông tin sức khỏe được trích xuất từ ​​văn bản dày đặc này và liên kết chúng với các bản thể y tế như mã ICD-10-CM, RxNorm và SNOMED CT. Điều này rất có giá trị trong việc tự động hóa quy trình thu thập, xác nhận và phê duyệt yêu cầu bồi thường cho các công ty bảo hiểm nhằm tăng tốc và đơn giản hóa quá trình xử lý yêu cầu bồi thường. Hãy xem cách chúng ta có thể sử dụng Amazon Comprehend Medical InferICD10CM API để phát hiện các tình trạng y tế có thể xảy ra dưới dạng thực thể và liên kết chúng với mã của chúng:

cm_json_data = comprehend_med.infer_icd10_cm(Text=text)

print("nMedical codingn========")

for entity in cm_json_data["Entities"]:
      for icd in entity["ICD10CMConcepts"]:
           description = icd['Description']
           code = icd["Code"]
           print(f'{description}: {code}')

Đối với văn bản đầu vào mà chúng ta có thể chuyển vào từ Amazon Textract DetectDocumentText API, InferICD10CM API trả về kết quả đầu ra sau (đầu ra đã được viết tắt cho ngắn gọn).

Tương tự, chúng ta có thể sử dụng Amazon Comprehend Medical InferRxNorm API để xác định thuốc và InferSNOMEDCT API để phát hiện các thực thể y tế trong các tài liệu bảo hiểm liên quan đến chăm sóc sức khỏe.

Thực hiện biên tập PII và PHI

Các gói yêu cầu bồi thường bảo hiểm yêu cầu rất nhiều quy định và tuân thủ quyền riêng tư vì chúng chứa cả dữ liệu PII và PHI. Các hãng bảo hiểm có thể giảm rủi ro tuân thủ bằng cách biên tập lại các thông tin như số hợp đồng hoặc tên bệnh nhân.

Chúng ta hãy xem một ví dụ về bản tóm tắt xuất viện của một bệnh nhân. Chúng tôi sử dụng Amazon Comprehend DetectPiiEntities API để phát hiện các thực thể PII trong tài liệu và bảo vệ quyền riêng tư của bệnh nhân bằng cách sắp xếp lại các thực thể này:

resp = call_textract(input_document = f's3://{data_bucket}/idp/textract/dr-note-sample.png')
text = get_string(textract_json=resp, output_type=[Textract_Pretty_Print.LINES])

# call Amazon Comprehend Detect PII Entities API
entity_resp = comprehend.detect_pii_entities(Text=text, LanguageCode="en") 

pii = []
for entity in entity_resp['Entities']:
      pii_entity={}
      pii_entity['Type'] = entity['Type']
      pii_entity['Text'] = text[entity['BeginOffset']:entity['EndOffset']]
      pii.append(pii_entity)
print(pii)

Chúng tôi nhận được các thực thể PII sau trong phản hồi từ detect_pii_entities() API :

Sau đó, chúng tôi có thể điều chỉnh lại các thực thể PII được phát hiện từ tài liệu bằng cách sử dụng hình dạng hộp giới hạn của các thực thể từ tài liệu. Để làm được điều đó, chúng tôi sử dụng một công cụ trợ giúp có tên là amazon-textract-overlayer. Để biết thêm thông tin, hãy tham khảo Lớp phủ văn bản. Các ảnh chụp màn hình sau đây so sánh tài liệu trước và sau khi biên tập.

Tương tự với Amazon Comprehend DetectPiiEntities API, chúng tôi cũng có thể sử dụng DetectPHI API để phát hiện dữ liệu PHI trong văn bản lâm sàng đang được kiểm tra. Để biết thêm thông tin, hãy tham khảo Phát hiện PHI.

Giai đoạn xem xét và xác nhận

Trong giai đoạn xem xét và xác thực tài liệu, giờ đây chúng tôi có thể xác minh xem gói yêu cầu có đáp ứng yêu cầu của doanh nghiệp hay không vì chúng tôi có tất cả thông tin được thu thập từ các tài liệu trong gói từ các giai đoạn trước. Chúng tôi có thể thực hiện việc này bằng cách giới thiệu một người trong vòng lặp có thể xem xét và xác thực tất cả các trường hoặc chỉ quy trình phê duyệt tự động đối với các yêu cầu có số tiền thấp trước khi gửi gói hàng đến các ứng dụng tiếp theo. Chúng ta có thể sử dụng AI tăng cường của Amazon (Amazon A2I) để tự động hóa quy trình đánh giá con người trong quá trình xử lý yêu cầu bảo hiểm.

Giờ đây, khi đã trích xuất và chuẩn hóa tất cả dữ liệu cần thiết từ quá trình xử lý khiếu nại bằng dịch vụ AI cho IDP, chúng tôi có thể mở rộng giải pháp để tích hợp với các dịch vụ AWS Analytics như AWS Glue và Amazon Redshift để giải quyết các trường hợp sử dụng bổ sung cũng như cung cấp thêm phân tích và hình ảnh hóa.

Phát hiện gian lận yêu cầu bồi thường bảo hiểm

Trong bài đăng này, chúng tôi triển khai kiến ​​trúc không có máy chủ, trong đó dữ liệu được trích xuất và xử lý được lưu trữ trong hồ dữ liệu và được sử dụng để phát hiện các yêu cầu bảo hiểm gian lận bằng ML. Chúng tôi sử dụng Dịch vụ lưu trữ đơn giản của Amazon (Amazon S3) để lưu trữ dữ liệu đã xử lý. Sau đó chúng ta có thể sử dụng Keo AWS or Amazon EMR để làm sạch dữ liệu và thêm các trường bổ sung để làm cho dữ liệu có thể sử dụng được cho báo cáo và ML. Sau đó, chúng tôi sử dụng Máy học dịch chuyển đỏ của Amazon để xây dựng mô hình ML phát hiện gian lận. Cuối cùng, chúng tôi xây dựng báo cáo bằng cách sử dụng Amazon QuickSight để hiểu rõ hơn về dữ liệu.

Thiết lập lược đồ bên ngoài Amazon Redshift

Với mục đích của ví dụ này, chúng tôi đã tạo một tập dữ liệu mẫu mô phỏng đầu ra của quy trình ETL (trích xuất, chuyển đổi và tải) và sử dụng Danh mục dữ liệu AWS Glue làm danh mục siêu dữ liệu. Đầu tiên chúng ta tạo một cơ sở dữ liệu có tên idp_demo trong Danh mục dữ liệu và lược đồ bên ngoài trong Amazon Redshift có tên idp_insurance_demo (xem đoạn mã sau). Chúng tôi sử dụng một Quản lý truy cập và nhận dạng AWS (IAM) cấp quyền cho cụm Amazon Redshift để truy cập Amazon S3 và Amazon SageMaker. Để biết thêm thông tin về cách thiết lập vai trò IAM này với đặc quyền tối thiểu, hãy tham khảo Cụm và định cấu hình thiết lập cho quản trị Amazon Redshift ML.

CREATE EXTERNAL SCHEMA idp_insurance_demo
FROM DATA CATALOG
DATABASE 'idp_demo' 
IAM_ROLE '<<>>'
CREATE EXTERNAL DATABASE IF NOT EXISTS;

Tạo bảng bên ngoài Amazon Redshift

Bước tiếp theo là tạo một bảng bên ngoài trong Amazon Redshift tham chiếu đến vị trí S3 chứa tệp. Trong trường hợp này, tệp của chúng tôi là tệp văn bản được phân tách bằng dấu phẩy. Chúng tôi cũng muốn bỏ qua hàng tiêu đề khỏi tệp, hàng này có thể được định cấu hình trong phần thuộc tính của bảng. Xem đoạn mã sau:

create external table idp_insurance_demo.claims(id INTEGER,
date_of_service date,
patients_address_city VARCHAR,
patients_address_state VARCHAR,
patients_address_zip VARCHAR,
patient_status VARCHAR,
insured_address_state VARCHAR,
insured_address_zip VARCHAR,
insured_date_of_birth date,
insurance_plan_name VARCHAR,
total_charges DECIMAL(14,4),
fraud VARCHAR,
duplicate varchar,
invalid_claim VARCHAR
)
row format delimited
fields terminated by ','
stored as textfile
location '<<>>'
table properties ( 'skip.header.line.count'='1');

Tạo tập dữ liệu huấn luyện và kiểm tra

Sau khi tạo bảng bên ngoài, chúng tôi chuẩn bị tập dữ liệu cho ML bằng cách chia nó thành tập huấn luyện và tập kiểm tra. Chúng tôi tạo một bảng bên ngoài mới gọi là claim_train, bao gồm tất cả các bản ghi có ID <= 85000 từ bảng xác nhận quyền sở hữu. Đây là tập huấn luyện mà chúng tôi huấn luyện mô hình ML của mình.

CREATE EXTERNAL TABLE
idp_insurance_demo.claims_train
row format delimited
fields terminated by ','
stored as textfile
location '<<>>/train'
table properties ( 'skip.header.line.count'='1')
AS select * from idp_insurance_demo.claims where id <= 850000

Chúng tôi tạo một bảng bên ngoài khác gọi là claim_test bao gồm tất cả các bản ghi có ID >85000 là tập kiểm tra mà chúng tôi kiểm tra mô hình ML trên:

CREATE EXTERNAL TABLE
idp_insurance_demo.claims_test
row format delimited
fields terminated by ','
stored as textfile
location '<<>>/test'
table properties ( 'skip.header.line.count'='1')
AS select * from idp_insurance_demo.claims where id > 850000

Tạo mô hình ML với Amazon Redshift ML

Bây giờ chúng ta tạo mô hình bằng cách sử dụng TẠO MÔ HÌNH lệnh (xem đoạn mã sau). Chúng tôi chọn các cột có liên quan từ claims_train bảng có thể xác định một giao dịch gian lận. Mục tiêu của mô hình này là dự đoán giá trị của fraud cột; Vì vậy, fraud được thêm vào làm mục tiêu dự đoán. Sau khi mô hình được huấn luyện, nó tạo ra một hàm có tên insurance_fraud_model. Hàm này được sử dụng để suy luận trong khi chạy các câu lệnh SQL nhằm dự đoán giá trị của fraud cột cho các bản ghi mới.

CREATE MODEL idp_insurance_demo.insurance_fraud_model
FROM (SELECT 
total_charges ,
fraud ,
duplicate,
invalid_claim
FROM idp_insurance_demo.claims_train
)
TARGET fraud
FUNCTION insurance_fraud_model
IAM_ROLE '<<>>'
SETTINGS (
S3_BUCKET '<<>>'
);

Đánh giá số liệu mô hình ML

Sau khi tạo mô hình, chúng ta có thể chạy truy vấn để kiểm tra tính chính xác của mô hình. Chúng tôi sử dụng insurance_fraud_model hàm dự đoán giá trị của fraud cột cho các bản ghi mới. Chạy truy vấn sau trên claims_test table để tạo ma trận nhầm lẫn:

SELECT 
fraud,
idp_insurance_demo.insurance_fraud_model (total_charges ,duplicate,invalid_claim ) as fraud_calculcated,
count(1)
FROM idp_insurance_demo.claims_test
GROUP BY fraud , fraud_calculcated;

Phát hiện gian lận bằng mô hình ML

Sau khi tạo mô hình mới, khi dữ liệu xác nhận quyền sở hữu mới được chèn vào kho dữ liệu hoặc hồ dữ liệu, chúng tôi có thể sử dụng insurance_fraud_model chức năng tính toán các giao dịch gian lận. Trước tiên, chúng tôi thực hiện việc này bằng cách tải dữ liệu mới vào một bảng tạm thời. Sau đó chúng tôi sử dụng insurance_fraud_model hàm tính toán fraud gắn cờ cho mỗi giao dịch mới và chèn dữ liệu cùng với cờ vào bảng cuối cùng, trong trường hợp này là bảng claims bảng.

Trực quan hóa dữ liệu khiếu nại

Khi dữ liệu có sẵn trong Amazon Redshift, chúng tôi có thể tạo trực quan hóa bằng QuickSight. Sau đó, chúng tôi có thể chia sẻ bảng thông tin QuickSight với người dùng doanh nghiệp và nhà phân tích. Để tạo bảng thông tin QuickSight, trước tiên bạn cần tạo tập dữ liệu Amazon Redshift trong QuickSight. Để biết hướng dẫn, hãy tham khảo Tạo tập dữ liệu từ cơ sở dữ liệu.

Sau khi tạo tập dữ liệu, bạn có thể tạo bản phân tích mới trong QuickSight bằng cách sử dụng tập dữ liệu. Sau đây là một số báo cáo mẫu mà chúng tôi đã tạo:

• Tổng số khiếu nại theo tiểu bang, được nhóm theo fraud lĩnh vực – Biểu đồ này cho chúng ta thấy tỷ lệ giao dịch gian lận so với tổng số giao dịch ở một trạng thái cụ thể.
• Tổng giá trị bằng đô la của các yêu cầu bồi thường, được nhóm theo fraud lĩnh vực – Biểu đồ này cho chúng ta thấy tỷ lệ số tiền giao dịch gian lận so với tổng số tiền giao dịch ở một tiểu bang cụ thể.
• Tổng số giao dịch của mỗi công ty bảo hiểm, được nhóm theo fraud lĩnh vực – Biểu đồ này cho chúng ta thấy có bao nhiêu yêu cầu bồi thường được nộp cho mỗi công ty bảo hiểm và bao nhiêu trong số đó là gian lận.

• Tổng số giao dịch gian lận theo tiểu bang hiển thị trên bản đồ Hoa Kỳ – Biểu đồ này chỉ hiển thị các giao dịch gian lận và hiển thị tổng phí cho các giao dịch đó theo tiểu bang trên bản đồ. Màu xanh đậm hơn biểu thị tổng phí cao hơn. Chúng tôi có thể phân tích sâu hơn điều này theo thành phố trong tiểu bang đó và mã zip với thành phố để hiểu rõ hơn về xu hướng.

Làm sạch

Để tránh phát sinh phí trong tương lai đối với tài khoản AWS của bạn, hãy xóa tài nguyên mà bạn đã cung cấp trong quá trình thiết lập bằng cách làm theo hướng dẫn trong Phần dọn dẹp trong kho lưu trữ của chúng tôi.

Kết luận

Trong loạt bài gồm hai phần này, chúng ta đã biết cách xây dựng quy trình IDP từ đầu đến cuối mà không cần hoặc có ít hoặc có ít kinh nghiệm về ML. Chúng tôi đã khám phá một trường hợp sử dụng xử lý yêu cầu bồi thường trong ngành bảo hiểm và cách IDP có thể giúp tự động hóa trường hợp sử dụng này bằng cách sử dụng các dịch vụ như Amazon Textract, Amazon Comprehend, Amazon Comprehend Medical và Amazon A2I. Trong Phần 1, chúng tôi đã trình bày cách sử dụng dịch vụ AWS AI để trích xuất tài liệu. Trong Phần 2, chúng tôi đã mở rộng giai đoạn trích xuất và thực hiện làm giàu dữ liệu. Cuối cùng, chúng tôi đã mở rộng dữ liệu có cấu trúc được trích xuất từ ​​IDP để phân tích sâu hơn và tạo hình ảnh trực quan để phát hiện các khiếu nại gian lận bằng cách sử dụng dịch vụ AWS Analytics.

Chúng tôi khuyên bạn nên xem lại các phần bảo mật của Văn bản Amazon, Amazon hiểuvà amazon A2I tài liệu và làm theo hướng dẫn được cung cấp. Để tìm hiểu thêm về giá của giải pháp, hãy xem lại chi tiết về giá của Văn bản Amazon, Amazon hiểuvà amazon A2I.

Về các tác giả

Chinmayee Rane là một Kiến trúc sư Giải pháp Chuyên gia về AI / ML tại Amazon Web Services. Cô ấy đam mê toán học ứng dụng và máy học. Cô tập trung vào việc thiết kế các giải pháp xử lý tài liệu thông minh cho khách hàng AWS. Ngoài giờ làm việc, cô thích khiêu vũ salsa và bachata.

Uday Narayanan là Kiến trúc sư giải pháp chuyên gia phân tích tại AWS. Ông thích giúp đỡ khách hàng tìm ra giải pháp sáng tạo cho những thách thức kinh doanh phức tạp. Lĩnh vực trọng tâm cốt lõi của ông là phân tích dữ liệu, hệ thống dữ liệu lớn và học máy. Trong thời gian rảnh rỗi, anh thích chơi thể thao, xem các chương trình truyền hình say sưa và đi du lịch.

Sonali Sahu đang lãnh đạo nhóm Kiến trúc sư giải pháp AI/ML xử lý tài liệu thông minh tại Amazon Web Services. Cô ấy là một người đam mê công nghệ và thích làm việc với khách hàng để giải quyết các vấn đề phức tạp bằng cách sử dụng sự đổi mới. Lĩnh vực trọng tâm cốt lõi của cô là trí tuệ nhân tạo và học máy để xử lý tài liệu thông minh.