Agent ArenaClickHouse Workshops

04 Điều tra với con người

Ghi chú giảng viên cho quy trình điều tra ưu tiên bằng chứng và bàn giao nguồn gốc production.

Tài liệu dành cho giảng viên, đi cùng bài học 04 Điều tra với con người.

Thời lượng

Tổng cộng khoảng 20 phút.

  • 3 phút — lọc phản hồi tiêu cực và xác minh root trace Chat có thẩm quyền.
  • 4 phút — tạo ba score config, rồi tạo queue với tập config cố định.
  • 4 phút — ghi nhận hành vi quan sát được trước khi thảo luận chẩn đoán.
  • 5 phút — kiểm tra trace và chạy SQL policy-v1/policy-v2 cạnh nhau.
  • 4 phút — nhập bản sửa, phê duyệt, hoàn tất và ghi nguồn gốc.

Chuẩn bị của giảng viên

Trước khi học viên đến, xác nhận Mô-đun 03 đã tạo root chat_turn có thẩm quyền với Boolean user-thumbs=false và sql-execution-success=true. Giữ trace ID trong phạm vi project và xác nhận output gốc chứa câu hỏi, SQL được tạo, các hàng trả về và outcome.

Nếu cần diễn tập, hãy tạo ba score config trong một project thử dùng riêng, nhưng không tạo trước queue cuối cùng của học viên. Tập ID score config gắn vào queue được cố định khi tạo, vì vậy lớp cần tạo config trước rồi gắn đủ cả ba:

TênKiểuGiá trị
observed-issueTEXTbằng chứng dạng văn bản tự do
failure-categoryCATEGORICALstale-business-policy, incorrect-sql, ambiguous-request, not-actionable
approved-for-goldenBOOLEANtrue / false

Bài annotation này chỉ thực hiện trên UI. Các script runtime có thể xác minh điểm số trên trace và sau đó promote file export đã review, nhưng không tạo queue, không viết phán đoán của con người và không hoàn tất annotation task.

Nội dung dẫn dắt

  1. Trong Tracing, lọc theo user-thumbs = false và đối chiếu trace ID từ bài thực hành Mô-đun 03. Nói rõ: “Feedback quyết định điều chúng ta điều tra tiếp theo, không quyết định kết luận của chúng ta.”

  2. Dùng Settings → Scores → Create cho từng score config. Sau đó vào Annotations → Queues → Create, đặt tên queue production-investigation-<session> với hậu tố session duy nhất và gắn đủ ba config.

  3. Chọn root observation chat_turn, mở menu Annotate và chọn queue mới. Cho lớp xem observation con llm_call nhưng giải thích vì sao đây là target sai: nó thiếu output thực thi đầu-cuối có cấu trúc và không phải sự cố feedback ở cấp logic.

  4. Nhắc học viên rằng Mô-đun 03 đã công khai tình huống được seed, rồi yêu cầu họ tạm gác kiến thức đó và thực hành ghi nhận mở dựa trên quan sát. Một ghi chú ban đầu phù hợp là:

    The SQL executed and returned a count. The observed count differs from the second
    reference count. The query uses a 90-day customer signup window, and the trace
    metadata reports policy-v1.
  5. Chỉ sau khi cả lớp đã ghi chú này mới trình bày toàn bộ bằng chứng: metadata phát ra policyversion=policy-v1, SQL/kết quả dựa trên ngày đăng ký và hai điểm số. Trường nguồn là policy_version; adapter OpenTelemetry phát khóa Langfuse đã chuẩn hóa là policyversion.

  6. Chạy hai định nghĩa chính sách cạnh nhau. SQL tham chiếu policy-v1 là:

    SELECT count() FROM v_customers
    WHERE signup_date >= today() - INTERVAL 90 DAY

    SQL tham chiếu cho chính sách hiện tại policy-v2 là:

    SELECT uniqExact(customer_id) FROM v_orders
    WHERE order_ts >= now() - INTERVAL 30 DAY
    AND status NOT IN ('cancelled', 'returned')
  7. Chỉ sau phép so sánh mới đưa ra chẩn đoán: ghi failure-category=stale-business-policy, chuyển Corrected output sang plain-text mode và dán truy vấn hiện tại ở dạng thô. Langfuse không thực thi SQL, nên hãy xác minh chính xác nội dung này qua client chỉ đọc ở Bước 6 trước khi đặt approved-for-golden=true và hoàn tất task.

  8. Giữ lại source_trace_id, failure_category, source_policy_version, bản sửa và annotation task ID tùy chọn cho Mô-đun 05.

Ba chẩn đoán nghe hợp lý nhưng sai

  • “Mô hình bỏ qua prompt.” SQL trong trace tuân theo đúng ngữ cảnh policy-v1 được nêu rõ. Lỗi nằm ở chính sách triển khai đã lỗi thời, không phải việc mô hình không tuân thủ hướng dẫn được cung cấp.
  • “sql-execution-success bị lỗi.” SQL đã thực thi nên evaluator vận hành trả về true là chính xác. Thiết kế của evaluator này không kiểm tra ý nghĩa nghiệp vụ được quản trị.
  • “Một lượt 👎 chứng minh SQL sai.” Feedback chỉ xác định trace đáng review. Nó không làm rõ ý định người dùng hay cung cấp truy vấn thay thế đã xác minh; phép so sánh chính sách cạnh nhau và đánh giá của con người mới làm được điều đó.

Giữ ba giả thuyết này trên màn hình cho đến khi học viên hoàn tất ghi nhận mở. Giảng viên đã biết câu trả lời của tình huống seed, nhưng cuộc điều tra vẫn phải mô phỏng một quy trình review thực tế, ưu tiên bằng chứng.

Nhắm đúng root observation

Trace có hai observation liên quan:

ObservationNội dungDùng cho annotation?
root chat_turncâu hỏi cùng SQL/kết quả/output có cấu trúcCó
con llm_calltranscript của model, SQL được tạo, token usageKhông

Nếu học viên thêm nhầm observation con, không hoàn tất nó như kết quả điều tra. Hãy thêm root chat_turn vào đúng queue và giữ lại/xóa task nhầm theo chính sách lưu giữ của project. Dùng trace ID, không dùng observation ID con, làm source_trace_id.

Tập config cố định của queue và cách đặt tên lại an toàn

Langfuse cố định tập ID score config gắn vào queue khi queue được tạo. Không thể gắn bổ sung một config bị bỏ sót sau đó, vì vậy cách an toàn nhất là tạo đủ config trước. Bản thân score config có thể thay đổi: các chỉnh sửa được hỗ trợ về tên, schema hoặc giá trị category phải dùng thao tác update score config đã kiểm thử; thao tác này không ghi lại các điểm số hiện có.

Dùng hậu tố an toàn khi làm lại, chẳng hạn:

production-investigation-<session>-retry-1

Nếu queue thiếu config hoặc gắn sai config ID, hãy tạo queue mới có hậu tố và đủ ba ID chính xác, thêm lại root có thẩm quyền, rồi đánh dấu rõ queue cũ đã bị thay thế; chỉ xóa nếu chính sách project cho phép. Với chỉnh sửa được hỗ trợ trên config đã gắn, hãy dùng thao tác update score config đã kiểm thử thay vì tạo lại queue. Không tái sử dụng tên của một queue đã hoàn tất theo cách làm mờ task nào đã tạo ra quyết định.

Độ tin cậy của corrected output

Bản sửa sẽ trở thành ground truth vàng trong tương lai, nên cả cú pháp lẫn chính sách đều quan trọng. Chuyển Corrected output sang plain-text mode trước khi dán SQL thô. Langfuse lưu văn bản nhưng không thực thi; trước khi phê duyệt, hãy chạy chính xác nội dung đó qua ClickHouse client chỉ đọc ở Bước 6. Một truy vấn trông có vẻ đúng nhưng sai định dạng, tham chiếu bảng thô, chứa nhiều statement hoặc không chạy được trên ClickHouse vẫn chưa đủ điều kiện phê duyệt.

Với SQL không hợp lệ:

  1. đặt hoặc giữ approved-for-golden=false;
  2. không hoàn tất task ở trạng thái đã phê duyệt;
  3. sửa truy vấn để chỉ dùng các view v_* được phép;
  4. chạy lại và kiểm tra kết quả; và
  5. chỉ phê duyệt, hoàn tất sau khi xác minh.

Nếu ai đó đã hoàn tất một bản sửa không hợp lệ, hãy tạo queue/task mới có hậu tố và review lại, không âm thầm sửa audit trail. Lệnh promotion ở Mô-đun 05 cũng kiểm tra SQL chỉ đọc và thực thi truy vấn, nhưng guardrail đó không thay thế phán đoán của con người.

Các lỗi thường gặp

  • Không có trace sau khi lọc — xác nhận score có kiểu Boolean và bộ lọc là user-thumbs=false; không tìm theo tên score cũ. Đối chiếu trace ID trong bảng ghi nhận, đừng chọn trace chẩn đoán curl không chấm điểm.
  • Sai target — task chỉ hiển thị transcript/SQL vì đã thêm llm_call. Quay lại trace và thêm root chat_turn.
  • Queue thiếu dimension — queue được tạo mà không gắn đủ config ID bắt buộc. Tạo queue mới có hậu tố, không tiếp tục với form review thiếu. Với chỉnh sửa được hỗ trợ trên config đã gắn, hãy update config đã kiểm thử thay vì tạo lại queue.
  • Không thấy metadata chính sách — tìm khóa phát ra policyversion, không phải khóa nguồn policy_version, rồi xác nhận tag policy-v1 của root.
  • Hai số đếm bất ngờ bằng nhau — dừng chẩn đoán. Chạy lại preflight Mô-đun 03 và không tạo bằng chứng từ một snapshot dữ liệu không còn tình huống đối chứng.
  • Corrected output có định dạng thay vì SQL thô — chuyển Corrected output sang plain-text mode và chỉ dán truy vấn.
  • Bản sửa không thực thi được — Langfuse không phát hiện điều này. Giữ trạng thái chưa phê duyệt, sửa và chạy lại chính xác nội dung qua client ở Bước 6 trước khi hoàn tất task.

Hoàn tất và bàn giao

Trước khi chuyển sang Mô-đun 05, xác minh task hoàn tất nhắm tới chat_turn có thẩm quyền, quan sát được ghi trước chẩn đoán, bản sửa là SQL chính xác theo chính sách hiện tại và task đã được phê duyệt. Bảng ghi nhận của học viên phải có:

source=production-feedback
source_trace_id=<authoritative Chat trace ID>
failure_category=stale-business-policy
source_policy_version=policy-v1
annotation_id=<task ID when available>

Điểm số tiêu cực của người dùng vẫn nằm trên trace production như một tín hiệu phân loại. Annotation của con người cung cấp ground truth đã review. Mô-đun 05 sẽ bảo toàn cả hai nguồn gốc khi promote bản sửa và xây dựng evaluator phòng ngừa.

Trên trang này

VI