Why Your Agent Disagrees With Itself (And What To Do About It)

1. Diane Lin: từ nghiên cứu AGI tới agent cho SOC

Talk này trả lời hai câu hỏi: vì sao AI agent của bạn lại bất đồng với chính nó, và bạn nên làm gì với chuyện đó. Người trình bày là Dianhuan Lin, thường gọi là Diane.

Diane kể nhanh hành trình của mình. Chặng đường với AGI của chị bắt đầu từ PhD tại Imperial College London, nơi chị làm về continual learning. Sau đó chị làm cùng Giáo sư Josh Tenenbaum ở MIT về one-shot learning, tức là học từ chỉ một ví dụ duy nhất. Tiếp theo, chị may mắn có mặt đúng lúc Alexa ra mắt: chị là một trong ba applied scientist đầu tiên của nhóm question answering trên Alexa.

Rồi chị bị cuốn sang một startup làm AGI ở Silicon Valley tên là Vicarious. Theo lời chị, Vicarious ngày nay là một phần của Google DeepMind. Ở đó chị được làm những nghiên cứu tiên phong về zero-shot transfer learning. Sau vài năm làm AGI, chị quyết định rẽ sang thế giới ứng dụng ở Zscaler, một công ty cybersecurity, nơi chị áp dụng đủ loại model machine learning khác nhau để giải các bài toán bảo mật.

Sau năm năm ở Zscaler, chị đồng sáng lập công ty riêng, xuất phát từ chính nỗi đau đã thấy ở đó. Culminate xây AI agent để tự động triage security alert, giúp SOC (security operations center) làm việc hiệu quả hơn. Chị rất tự hào khi Culminate được Datadog mua lại đầu năm nay. Giờ chị là người của Datadog và dẫn dắt việc phát triển self-evolving agent, tức agent tự tiến hoá theo thời gian.

Slide mở đầu: tên talk, tên diễn giả Dianhuan (Diane) Lin và logo Datadog. Góc trên bên phải là camera của diễn giả.

Slide Background với dòng thời gian Imperial College London, Amazon Alexa, Vicarious, Zscaler, Culminate và Datadog — Slide "Background" xếp các chặng theo thứ tự: PhD Machine Learning tại Imperial College London và research affiliation ở MIT CSAIL; founding applied scientist trong nhóm Alexa của Amazon; Senior Researcher ở Vicarious (slide ghi "acquired by Google DeepMind"); Director of Machine Learning ở Zscaler; CTO & Co-founder của Culminate (acquired by Datadog); và hiện là Tech Lead ở Datadog với mảng "Self-Evolving AI Agents for the Modern SOC".

2. Vấn đề: cùng model, cùng input, khác output

Lộ trình của talk gồm bốn phần. Đầu tiên là vấn đề mà nhiều khả năng bạn đang gặp hằng ngày khi xây AI agent: sự thiếu nhất quán (inconsistency). Sau đó là câu hỏi inconsistency đến từ đâu, vì phải hiểu nguồn gốc thì mới tìm ra lời giải. Tiếp theo là vài trade-off giữa các giải pháp khác nhau, và cuối cùng là kết quả thực nghiệm cho thấy các giải pháp đó khả thi tới đâu.

Slide Agenda với bốn mục — Agenda gồm bốn mục: The Problem (LLM inconsistency trong thực tế), Where Does Inconsistency Come From, Solutions, và Experimental Results.

Hiện tượng chắc bạn đã thấy: cùng một model, cùng một input, nhưng output khác nhau. Diane nói rõ ở đây chị không nói về chuyện câu chữ khác nhau, mà là output khác nhau về mặt ngữ nghĩa, tức là kết luận khác nhau. Có thể bạn đang nghĩ: đó là bản chất stochastic của LLM thôi. Chị bảo hãy giữ suy nghĩ đó lại, rồi cùng xem vài ví dụ cụ thể.

Slide The Problem: Same model. Same input. Different output. — Slide "The Problem" tóm vấn đề trong một dòng: cùng model, cùng input, khác output.

Ví dụ thứ nhất là sentiment analysis: bạn giao cho model nhiệm vụ gán nhãn từng review khách sạn là positive hoặc negative. Đây là một task NLP rất điển hình, và LLM ngày nay làm việc này rất tốt. Thế nhưng có một vấn đề. Khi bạn đưa cùng input này vào cùng một LLM, thỉnh thoảng bạn sẽ thấy kết luận (verdict) khác nhau khi chạy nhiều lần. Điều đó có nghĩa là một lần chạy evaluation duy nhất không kể cho bạn toàn bộ câu chuyện.

Slide LLM Inconsistency in Practice với hai review khách sạn A và B — Hai review khách sạn dùng xuyên suốt talk. Review A khen hết lời: vị trí hoàn hảo, đi bộ năm phút tới bảo tàng và nhà hàng, phố yên tĩnh, anh concierge tên David gợi ý chỗ ăn rất hay, "highly recommend". Review B lưng chừng: sạch sẽ và an toàn, nhưng thiếu hẳn cá tính, check-in qua kiosk nên không gặp một nhân viên nào, phòng "vô trùng như phòng bệnh viện", ổn cho một đêm trước chuyến bay sớm, "chỉ đừng mong một trải nghiệm hospitality đáng nhớ".

3. Trong cybersecurity, flip-flop là vấn đề niềm tin

Vì một lần chạy không đủ, bạn phải lặp lại evaluation nhiều lần và lấy trung bình kết quả các lần chạy thì mới có bức tranh tổng thể. Nghe thì giống một sự bất tiện kỹ thuật, nhưng thực tế nó nghiêm trọng hơn nhiều. Diane đưa sang một lĩnh vực khác để cho thấy điều đó: cybersecurity.

Hãy tưởng tượng bạn là một security analyst. Công việc hằng ngày của bạn là triage security alert: quyết định một alert là malicious, nghĩa là bạn phải hành động để chặn cuộc tấn công, hay là false alarm, nghĩa là thực ra nó benign và có thể bỏ qua. Alert ví dụ ở đây là: phát hiện một lần đăng nhập thất bại vào tài khoản Gmail từ một IP đáng ngờ.

Slide LLM Inconsistency in Practice với alert Failed login attempt to gmail account detected from suspicious IP — Ví dụ thứ hai: triage cyber security alert với nội dung "Failed login attempt to gmail account detected from suspicious IP".

Nếu giao những task tương tự như thế cho AI agent và chạy nhiều lần, bạn sẽ thấy có alert lúc nào cũng ra benign, có alert lúc nào cũng ra suspicious qua các lần chạy. Nhưng cũng có những ca mà agent lật qua lật lại (flip-flop) giữa benign và suspicious. Lúc này khách hàng sẽ rất khó dùng sản phẩm của bạn, vì họ sẽ tự hỏi: tôi nên tin kết quả nào? Như vậy inconsistency đang gây ra một vấn đề về niềm tin (trust) đối với sản phẩm.

Diane đưa thêm một hình ảnh: bạn đang ở trong một vòng POC bake-off, tức khách hàng cho nhiều vendor chạy thử song song để so. Một vendor cho verdict nhất quán mọi lúc, vendor còn lại có verdict flip-flop. Bạn có thể đoán ai sẽ thắng hợp đồng.

Chị khá chắc là bạn muốn giải quyết vấn đề này. Việc đầu tiên là phải tìm ra inconsistency đến từ đâu.

4. Gray zone: dữ liệu nằm sát decision boundary

Tin tốt là những data point hay flip-flop thực ra tập trung quanh decision boundary, vùng mà Diane gọi là gray zone. Chị minh hoạ lại bằng ví dụ sentiment analysis với hai review.

Slide chuyển phần: Where Does the Inconsistency Come From? — Slide chuyển sang phần hai: inconsistency đến từ đâu.

Review thứ nhất, dù chạy qua LLM bao nhiêu lần, cũng luôn được gán nhãn positive. Ca này quá rõ: review cực kỳ tích cực. Review thứ hai mới là ca hay bị lật. Nhìn kỹ thì nó nằm ngay trên ranh giới. Có những chữ trong đó đọc lên thì tương đối tích cực, nhưng cũng có lúc lại hơi tiêu cực.

Slide Gray zone: data that sit near the decision boundary, với lại hai review A và B — Cùng hai review A và B, giờ dưới tiêu đề "Gray zone: data that sit near the decision boundary". Review A luôn ra positive; Review B (sạch, an toàn nhưng vô hồn) là ca nằm trên ranh giới.

Với những ca như vậy, chính các chuyên gia con người cũng sẽ bất đồng với nhau. Thực ra ở đây không có đáp án đúng hay sai. Mọi thứ phụ thuộc vào policy và preference của từng công ty. Một khách sạn có thể nghĩ rằng review kiểu này nói về thứ họ chẳng làm gì được để cải thiện cái gọi là trải nghiệm đáng nhớ (Diane nói nhịu "memorial" rồi bật cười sửa thành "memorable"), nên không gán nhãn negative, vì chẳng có hành động nào để làm. Nhưng một khách sạn khác lại quan tâm tới đúng điểm đó và muốn gán nhãn negative để còn cải thiện. Cuối cùng, nó quy về preference của bạn.

5. Gray zone trong security: kẻ tấn công gõ cửa nhưng chưa vào

Quay lại ví dụ cybersecurity. Đây cũng là một ca nằm trên ranh giới, và lý do là: có vài lần thử đăng nhập. Đúng là có kẻ tấn công đang gõ cửa, nhưng có thể nó chưa vào được.

Slide Gray zone với alert Failed authentication attempts detected from suspicious IP và bảng verdict qua ba lần chạy — Gray zone trong security: alert "Failed authentication attempts detected from suspicious IP". Bên phải là bảng ba cột verdict_iter0, verdict_iter1, verdict_iter2: nhiều dòng giữ nguyên benign hoặc suspicious qua cả ba lần chạy, nhưng có không ít dòng đổi nhãn giữa các lần.

Với khách hàng enterprise, lúc nào cũng có kẻ tấn công gõ cửa. Nếu chúng chưa vào được môi trường, khách hàng không muốn bận tâm, nếu không họ sẽ ngập trong loại alert này. Họ chẳng cần làm gì, vì kẻ tấn công đã bị chặn ở ngoài rồi. Nhưng nếu kẻ tấn công đoán đúng mật khẩu, vượt qua được MFA và vào được môi trường, thì chuyện trở nên rất nghiêm trọng và bạn phải hành động.

Tức là hành vi lúc đầu gần như giống hệt nhau, nhưng kết cục rất khác nhau và cách phản ứng cần có cũng khác nhau, tuỳ vào việc đó thực sự là một cuộc tấn công đã thành hay kẻ tấn công vẫn còn ở ngoài. Vì vậy gán nhãn malicious hay benign ở đây phụ thuộc vào preference của công ty: họ có muốn được báo về tình huống như thế không. Một lần nữa, đây là ví dụ mà kết quả phụ thuộc vào preference của bạn và vào thông tin bổ sung để phân biệt hai kịch bản.

Hình minh hoạ gray zone: chấm đỏ và chấm xanh hai bên một đường chéo nét đứt, vùng xám dọc đường đó — Hình minh hoạ gray zone: chấm đỏ một bên, chấm xanh một bên, ngăn bởi decision boundary nét đứt. Dải xám dọc theo đường đó là gray zone, nơi có ba chấm được tô viền đậm: đó là những data point sát ranh giới, loại dễ bị flip-flop nhất.

Từ hai lĩnh vực rất khác nhau, bạn thấy cùng một quy luật: những data point hay flip-flop là những điểm nằm gần decision boundary, nơi cần bạn làm rõ để phân định nó thực sự thuộc về bên nào. Đây cũng chính là những data point mà chuyên gia con người hay mắc lỗi, và các classifier machine learning truyền thống cũng chật vật với chúng. Nói cách khác, đó không phải lỗi của AI agent. Agent của bạn chỉ đơn giản là chỉ ra sự mơ hồ vốn đã tồn tại sẵn.

6. Active learning: biết chính xác cần nhìn vào đâu

Giờ đã biết root cause của inconsistency nằm ở đâu, bước tiếp theo là xác định chính xác chúng ở chỗ nào, là những ca nào, rồi sửa chúng. Điều vừa bất ngờ vừa không bất ngờ là lời giải để tìm ra gray zone đã có sẵn trong machine learning, và nó tên là active learning.

Slide Identifying the Gray Zone: Active learning — Slide chuyển phần: "Identifying the Gray Zone: Active learning", với dòng phụ "Active learning tells us exactly where to look".

Ý tưởng của active learning như sau. Bạn có rất nhiều data point cần gán nhãn. Hãy hình dung bạn có một model ban đầu, đưa nó lên production, có thể ở monitor mode, và muốn kiểm tra chất lượng, nhưng bạn không có đủ thời gian để xem hết. Nếu xem hết thì còn gì là ý nghĩa của việc để agent làm thay. Dù vậy bạn vẫn muốn biết model làm chưa tốt ở đâu. Active learning là cách chọn ra những data point mà model có xu hướng sai, và nhờ đó cho bạn biết nên dồn sự chú ý vào đâu.

Diane đi qua pipeline active learning của machine learning truyền thống, rồi xem nó khác gì trong thời LLM và AI agent.

Sơ đồ Traditional ML Active Learning Pipeline tám bước thành một vòng lặp — "Traditional ML Active Learning Pipeline": (1) một tập nhỏ dữ liệu đã gán nhãn, (2) train model ban đầu, (3) một pool lớn dữ liệu chưa gán nhãn, (4) model inference dự đoán nhãn hoặc xác suất cho toàn bộ pool, (5) query strategy chọn ra ví dụ giàu thông tin nhất (uncertainty sampling, query by committee, expected error reduction, diversity sampling...), (6) chuyên gia con người gán nhãn các ví dụ được chọn, (7) thêm chúng vào tập đã gán nhãn, (8) retrain hoặc fine-tune model. Ở giữa: lặp lại tới khi hết ngân sách gán nhãn hoặc model hội tụ. Mục tiêu: với ngân sách gán nhãn hạn chế, chủ động chọn những ví dụ giàu thông tin nhất để model học tốt hơn, nhanh hơn.

Trước hết bạn train model ban đầu, rồi cho nó dự đoán trên tập dữ liệu chưa gán nhãn, có thể chính là dữ liệu online ở production. Từ đó bạn thấy có những ca model không chắc chắn vì xác suất xấp xỉ 0.5. Đó là những data point giàu thông tin nhất, nơi model sẽ học được nhiều nhất. Uncertainty là một loại tín hiệu cho biết model dễ sai ở đâu.

Một cách phổ biến khác để tìm ra ca có vấn đề là query by committee: cho vài model khác nhau, hoặc thậm chí cùng một model chạy nhiều lần, rồi tìm chỗ chúng bất đồng. Đó cũng là chỗ model dễ sai, và là chỗ cần con người làm rõ nhãn để model học theo.

Sau khi đã đưa những data point có vấn đề lên để con người xem lại lần hai, người đó đảm bảo nhãn thực sự đúng, hoặc xác định ca đó có cần thêm thông tin để phân định hay không, tức là thêm feature mới. Rồi bạn đưa dữ liệu đã gán nhãn, và có thể cả feature bổ sung, vào vòng train tiếp theo. Bạn retrain model và tiếp tục vòng lặp.

Trong vòng active learning này, bạn chỉ bỏ ra rất ít công sức, hay nói cách khác, đây là một cách rất hiệu quả để tìm ra data point có vấn đề và dồn sự chú ý vào những điểm mà model học được nhiều nhất. Đó là phiên bản truyền thống.

7. Active learning trong thời LLM: chọn theo disagreement

Tin tốt là cách làm với LLM không khác mấy. Có hai phần chính cần tinh chỉnh: một là selection strategy (cách chọn ca), hai là bước retrain.

Sơ đồ Typical LLM Active Learning Pipeline tám bước — "Typical LLM Active Learning Pipeline": (1) một pool prompt hoặc task chưa gán nhãn, (2) LLM hiện tại sinh nhiều response cho mỗi prompt, (3) pool ví dụ chưa gán nhãn, (4) model inference, (5) query by committee, tức tìm disagreement: dùng nhiều model (committee) và chọn những prompt có bất đồng lớn nhất, (6) human annotation và feedback: viết câu trả lời lý tưởng, xếp hạng response, sửa nhãn, (7) agent memory: lưu domain knowledge (guideline, tài liệu, rule, best practice) và past similar cases (prompt, response, human feedback, kết quả) để dùng cho các lần sau, (8) fine-tune hoặc preference train để cập nhật LLM. Mục tiêu ghi dưới cùng: chủ động chọn prompt giàu thông tin nhất, lấy feedback chất lượng cao từ con người và liên tục cải thiện LLM với công sức gán nhãn tối thiểu.

Về selection strategy, Diane khuyên dùng hướng tìm disagreement. Ít nhất là theo những gì nhóm chị đã thử tới nay, uncertainty score do LLM tự báo không đáng tin lắm. LLM không biết là nó không biết gì. Khi nó rất tự tin, điều đó không có nghĩa là nó đúng.

Ngược lại, disagreement giữa các lần chạy khác nhau, hoặc giữa các model khác nhau, cho bạn một tín hiệu đáng tin hơn nhiều về chỗ model thực sự không chắc về verdict của mình và cần con người hướng dẫn. Sau khi tìm ra nhóm ca bất đồng cần chú ý này, bạn gán nhãn và đưa feedback y như trước.

8. Không cần fine-tune đắt tiền: semantic memory

Đến đây có thể bạn nghĩ: "À, tới lúc retrain model rồi." Diane trả lời: vừa đúng vừa không. Đúng, một lựa chọn là retrain model, nhưng fine-tune model thì đắt. Nhóm chị đề xuất một giải pháp nhẹ hơn, dễ lặp nhanh hơn: bổ sung cho agent semantic memory và episodic memory.

Slide Improving the Model Without Expensive Fine-Tuning — Slide chuyển phần: "Improving the Model Without Expensive Fine-Tuning", với lựa chọn nhẹ hơn là bổ sung semantic memory và episodic memory cho agent.

Chị dùng lại ví dụ cũ để minh hoạ. Như đã nói, những ca hay bị lật chủ yếu là vì thiếu thông tin về policy hoặc preference của từng công ty. Bạn có thể đưa thông tin đó vào knowledge base. Với khách sạn: nếu khách phàn nàn về điều gì đó nằm ngoài tầm kiểm soát của khách sạn thì phân loại review là positive, vì bạn không muốn tốn sự chú ý vào loại này.

Slide Semantic Memory: Domain Knowledge với hai review và một rule tô màu ở dưới — "Semantic Memory: Domain Knowledge" cho bài toán review khách sạn. Bên dưới hai review là rule được thêm vào: "If the customer complains about something outside the hotel's control, classify the review as positive."

Với ví dụ cybersecurity cũng tương tự. Bạn có thể ghi rằng: password spray, tức kẻ tấn công thử đoán mật khẩu nhiều lần với nhiều giá trị khác nhau, nếu thất bại liên tục và không có lần đăng nhập thành công nào thì nên coi là benign. Ngược lại, nếu cuối cùng có một lần đăng nhập thành công thì nên coi là malicious.

Slide Semantic Memory cho security alert với rule password spray và hai gạch đầu dòng — Cùng ý đó cho alert "Failed authentication attempts detected from suspicious IP". Rule trên slide: "Password spray without successful login should be benign. In contrast, password spray with final successful login should be considered malicious." Hai gạch đầu dòng bên dưới: domain knowledge làm sắc nét decision boundary, và giúp người review đưa ra quyết định nhất quán hơn.

Ở đây bạn đã xác định được thông tin bổ sung để phân định hai trường hợp, rồi gán nhãn chúng riêng biệt. Chính sự rõ ràng đó giúp model học, và cũng giúp chuyên gia con người gán nhãn nhất quán hơn. Loại domain knowledge này làm decision boundary sắc nét hơn và giúp cả con người.

Kiểu kiến thức này giống như factual knowledge, và thuộc về semantic memory.

If the customer complains about something outside the hotel's control, classify the review as positive.

Password spray without successful login should be benign. In contrast, password spray with final successful login should be considered malicious.

9. Episodic memory: dựa vào các ca tương tự trong quá khứ

Semantic memory đối lập với episodic memory. Episodic memory dùng cho trường hợp bạn chưa kịp chắt lọc lý do đằng sau những ca trước, vì sao ca đó nên nằm phía malicious hay phía benign. Thay vào đó bạn nói: tôi đã thấy những ca tương tự thế này trước đây, chúng được gán nhãn benign, hãy dựa vào những ca quá khứ tương tự đó và quyết định theo.

Ưu điểm của episodic memory là nó tương đối tự động, ít cần con người can thiệp. Nói đúng hơn, phần can thiệp của con người đã được làm trong quá khứ rồi. Khi agent đang làm việc online, nó có thể tự tham chiếu những ca đó và ra quyết định mà không phải chờ bạn chắt lọc lý do rồi đưa vào semantic knowledge.

Slide Episodic Memory: Past Similar Cases với hình embedding space — "Episodic Memory: Past Similar Cases" minh hoạ trong embedding space. Ngôi sao xanh là ca mới; chấm xanh lá là các ca tương tự trong quá khứ đã gán benign; chấm đỏ là các ca tương tự đã gán malicious; chấm xám là các ca khác. Các đường nét đứt nối ca mới với những ca gần nhất của nó.

Ý tưởng là tìm những ca tương tự với ca đang xét, rồi dùng quyết định trước đây của chúng làm tham chiếu. Giờ hãy tưởng tượng có một ca mới nằm lơ lửng ở giữa, không thuộc nhóm quá khứ nào. Đó là ca vẫn cần con người chú ý.

Đây cũng là cách episodic memory tự xử lý những ca lặp lại. Điều này đặc biệt hữu ích với security alert, vì rất nhiều noise, nhất là noise false positive, cứ lặp đi lặp lại. Đó chính là "quả ngọt ở cành thấp" mà bạn có thể tự động hoá đi. Còn sự chú ý của người review, thứ băng thông quý giá bạn có, giờ có thể dồn vào những ca mà episodic memory không giải quyết được.

10. Semantic memory và episodic memory bổ trợ nhau

Đây cũng là cách chọn giữa semantic memory và episodic memory. Hai thứ này thực ra không mâu thuẫn. Chúng bổ trợ cho nhau.

Slide Semantic Memory vs Episodic Memory với ba gạch đầu dòng — "Semantic Memory vs Episodic Memory": hai thứ bổ trợ nhau. Episodic memory xử lý tự động các tình huống lặp lại; các ca vẫn còn lật chính là những ca đáng để con người xem lại; human review chắt lọc domain knowledge để đưa vào semantic memory.

Về cơ bản, bạn dùng episodic memory để tự động xử lý những tình huống lặp lại. Phần còn lại, tức những ca vẫn flip-flop sau khi đã tham chiếu quá khứ, hoặc không có ca quá khứ nào để tham chiếu, thì chuyển cho người review. Người review chắt lọc domain knowledge và đưa nó vào semantic memory để dùng cho lần sau.

Vòng lặp Diane mô tả: episodic memory tự xử lý những ca lặp lại; ca vẫn còn lật hoặc không có ca tương tự thì chuyển cho người review; người review chắt lọc domain knowledge thành rule trong semantic memory để agent dùng ở lần sau.

11. Một giải pháp, ba lợi ích

Giải pháp vừa trình bày mang lại ba lợi ích.

Thứ nhất, nhờ tìm ra những data point gần decision boundary, rồi dùng domain knowledge trong semantic memory và các ca tương tự trong episodic memory, bạn cải thiện tính nhất quán một cách đáng kể. Giờ bạn có một AI agent đáng tin hơn cho người dùng.

Hai lợi ích còn lại là sản phẩm phụ. Một là bạn có một quy trình quality control rất hiệu quả. Bạn không cần kiểm từng output của agent, mà chỉ kiểm một tập con mà thuật toán active learning cho là có khả năng có vấn đề. Bạn xem chúng, bổ sung thông tin hoặc làm rõ nhãn, và model học từ đó. Quan trọng nhất, công sức gán nhãn của bạn rất nhỏ nhưng lợi ích thu về rất cao.

Cuối cùng nhưng không kém phần quan trọng, dọc đường bạn đang thu thập feedback của khách hàng. Bạn không chỉ có một model đáng tin, nhất quán và hiệu quả cao, mà còn có một model thích nghi với môi trường của khách hàng. Diane khá chắc là khách hàng sẽ yêu sản phẩm của bạn nếu AI agent của bạn biết lắng nghe và thích nghi theo họ.

Slide One Solution, Three Benefits với ba thẻ — "One Solution, Three Benefits": Higher Consistency nhờ làm rõ decision boundary; Better Quality Control nhờ chỉ đưa ca mơ hồ cho người review; Better Customer Alignment nhờ liên tục thích nghi theo policy và preference riêng của từng khách hàng.

12. Kết quả thực nghiệm trên 93 alert

Diane đưa ra kết quả thực nghiệm trên data point thật. Nhóm chị thu thập 93 security alert và chạy mỗi alert ba lần.

Nếu không dùng giải pháp đề xuất, một phần tư số alert, tức 25%, bị flip-flop verdict. Sau khi áp dụng giải pháp, cụ thể là dùng episodic memory, khoảng 15% trong số đó trở nên nhất quán. Tuy vậy vẫn còn 10% không nhất quán. Chúng vẫn lật, có khi vì không có ca tương tự nào trong quá khứ để tham chiếu, có khi dù có tham chiếu thì sau khi "nghĩ lại" model vẫn bất đồng.

Điều đó không thành vấn đề. Episodic memory tự động hạ inconsistency đi 15%, còn 10% còn lại thì người review xem và bổ sung kiến thức để phân định những ca khó đó. Sau bước này, bạn cũng thích nghi được với môi trường của khách hàng mà bạn muốn học theo.

Slide Experimental Results: 93 alerts, 3x reruns, 25% flip-flop trước, 10% còn lại sau episodic memory — "Experimental Results" chia ba cột. Experiment setup: 93 alert, chạy lại 3 lần. Before: 25% verdict flip-flop, phần còn lại nhất quán. After, systemic improvement: với episodic memory, 10% vẫn không nhất quán (90% nhất quán); human review xử lý 10% ca mơ hồ đó.

Cách đọc con số trên 93 alert chạy ba lần: 25% ban đầu bị lật; episodic memory tự làm nhất quán khoảng 15%; 10% còn lại là phần dành cho người review.

13. Ba điều nên mang về

Diane muốn người nghe mang về ba điều.

Inconsistency thường không phải vấn đề của model. Đừng đổ lỗi cho model nữa. Hãy dồn sức vào vấn đề nhãn và vào khả năng thông tin chưa đủ, rồi giúp AI agent bằng sự rõ ràng bổ sung đó.
Model disagreement không phải bug, mà là feature. Hãy coi mỗi lần bất đồng là một cơ hội để model học.
Fine-tune không phải lựa chọn duy nhất. Hãy trang bị cho agent semantic memory và episodic memory.

Slide Takeaways với ba gạch đầu dòng — "Takeaways": inconsistency thường không phải vấn đề của model (mà là label ambiguity cộng thông tin chưa đủ); model disagreement không phải bug mà là feature; fine-tune không phải lựa chọn duy nhất, hãy bổ sung semantic memory và episodic memory cho agent.

Chị mong bạn sẽ thích thú khi thấy model của mình liên tục tiến bộ và thích nghi với môi trường của khách hàng.

Cuối cùng, Diane cảm ơn các đồng nghiệp và bạn bè ở Datadog. Chị gửi lời cảm ơn đặc biệt tới bảy đồng nghiệp đã cùng chị có nhiều cuộc thảo luận thú vị và giúp chị làm rõ một số khái niệm. Chị cũng cảm ơn toàn bộ Datadog Bits Security Analyst Team đã làm cho hành trình này trở nên thú vị. Chị cảm ơn mọi người đã lắng nghe và chúc mọi người vui khi train model và thấy nó tiến bộ.