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-v2cạ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ên | Kiểu | Giá trị |
|---|---|---|
observed-issue | TEXT | bằng chứng dạng văn bản tự do |
failure-category | CATEGORICAL | stale-business-policy, incorrect-sql, ambiguous-request, not-actionable |
approved-for-golden | BOOLEAN | true / 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
-
Trong Tracing, lọc theo
user-thumbs = falsevà đố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.” -
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. -
Chọn root observation
chat_turn, mở menu Annotate và chọn queue mới. Cho lớp xem observation conllm_callnhư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. -
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. -
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. -
Chạy hai định nghĩa chính sách cạnh nhau. SQL tham chiếu
policy-v1là:SELECT count() FROM v_customers WHERE signup_date >= today() - INTERVAL 90 DAYSQL tham chiếu cho chính sách hiện tại
policy-v2là:SELECT uniqExact(customer_id) FROM v_orders WHERE order_ts >= now() - INTERVAL 30 DAY AND status NOT IN ('cancelled', 'returned') -
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 đặtapproved-for-golden=truevà hoàn tất task. -
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-successbị lỗi.” SQL đã thực thi nên evaluator vận hành trả vềtruelà 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:
| Observation | Nội dung | Dùng cho annotation? |
|---|---|---|
root chat_turn | câu hỏi cùng SQL/kết quả/output có cấu trúc | Có |
con llm_call | transcript của model, SQL được tạo, token usage | Khô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-1Nế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ệ:
- đặt hoặc giữ
approved-for-golden=false; - không hoàn tất task ở trạng thái đã phê duyệt;
- sửa truy vấn để chỉ dùng các view
v_*được phép; - chạy lại và kiểm tra kết quả; và
- 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áncurlkhô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 rootchat_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ồnpolicy_version, rồi xác nhận tagpolicy-v1củ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.