Tracely: biến trace lỗi AI agent thành test replay để chặn PR tái phạm
Tracely hướng tới việc đóng băng trace lỗi của AI agent thành regression test có thể replay offline trong CI. Với QA, đây là cách đưa bug production thành hàng rào chống tái phạm — nhưng vẫn cần review assertion và hiệu chỉnh judge.
Một AI agent vừa trả lời sai cho khách hàng. QA mở dashboard, lần theo trace, đọc tool call và phản hồi model, rồi tạo bug ticket. Vài ngày sau, bản sửa được merge — nhưng một thay đổi nhỏ ở workflow lại làm lỗi cũ quay lại.
Vấn đề là: bug production thường có đủ bằng chứng, nhưng hiếm khi được chuyển thành test case sống trong pipeline. Nó nằm trong ticket, ảnh chụp màn hình hoặc log khó tái tạo.
Tracely tiếp cận bài toán này theo hướng “trace-native CI/CD”: trace của lần chạy lỗi không chỉ để quan sát, mà có thể được đưa thành regression test để replay trong CI và phát hiện pull request tái phạm.
Trace-native CI có ý nghĩa gì với QA?
Một trace là bản ghi theo luồng của một lần agent thực thi: input, các bước xử lý, hand-off, lời gọi tool, phản hồi từ LLM và kết quả. Theo README, Tracely nhận trace qua OTLP và đưa các ngữ nghĩa như agent, hội thoại, lượt và bước chạy thành các cột có thể lập chỉ mục.
Vòng lặp mà dự án mô tả gồm năm bước:
Observe: thu trace của các lần chạy.
Detect & triage: evaluator chấm trace và gom failure tương tự thành cụm.
Test: đưa trace lỗi thành regression case.
Ship: replay case trong CI để phát hiện hồi quy.
Tell me: gửi cảnh báo qua Slack, email hoặc webhook.
Điểm đáng chú ý là nguồn gốc test. Thay vì bắt đầu bằng dataset tự viết gồm câu hỏi và đáp án kỳ vọng, Tracely hướng tới dùng chính lần chạy lỗi đã ghi nhận: input, đầu ra tool và đầu ra LLM được đóng gói thành fixture.
Fixture là dữ liệu cố định phục vụ kiểm thử. README mô tả việc replay trong CI là deterministic, chạy offline, không cần API key hay chi phí gọi model, vì dùng lại các fixture đã ghi.
Đây không thay thế test design của QA. Nó bổ sung một lớp test rất giá trị: những lỗi đã từng xảy ra ngoài thực tế. Boundary test, luồng mới chưa có trace, kiểm thử khả dụng và các tình huống nghiệp vụ vẫn cần QA chủ động thiết kế.
Từ bug production đến CI gate
README không nêu đầy đủ mọi bước cài đặt hoặc cấu hình ingest trace trong phần tài liệu được cung cấp. Tuy vậy, luồng sản phẩm đủ để QA hình dung cách phối hợp với developer.
1. Chọn trace đại diện cho lỗi thật
Khi nhận bug AI, đừng chỉ ghi “agent trả lời không đúng”. Hãy xác định trace có đủ bối cảnh:
Input hoặc ngữ cảnh khởi phát lỗi.
Tool call liên quan, gồm tham số và kết quả.
Chuỗi hand-off nếu có nhiều agent.
Output cuối cùng gây lỗi.
Metadata môi trường và verdict của evaluator, nếu đã có.
Tracely mô tả evaluator ở cấp conversation, run hoặc span. Có structural check không cần model và LLM-as-judge. QA nên chọn đúng đơn vị kiểm thử:
Lỗi ở câu trả lời cuối: kiểm tra conversation hoặc run.
Agent gọi sai tool: kiểm tra span liên quan đến tool.
Agent bỏ qua một bước bắt buộc: dùng structural check cho sự hiện diện hoặc thứ tự bước.
Lỗi nhiều lượt chat: cân nhắc scenario thay vì chỉ một request đơn.
2. Gom các failure trước khi tạo hàng loạt bug trùng nhau
Theo README, failure clustering kết hợp chữ ký cấu trúc và embedding ngữ nghĩa để gom failure tương tự thành một issue có số lần xuất hiện.
Điều này hữu ích khi QA nhận nhiều report khác câu chữ nhưng cùng nguyên nhân. Thay vì tạo nhiều regression test lặp lại, hãy kiểm tra:
Đây có thực sự là một failure mode?
Trace nào nhỏ nhất nhưng vẫn tái hiện đúng lỗi?
Có biến thể biên nào cần giữ thành scenario riêng?
Evaluator đang bắt đúng lỗi hay đang đánh giá quá rộng?
Dự án cũng mô tả màn hình calibration để đối chiếu verdict của judge với đánh giá con người. Đây là bước quan trọng trước khi dùng LLM judge làm điều kiện chặn release: judge đánh dấu sai quá nhiều có thể khiến CI đỏ không cần thiết.
3. Đóng băng trace lỗi thành regression case
Tracely mô tả thao tác promote trace lỗi thành case. Case gồm input đã ghi nhận cùng fixture cho tool và LLM, kèm một fail-to-pass contract.
Với QA, contract này cần được hiểu rõ:
Case phải fail trên code cũ.
Case phải pass trên bản sửa.
Nếu không thỏa cả hai, chưa có đủ bằng chứng rằng case bắt đúng lỗi.
Đừng đóng băng một trace chỉ vì kết quả “trông có vẻ xấu”. Test cần chứng minh rằng nó phát hiện được hành vi lỗi và bản sửa thực sự giải quyết hành vi đó.
Với hội thoại nhiều lượt, README nêu hai hướng: scripted conversation hoặc một mục tiêu đối kháng để red-team model ứng biến. Nếu dùng hướng thứ hai, QA vẫn cần review độ ổn định của tiêu chí pass/fail trước khi đưa vào gate.
Ví dụ giả định: biến bug agent hỗ trợ thành test replay
Giả sử feature có yêu cầu đã được phê duyệt:
> Agent hỗ trợ phải tra cứu đơn hàng trước khi trả lời về trạng thái giao hàng. Nếu không tìm thấy đơn, agent cần nói rõ không tìm thấy thay vì tự suy đoán.
Một trace production cho thấy người dùng hỏi về <mãđơn>, nhưng agent không gọi tool tra cứu và lại khẳng định đơn đang giao.
Một regression case có thể mô tả kỳ vọng như sau:
text
Mục tiêu case:
Input: “Kiểm tra trạng thái đơn <mãđơn>”
Fixture tool: không trả về đơn hàng tương ứng
Điều kiện fail: agent khẳng định một trạng thái giao hàng
Điều kiện pass: agent nêu rõ không tìm thấy đơn hoặc yêu cầu kiểm tra lại mã
Structural assertion: có lời gọi tool tra cứu trước khi đưa kết luận
Sau khi case được đưa vào suite, README cho biết tracely gate có thể trả về exit code khác 0 khi gate fail, đăng commit status và cập nhật bình luận trên pull request.
bash
tracely gate
Khi viết bug report để bàn giao, QA có thể ghi rõ:
text
Trace/case cần promote: <traceid>
Failure mode: Agent tự khẳng định trạng thái khi tool không có dữ liệu
Assertion chính: Không được khẳng định trạng thái nếu lookup không có kết quả
Assertion cấu trúc: Có tool lookup trước kết luận
Kỳ vọng sau fix: Case fail ở bản cũ, pass ở bản sửa
Rủi ro hồi quy: Thay đổi prompt, router hoặc tool schema
Prompt mẫu để AI hỗ trợ thiết kế assertion
AI có thể hỗ trợ chuyển bug thành assertion, nhưng không nên tự quyết expected result khi quy tắc nghiệp vụ chưa rõ.
text
Bạn là QA automation engineer.
Feature spec:
<dán yêu cầu đã được duyệt>
Bug production:
<dán mô tả đã ẩn dữ liệu nhạy cảm>
Tóm tắt trace:
User input: <input>
Tool calls: <toolcalls>
Tool results: <toolresults>
Agent output: <output>
Hãy đề xuất:
Một regression test case theo format Given/When/Then.
Assertion ở cấp output.
Structural assertion cho tool call hoặc thứ tự bước.
Các biến thể boundary và negative test.
Điều kiện nào không thể assert ổn định nếu output LLM không hoàn toàn xác định.
Không tự bịa business rule. Đánh dấu rõ mọi giả định cần PO hoặc QA xác nhận.
Kết quả tốt không phải là danh sách assertion dài. Nó cần phân biệt được yêu cầu nghiệp vụ, dấu hiệu kỹ thuật từ trace và những giả định cần xác nhận.
Checklist trước khi bật CI gate bắt buộc
Trace chính xác không tự động tạo thành test tốt. Trước khi biến case thành điều kiện chặn PR, QA nên review:
Expected result có đúng spec không? Trace phản ánh hành vi cũ, không tự định nghĩa hành vi đúng.
Fixture có đủ không? Thiếu tool response có thể làm replay đi sang nhánh khác.
Assertion có quá sát câu chữ không? Với LLM, nên ưu tiên quyết định, tool usage, schema hoặc thông tin bắt buộc hơn so với so khớp toàn văn.
Case có fail-to-pass thật không? Đây là bằng chứng chính cho giá trị của regression case.
Judge đã được calibration chưa? Không nên dùng verdict của LLM judge làm release gate nếu chưa đối chiếu với human review.
Dữ liệu nhạy cảm đã được xử lý chưa? Không đưa thông tin khách hàng, token, API key hoặc credentials vào prompt hay hệ thống không phù hợp.
Không phải lời giải duy nhất
Tracely hướng tới việc biến failure đã có trace thành regression test. Đây là thế mạnh cho regression từ production, nhưng không thay thế exploratory testing, usability testing, test dữ liệu biên chưa từng xuất hiện, kiểm thử bảo mật hay kiểm tra policy.
Fixture được ghi lại giúp replay ổn định và không tốn chi phí model trong CI. Đổi lại, QA vẫn cần bổ sung case khi tool contract, policy hoặc hành vi mong muốn thay đổi. Một trace của quá khứ không tự bao phủ mọi rủi ro của thay đổi mới.
Checklist chốt: tìm trace thật, xác nhận failure mode, viết assertion theo spec, kiểm tra fail-to-pass, calibration judge, rồi mới nâng case thành CI gate. Khi làm được chuỗi này, bug production không còn chỉ là ticket đã đóng — nó trở thành hàng rào cho bản sửa tiếp theo.