# Using RL-based Agent to Detect and Remediate ETL Pipeline Failures

Anna Marie Benzon · University of the Philippines Diliman · AI Engineer World's Fair 2026: Online Track

> Agent tự xử lý lỗi ETL trên AWS: rules xác lập facts, Q-learning chọn action có giới hạn, safety layer bên ngoài giữ quyền escalate; MTTR từ ngày xuống phút.

Topics: Agents, Workflow, Security

Canonical: https://homus.dev/talks/using-rl-based-agent-to-detect-and-remediate-etl-pipeline-failures

## 1. Nửa đêm, một ETL job hỏng và câu hỏi "cái gì đã đổi?"

Talk mở đầu bằng một cảnh mà ai làm data engineering cũng từng gặp. Hãy tưởng tượng bạn là người engineer này: một data job chạy trên production đã fail từ nhiều giờ trước, dashboard bị stale, không còn số mới. Bạn đã mất cả ngày đi kiểm tra logs, kiểm tra schema, kiểm tra dữ liệu upstream, và giờ đã quá nửa đêm. Câu hỏi cứ quay lại mãi: What changed? Cái gì đã thay đổi?

Bản thân lỗi có thể rất nhỏ. Phần tốn kém là mọi thứ xung quanh nó: inspection (đi xem xét), diagnosis (chẩn đoán), chọn một cách phản ứng an toàn, rerun job, rồi xác nhận rằng mình không làm cho dữ liệu tệ hơn trước.

Anna Marie Benzon tự giới thiệu và nêu mục tiêu của talk: trình bày một hệ thống RL-guided, tức được dẫn dắt bởi reinforcement learning, dùng để chọn ra những remediation action có giới hạn (bounded) cho các lỗi ETL. Theo chị, câu hỏi trung tâm không đơn giản là một agent có thể hành động hay không, mà là nó có hành động một cách hữu ích, giải thích được, và nằm trong những ranh giới mà một operations team thực sự tin tưởng hay không.

![Slide tiêu đề của talk với tên người trình bày Anna Marie Benzon](https://homus.dev/photos/LrGCT7G_rU8-0008.jpg)

Slide mở đầu: tên talk, người trình bày Anna Marie Benzon, đơn vị University of the Philippines Diliman, và đường dẫn tới repository rl-etl-remediation-agent trên GitHub.

## 2. Vì sao cloud ETL hỏng, và vì sao sửa tay mất 2,5 ngày làm việc

Lỗi của cloud ETL hiếm khi đến dưới dạng một exception gọn gàng, được gắn nhãn rõ ràng. Thực tế chị gặp là một danh sách lộn xộn hơn nhiều:

- source dữ liệu đến trễ hoặc không có;

- schema drift, cấu trúc dữ liệu tự thay đổi so với trước;

- không tương thích định dạng date-time khi parse;

- null rate tăng vọt bất thường;

- type của một field bị đổi;

- và những runtime error không khớp với bất kỳ mục nào trong runbook.

Cách phản ứng quen thuộc là một human workflow: inspect logs, đưa ra một chẩn đoán, thử một cách sửa, rerun job, rồi validate output. Từng bước đều hợp lý. Độ trễ không đến từ một bước nào cụ thể mà đến từ các lần chuyển tay (handoff), từ việc thiếu context, và từ nhu cầu phải tránh một cách sửa không an toàn.

Trong phần evaluation của capstone project, baseline phục hồi thủ công được mô hình hoá ở mức khoảng **2,5 ngày làm việc**. Con số này đại diện cho một incident đi qua đủ các khâu bình thường: xếp hàng chờ (queuing), điều tra, và chờ phê duyệt.

Vì vậy mục tiêu kỹ thuật được đặt ra rất cụ thể: nén vòng lặp đó lại cho những lỗi thường gặp, nhận diện được, đồng thời escalate (đẩy lên cho con người) những ca không chắc chắn, mới lạ, hoặc có rủi ro cao.

![Slide The Problem liệt kê các nguyên nhân khiến cloud ETL job hỏng](https://homus.dev/photos/LrGCT7G_rU8-0056.jpg)

Slide "The Problem": phía trên là chuỗi xử lý thủ công Failure, Inspect Logs, Diagnose, Repair, Rerun, Validate; bên dưới là sáu nhóm nguyên nhân (source đến trễ, schema drift, lỗi parse datetime, null-rate spike, type change, runtime error lạ) và dòng cuối ghi MTTR thủ công được mô hình hoá khoảng 2,5 ngày làm việc.

## 3. Kiến trúc AWS end-to-end: một vòng vận hành khép kín

Sơ đồ tiếp theo là kiến trúc AWS end-to-end trong capstone của chị. Luồng đi như sau:

- Một [AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/what-is-glue.html) ETL job có sẵn phát ra một event "job failed".

- [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) bắt event đó và trigger một [Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) function, nơi agent chạy.

- Lambda thu thập bằng chứng từ hai nguồn chỉ đọc (read-only): [CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) cung cấp error logs, còn Glue Data Catalog cung cấp schema metadata hiện tại.

- Hệ thống dùng các tín hiệu đó để phân loại lỗi, đánh giá chất lượng dữ liệu và rủi ro vận hành, rồi dựng nên state để chuyển cho RL decision engine.

- Policy đề xuất một phản ứng có giới hạn.

- Safety layer kiểm tra đề xuất đó trước khi executor được phép dùng Glue API để trigger lại job hoặc áp một remediation đã được phê duyệt.

- [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) lưu artifact của agent, audit log và các output bị quarantine (cách ly).

- Cuối cùng job được rerun và validate.

Nói gọn, đây là một vòng vận hành khép kín: monitor, diagnose, score, decide, check safety, act, và verify recovery.

Chị nói rõ phạm vi dữ liệu: bản capstone dùng dữ liệu synthetic do client cung cấp. Repository công khai giữ nguyên pattern đó thông qua một deployment template đã được làm sạch (sanitized) và tổng quát hoá.

![Sơ đồ kiến trúc AI Pipeline Health Agent trên AWS và chuỗi Monitor đến Validate](https://homus.dev/photos/LrGCT7G_rU8-0200.jpg)

Slide "The Solution": sơ đồ Phase 1 của AI Pipeline Health Agent nối Glue ETL Jobs, EventBridge, Lambda, CloudWatch Logs, Glue Data Catalog, RL Agent (Decide + Act), Glue API và S3; ghi chú đây là kiến trúc tham chiếu công khai đã tổng quát hoá. Bên dưới là chuỗi Monitor, Diagnose, Score, Decide, Safety, Act, Validate với năm bước: quan sát logs, schema và data quality; chẩn đoán nhóm lỗi; ước lượng rủi ro vận hành; chọn một remediation action có giới hạn; kiểm tra action đó có đưa hệ thống về trạng thái khoẻ hay không.

## 4. Intelligence layer: rules cho facts, learning cho lựa chọn, guardrails cho quyền hạn

Phần "trí tuệ" của hệ thống cố ý tách ba mối quan tâm ra riêng:

- **Deterministic anomaly rules** xác lập những sự thật quan sát được: một field biến mất, một type bị đổi, hay null rate vượt ngưỡng.

- **Q-learning policy** lo việc chọn action theo ngữ cảnh. Với state hiện tại của incident, hệ thống nên retry, coerce schema, rollback, quarantine, escalate, hay chỉ log sự kiện lại?

- **Safety override** nằm bên ngoài learned policy. Ví dụ, nếu anomaly ở mức critical mà policy lại đề xuất một action thụ động như chỉ log, override sẽ đổi lựa chọn đó thành escalation.

Sự tách bạch này chính là luận điểm thiết kế (design thesis) của cả project: rules for facts, learning for bounded choices, and guardrails for authority. Rules để xác lập facts, learning cho những lựa chọn có giới hạn, và guardrails để giữ quyền hạn.

![Slide The Intelligence Layer với ba tầng xếp chồng](https://homus.dev/photos/LrGCT7G_rU8-0320.jpg)

Ba tầng của intelligence layer: Deterministic Anomaly Rules (schema drift, null spike, field bị xoá, type change), Q-Learning Decision Policy (retry, coerce schema, rollback, quarantine, escalate, log), và Safety Override (anomaly critical cộng action thụ động thì chuyển thành escalate).

## 5. Detection và diagnosis: xác lập facts trước khi chọn action

Trước khi chọn bất kỳ action nào, hệ thống phải biết chắc điều gì đã thực sự xảy ra. Năm component đảm nhận việc này:

- **Schema profiler** trích xuất cấu trúc, type, độ lồng (nesting) và thống kê null rate.

- **Drift detector** so sánh profile hiện tại với baseline, nhận diện field được thêm, field bị xoá, và type bị đổi.

- **Data quality analyzer** kiểm tra completeness, validity và consistency.

- **Error classifier** ánh xạ các pattern trong log vào những họ lỗi (failure family).

- **Risk scorer** biến các tín hiệu trên thành một mức rủi ro vận hành.

Tất cả các component này đều deterministic, và đó là chủ ý. Với những tình trạng dữ liệu quan sát trực tiếp được, một rule tường minh dễ validate, dễ giải thích và dễ audit hơn một phép suy luận mờ đục (opaque inference).

Chị thừa nhận rằng khi có lịch sử incident phong phú và mang tính đại diện hơn, một vài classifier có thể trở thành learned component. Nhưng "ML-ready không có nghĩa là ML-required". Component đơn giản nhất mà vẫn đáng tin cậy nên là thứ sở hữu từng quyết định.

![Bảng Detection and Diagnosis gồm năm component và trách nhiệm](https://homus.dev/photos/LrGCT7G_rU8-0408.jpg)

Bảng "Establish the Facts Before Choosing an Action": mỗi component một trách nhiệm, từ schema profiler đến risk scorer. Dòng cuối nhấn mạnh đây là prototype deterministic trên một dataset hạn chế, sẵn sàng chuyển sang ML khi có lịch sử incident phong phú hơn.

## 6. RL chọn cách phản ứng, không chọn facts

Policy nhận một state gọn gồm năm thành phần: failure category, risk level, retry count, drift severity và data quality condition. Từ đó nó chọn một trong sáu action: `retry`, `coerce`, `rollback`, `quarantine`, `escalate`, hoặc `log`.

Chị dùng [tabular Q-learning](https://en.wikipedia.org/wiki/Q-learning) vì cả state space lẫn action space đều nhỏ. Q-table rẻ khi tính, và mọi quyết định đều có thể xem xét trực tiếp: với state này, đây là các action value, và action này thắng.

Về mặt kỹ thuật, mỗi incident được mô hình hoá như một quyết định ngữ cảnh một bước (single-step contextual decision) được cài đặt bằng tabular Q-learning, chứ không phải một bài toán điều khiển nhiều bước dài hạn (long-horizon control task). Cách đặt bài toán này là có chủ đích: hệ thống cần chọn một phản ứng vận hành an toàn từ một tập action có giới hạn.

Giá trị của learned policy ở đây không phải là sự tinh vi cho bản thân nó. Đó là một cách có cấu trúc để học sở thích chọn action từ kết quả thực tế, trong khi vẫn giữ một "bề mặt quyết định" (decision surface) mà engineer có thể mở ra xem.

![Slide RL Selects the Response, Not the Facts với state và action](https://homus.dev/photos/LrGCT7G_rU8-0512.jpg)

Slide "RL Selects the Response, Not the Facts": năm thành phần của state bên trái, sáu action bên phải, kèm lựa chọn tabular Q-learning và ba lý do (state space nhỏ và diễn giải được, inference tốn ít bộ nhớ, Q-value xem được cho từng quyết định). Chú thích cuối slide nói rõ đây là bài toán quyết định ngữ cảnh một bước.

## 7. Safe autonomy: learned policy không có quyền quyết định cuối cùng

Learned policy không có final authority. Nó chỉ đề xuất một action. Safety layer đánh giá đề xuất đó dựa trên mức nghiêm trọng của anomaly và các ràng buộc vận hành của hệ thống:

- action thụ động bị override khi tình trạng là critical;

- ca rủi ro cao hoặc chưa biết thì được escalate;

- mọi đề xuất, mọi lần override, kết quả thực thi và kết quả validation đều được ghi vào một audit record.

![Slide Safe Autonomy với năm nguyên tắc](https://homus.dev/photos/LrGCT7G_rU8-0608.jpg)

Slide "Safe Autonomy, The Learned Policy Does Not Have Final Authority": policy đề xuất, safety layer đánh giá anomaly critical, action thụ động không an toàn bị override, ca rủi ro cao và chưa biết được escalate, mọi quyết định sinh ra audit record. Dòng cuối: escalation là một action đúng, không phải thất bại của autonomy.

## 8. Escalation là một capability, không phải agent bỏ cuộc

Chị lưu ý rằng escalation nằm ngay trong action space. Đó không phải là agent bỏ cuộc, mà là hệ thống nhận ra đúng ranh giới của bằng chứng hoặc của quyền hạn mà nó có.

Với một operational agent, khả năng nói "tôi không nên tự động làm việc này" là một capability thật sự. Nếu thành công chỉ được đo bằng việc không escalate, thì mục tiêu tối ưu đã sai ngay từ đầu.

Policy chỉ đề xuất; safety layer nằm ngoài nó quyết định đề xuất được thực thi hay bị chuyển thành escalation. Cả hai nhánh đều là kết quả hợp lệ.

## 9. Một failure path cụ thể: coercion an toàn nhưng không làm được

Chị đi qua một đường lỗi cụ thể:

- Agent nhận một job failure event kiểu Glue.

- Log classifier phát hiện lỗi không tương thích định dạng date-time, với confidence 0,9.

- Dựa trên state đã mã hoá, policy đề xuất schema coercion.

- Safety override không kích hoạt, vì đây không được phân loại là anomaly critical.

- Nhưng sau đó executor phát hiện rằng coercion tự động không có sẵn cho ca cụ thể này.

Hệ thống không giả vờ là đã sửa xong. Nó ghi lại action được đề xuất, báo rằng việc thực thi không khả dụng, và gửi incident sang manual review.

Ví dụ này cho thấy hai lớp kiểm soát khác nhau: **policy safety** (action có an toàn về nguyên tắc không) và **implementation capability** (môi trường hiện tại có làm được action đó không). Một action có thể an toàn về nguyên tắc nhưng vẫn không khả dụng trong môi trường hiện tại. Một agent vững vàng phải biểu diễn cả hai điều kiện này một cách tường minh.

![Slide Example Failure với bản ghi JSON của một incident](https://homus.dev/photos/LrGCT7G_rU8-0704.jpg)

Slide "Example Failure": bản ghi JSON của incident có chú thích từng bước, từ [A] lỗi Glue job, [B] Error Classifier phân loại DATETIME_FORMAT_ERROR với confidence 0.90 và root cause là lỗi định dạng datetime của Spark 3, [C] rule engine khuyên coerce, [D] agent chọn schema coercion, [E] safety override không kích hoạt, đến [F] remediation thất bại (success là false, ghi chú "cần cập nhật Glue script thủ công") và incident được ghi lại để review.

Bản ghi trên slide, giữ nguyên để tham khảo cấu trúc một audit record:

```
{
"job_name": "synthetic_etl_job",
"triggered_at": "2026-05-21T02:05:20Z",

"error_classification": {
"error_type": "DATETIME_FORMAT_ERROR",
"confidence": 0.90,
"root_cause": "Spark 3 datetime format incompatibility",
"recommended_action": "APPLY_SCHEMA_COERCION"
},

"selected_action": "APPLY_SCHEMA_COERCION",
"anomaly_override": false,

"remediation": {
"success": false,
"note": "Manual Glue script update required"
}
}
```

## 10. Benchmark công khai để ai cũng chạy lại được

Để công trình có thể được review độc lập mà không lộ context của client, chị xây một benchmark công khai đã sanitize, quanh một kiến trúc kiểu AWS Lambda đã tổng quát hoá. Bản capstone dùng dữ liệu synthetic do client cung cấp; còn repository công khai dùng schema, record, log và kịch bản incident synthetic được tạo mới hoàn toàn. Nó không chứa tài liệu của client, không có infrastructure identifier, không có giá trị đặc thù của doanh nghiệp.

Chị chạy bốn nhóm thí nghiệm có kiểm soát, và lặp lại phần evaluation độ bền (robustness) qua 30 seed, từ 42 đến 71. Các số tổng hợp được báo cáo kèm khoảng tin cậy 95%. Cách làm này giữ lại thiết kế hệ thống và logic thí nghiệm ở dạng mà engineer khác có thể xem và chạy lại, trong khi vẫn giữ ranh giới bảo mật thông tin.

![Slide Reproducible Evaluation với thẻ repository GitHub](https://homus.dev/photos/LrGCT7G_rU8-0808.jpg)

Slide "Reproducible Evaluation, Designed for Independent Reproduction": kiến trúc kiểu Lambda tổng quát hoá, dữ liệu synthetic, không có dữ liệu production hay infrastructure identifier, bốn thí nghiệm E1 đến E4, kiểm tra robustness qua 30 lần chạy với seed 42 đến 71, kết quả kèm khoảng tin cậy 95%. Bên phải là thẻ repository [ambenzon27/rl-etl-remediation-agent](https://github.com/ambenzon27/rl-etl-remediation-agent), nơi có benchmark và test.

## 11. Kết quả evaluation: từ vài ngày xuống vài phút, trong phạm vi benchmark

Trên benchmark có kiểm soát, rule-based anomaly detector đạt precision 1, recall 0,8 và F1 score 0,889. Nghĩa là detector này bảo thủ: những anomaly nó gắn cờ đều đúng trong benchmark, nhưng nó vẫn bỏ sót một số ca dương tính. Với vận hành, sự phân biệt đó quan trọng: precision hoàn hảo không có nghĩa là phát hiện hoàn hảo.

Với những ca mà RL-guided workflow giải quyết thành công, thời gian xử lý trung bình khoảng 5,24 phút. Qua 30 lần chạy:

- tỉ lệ thành công mô phỏng là 74,63%, cộng trừ 1,51 điểm phần trăm;

- tỉ lệ không escalate (non-escalation rate) là 88,63%, cộng trừ 0,89 điểm.

Biểu đồ so sánh kết quả ở thang phút đó với baseline thủ công được mô hình hoá là 2,5 ngày làm việc, tức 216.000 giây. Trong phạm vi benchmark, đó là mức giảm MTTR (mean time to recovery) khoảng 99,85%.

Chị nhấn mạnh các con số này định lượng hiệu năng trong benchmark có kiểm soát. Trong phạm vi đó, chúng cho thấy kiến trúc có thể tự động hoá "fast path" cho những tình trạng lỗi đã biết. Validation trên production là ranh giới evaluation kế tiếp.

![Slide Evaluation Results với biểu đồ MTTR thang log](https://homus.dev/photos/LrGCT7G_rU8-0904.jpg)

Slide "Evaluation Results" (benchmark synthetic có kiểm soát, 30 seed, trung bình cộng trừ khoảng tin cậy 95%): sáu chỉ số bên trái, và biểu đồ thang log "MTTR Drops from Days to Minutes in the Benchmark" so cột thủ công 2,5 ngày làm việc (216.000 giây) với cột RL health agent 5,24 cộng trừ 0,14 phút, chú thích MTTR thấp hơn khoảng 99,85%. Ghi chú dưới biểu đồ: benchmark synthetic, không phải bằng chứng từ incident production.

## 12. Ablation: độ tin cậy thật ra đến từ đâu

Theo chị, kết quả ablation là phần hữu ích nhất của cả project.

- RL policy ngang bằng với policy deterministic tương đương: chênh lệch 0 điểm phần trăm, trong khoảng tin cậy 0,19 điểm. Trên state space gọn này, learned policy giữ được đúng mức thành công của policy định nghĩa bằng tay.

- Ngược lại, chọn action theo logic deterministic thắng chọn ngẫu nhiên 15,63 điểm.

- Bật safety override làm giảm non-escalation khoảng 15,03 điểm. Mức giảm này là có chủ đích: hệ thống có guardrail escalate thường xuyên hơn khi tự hành (autonomy) là không phù hợp.

Vậy độ tin cậy đến từ đâu? Chủ yếu đến từ state có cấu trúc, logic quyết định hợp lý và các ràng buộc an toàn bên ngoài, chứ không phải từ riêng RL. Chị coi đó là một kết quả kỹ thuật có ích.

Trong benchmark hiện tại, RL mang lại một decision surface học được và xem xét được, chứ chưa mang lại ưu thế về tỉ lệ thành công ngay lập tức. Giá trị của nó sẽ lớn dần khi lịch sử incident phong phú hơn, khi kết quả của action thay đổi theo ngữ cảnh, và khi việc duy trì tay mọi sở thích chọn action trở nên khó khăn.

![Slide Robustness and Ablation với biểu đồ chênh lệch điểm phần trăm](https://homus.dev/photos/LrGCT7G_rU8-1024.jpg)

Slide "Robustness and Ablation": biểu đồ chênh lệch theo điểm phần trăm qua 30 seed synthetic. Safety override so với không có override: âm 15,03 cộng trừ 0,66; RL so với rules: 0,00 cộng trừ 0,19; rules so với random: dương 15,63 cộng trừ 1,86. Cột chữ bên trái kết luận RL cho một policy xem xét được nhưng không vượt rules trong benchmark này, và phần lớn độ tin cậy đến từ decision logic có cấu trúc cùng guardrail bên ngoài.

## 13. Ranh giới validation hiện tại và bước kế tiếp

Slide này định nghĩa ranh giới validation hiện tại, tức những gì prototype chưa chứng minh được:

- Kết quả đến từ các kịch bản synthetic.

- Agent phản ứng sau khi có tín hiệu lỗi. Nó không dự đoán lỗi trước khi lỗi xảy ra.

- Độ đa dạng của incident thật có thể vượt quá state space hiện tại.

- Một số remediation action được mô phỏng, hoặc cố ý giới hạn.

- Online learning trong môi trường production sẽ đòi hỏi approval gate nghiêm ngặt, policy có version, hỗ trợ rollback và monitoring liên tục.

Kết quả là một minh chứng khả thi đáng tin cho thiết kế hệ thống, với một lộ trình rõ ràng tới validation trên production. Bước tiếp theo là một đợt deploy ở shadow mode trên các incident trace mang tính đại diện: ở đó các khuyến nghị của agent được so với quyết định của con người trước khi agent được trao quyền thực thi.

![Slide Current Limitations liệt kê những gì prototype chưa chứng minh](https://homus.dev/photos/LrGCT7G_rU8-1144.jpg)

Slide "Current Limitations, What This Prototype Does Not Yet Prove": năm giới hạn ở trên, và câu kết: công trình này chứng minh tính khả thi và thiết kế hệ thống, chưa phải độ hoàn chỉnh cho production.

## 14. Năm takeaway cho một engineering team

Chị để lại năm takeaway:

- Dùng logic deterministic cho những facts đo trực tiếp được.

- Chỉ dùng learning ở nơi việc chọn action theo ngữ cảnh thực sự mang lại giá trị.

- Đặt các ràng buộc an toàn bên ngoài learned policy, để một lần cập nhật policy không thể âm thầm định nghĩa lại quyền hạn của chính nó.

- Coi escalation và validation sau action là kết quả hạng nhất (first-class outcome), không phải nhánh ngoại lệ.

- Evaluate qua nhiều seed lặp lại và so với các baseline đơn giản. Một lần chạy đẹp là một bản demo, không phải bằng chứng.

Một hệ thống tự phục hồi (self-healing) thực dụng không cần model lớn nhất có thể. Nó cần một state rõ ràng, action có giới hạn, evaluation tái lập được, quyết định quan sát được, và kỷ luật để dừng lại khi độ bất định vượt quá quyền hạn của nó.

![Slide Takeaways với năm nguyên tắc và mã QR tới repository](https://homus.dev/photos/LrGCT7G_rU8-1232.jpg)

Slide "Takeaways, Small AI Can Still Deliver Operational Value": năm nguyên tắc trên, mã QR dẫn tới repository GitHub, và câu kết: một pipeline tự phục hồi thực dụng không cần model khổng lồ, nó cần quyền hạn có giới hạn, bằng chứng tái lập được, và kỷ luật escalate khi không chắc chắn.

## 15. Quay lại người engineer lúc hai giờ sáng

Chị đưa người nghe trở lại với người engineer trong đoạn video mở đầu. Mục tiêu không phải là loại bỏ phán đoán của con người, mà là thôi tiêu phán đoán đó vào cùng một lỗi quen thuộc lúc hai giờ sáng.

**Trước:** phản ứng là xem log bằng tay, lần theo schema, dashboard bị trễ, và quá trình phục hồi được đo bằng ngày làm việc.

**Sau:** đường đi thường lệ trở thành chẩn đoán được trigger bởi event, action được RL dẫn dắt nhưng bị ràng buộc bởi safety, validation tường minh, và phục hồi được đo bằng phút khi ca đó nằm trong phạm vi hệ thống hỗ trợ. Những lỗi bất thường hoặc rủi ro cao vẫn đi tới con người.

Đó chính là điểm mấu chốt: sự chú ý của con người được dành cho những incident mà context, các đánh đổi (trade-off), hoặc quyền hạn thực sự đòi hỏi.

![Slide From reactive debugging to intelligent recovery so sánh trước và sau](https://homus.dev/photos/LrGCT7G_rU8-1336.jpg)

Slide "From reactive debugging to intelligent recovery!": mục tiêu không phải thay thế phán đoán của con người mà là để dành nó cho những lỗi thật sự cần. Cột Before (xem log tay, lần theo schema, dashboard trễ, MTTR mô hình hoá 2,5 ngày làm việc) đối lập với cột After (chẩn đoán theo event, remediation có RL dẫn dắt, escalation có ràng buộc an toàn, phục hồi trong vài phút), minh hoạ bằng hai ảnh biểu cảm trước và sau.

Code, synthetic benchmark, các script thí nghiệm và hướng dẫn tái lập đều có trong [repository GitHub](https://github.com/ambenzon27/rl-etl-remediation-agent) hiện trên màn hình. Nếu bạn làm về độ tin cậy của agent, data quality, hay tự động hoá xử lý incident trên production, chị đặc biệt mong nhận feedback về ba điểm: cách biểu diễn state, thiết kế reward, và ranh giới an toàn. Chị cảm ơn mọi người đã theo dõi.

![Slide Thank You với tên và đơn vị của Anna Marie P. Benzon](https://homus.dev/photos/LrGCT7G_rU8-1416.jpg)

Slide cảm ơn: code, benchmark và hướng dẫn tái lập có trong repository công khai, mọi feedback kỹ thuật đều được hoan nghênh. Bên dưới là tên Anna Marie P. Benzon, PhD in Artificial Intelligence, University of the Philippines Diliman, cùng mã QR tới LinkedIn và GitHub.

## Sources and links

- [Trang talk chính thức trên ai.engineer](https://ai.engineer/talks/LrGCT7G_rU8)

- [ambenzon27/rl-etl-remediation-agent](https://github.com/ambenzon27/rl-etl-remediation-agent): code, synthetic benchmark, script thí nghiệm và AWS Lambda template

- [AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/what-is-glue.html), [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html), [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html), [CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html), [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html)

- [Q-learning](https://en.wikipedia.org/wiki/Q-learning)

- LinkedIn của Anna Marie Benzon: linkedin.com/in/anna-marie-benzon