Langfuse AI Eval Thực Chiến: Trace, Golden Dataset, Evaluator Và Regression Gate

Một chatbot có thể trả lời đúng mười câu hỏi mẫu nhưng vẫn thất bại ngay khi gặp người dùng thật. Một AI agent có thể hoàn thành demo trơn tru nhưng lại chọn sai tool, dùng tài liệu cũ hoặc tạo ra một câu trả lời nghe rất thuyết phục mà không bám dữ liệu. Vấn đề không nằm ở việc đội ngũ chưa viết đủ prompt. Vấn đề là chưa có một vòng đánh giá nối được hành vi production với bộ kiểm thử trước khi phát hành.

Langfuse cung cấp các mảnh ghép cho vòng lặp đó: tracing để thấy từng bước, score để biểu diễn chất lượng, annotation queue để con người xem đúng trường hợp cần xem, dataset để lưu lại lỗi có giá trị, experiment để so sánh phiên bản và dashboard để theo dõi drift. Điều quan trọng là không triển khai từng tính năng như những màn hình rời rạc. Một hệ thống AI Eval hữu ích phải trả lời được ba câu hỏi: lỗi nào đang xảy ra ngoài production, lỗi đó được biến thành test case ra sao và thay đổi mới có thực sự sửa lỗi mà không làm giảm chất lượng ở nơi khác hay không.

Bài viết này xây một workflow thực chiến cho chatbot, RAG và AI agent. Mục tiêu không phải tạo một “điểm chất lượng” duy nhất, mà là hình thành chuỗi bằng chứng đủ rõ để developer, AI Creator, solopreneur và team sản phẩm quyết định khi nào nên phát hành, khi nào cần điều tra và khi nào phải đưa con người vào vòng kiểm soát.

Langfuse v4 và bối cảnh phiên bản hiện hành

Langfuse là một repository công khai do tổ chức Langfuse duy trì, ngôn ngữ chính TypeScript và vẫn được phát triển tích cực. Phần lõi nằm ngoài các thư mục enterprise được cấp phép MIT; các thư mục ee có điều khoản riêng. Vì vậy, “open source” không đồng nghĩa mọi tính năng Cloud hoặc Enterprise đều thuộc cùng phạm vi giấy phép. Khi tự host cho sản phẩm thương mại, cần kiểm tra chính xác tính năng đang dùng nằm trong phần core hay enterprise thay vì suy luận từ giao diện demo.

Tại thời điểm bài được chuẩn bị, repository có hơn 32.000 star, không bị archived và vẫn nhận commit mới. Star là tín hiệu về mức độ quan tâm của cộng đồng, không phải chứng nhận production-ready. Release ổn định gần nhất trên GitHub là v3.224.2, trong khi nhiều tài liệu và ảnh giao diện mới trình bày hướng phát triển v4. Điều này có hai hệ quả. Thứ nhất, hãy pin image, SDK và schema đang dùng. Thứ hai, đừng viết automation dựa trên một màn hình hoặc endpoint mới mà không kiểm tra phiên bản triển khai của chính bạn.

V4 chuyển trọng tâm dữ liệu sang observation-centric model và tối ưu các truy vấn phân tích. Với hệ thống Eval, đây là thay đổi đáng chú ý vì score, latency, cost, model, environment và metadata cần được lọc trên lượng observation lớn. Tuy nhiên, cải thiện hiệu năng do maintainer công bố là kết quả trong bối cảnh thử nghiệm của họ; nó không bảo đảm instance của bạn đạt cùng mức nếu cấu hình ClickHouse, retention, index, storage hoặc workload khác.

Mô hình dữ liệu observation-centric thay đổi cách đọc một lần chạy

Trong một ứng dụng LLM đơn giản, người ta thường coi một request là một trace và một lần gọi model là phần quan trọng nhất. Với agent, trace có thể chứa nhiều observation: retrieval, generation, tool call, embedding, guardrail, handoff và các bước logic. Nếu chỉ chấm output cuối, đội ngũ biết câu trả lời sai nhưng không biết nguyên nhân là dữ liệu đầu vào, retrieval, quyết định tool hay model.

Observation-centric model giúp xem mỗi bước như một đơn vị có thể lọc và đánh giá. Một evaluator có thể chỉ chạy trên generation cuối, một evaluator khác kiểm tra riêng tool call, trong khi dashboard latency tập trung vào retrieval. Cách phân tách này quan trọng vì cùng một score không nên áp lên mọi loại observation. “Groundedness” phù hợp với câu trả lời dựa trên tài liệu; “tool argument valid” phù hợp với hành động; “retrieval relevance” phù hợp với danh sách tài liệu được lấy về.

Thiết kế tốt bắt đầu bằng naming convention. Thay vì để mọi bước mang tên llm_call, hãy đặt tên theo nhiệm vụ như retrieve_docs, route_request, draft_answer hoặc call_refund_api. Thêm environment, release, model và phiên bản prompt để khi score giảm, bạn có thể xác định thay đổi nào liên quan.

Trace trước khi chấm điểm

Không có trace đầy đủ, evaluation dễ biến thành việc chấm một chuỗi văn bản đã mất ngữ cảnh. Với chatbot, mặc định hợp lý là một trace cho mỗi tin nhắn người dùng và một session cho toàn bộ cuộc hội thoại. Trace giữ việc điều tra từng lượt gọn gàng; session cho phép xem các lượt trước đã ảnh hưởng thế nào tới câu trả lời hiện tại.

Một trace hữu ích nên chứa input, output, model, latency, token hoặc usage nếu provider trả về, các tài liệu retrieval, tool name, tool arguments đã được làm sạch và kết quả cần thiết để debug. Nó cũng cần liên kết với user hoặc account bằng định danh đã pseudonymize khi có yêu cầu riêng tư. Không ghi authorization header, cookie, API key, token phục hồi hoặc toàn bộ tài liệu nội bộ chỉ vì “có thể sẽ cần”.

Khi câu trả lời sai, hãy lần theo trace theo thứ tự:

1. Intent có được phân loại đúng không?
2. Retrieval có lấy đúng nguồn và đúng phiên bản không?
3. Model có thực sự sử dụng nguồn hay dựa vào kiến thức sẵn có?
4. Tool được chọn có đúng nhiệm vụ và đúng quyền không?
5. Output có vượt schema hoặc vi phạm policy không?
6. Lỗi xuất hiện ở một model, một release hay toàn bộ hệ thống?

Hai lỗi có output giống nhau có thể cần cách sửa hoàn toàn khác. Nếu retrieval lấy nhầm tài liệu, thay prompt generation không giải quyết gốc rễ. Nếu retrieval đúng nhưng model bỏ qua evidence, cần sửa prompt, context formatting hoặc evaluator groundedness. Trace là nơi tách hai trường hợp đó.

Đừng review mọi trace: hãy tìm tín hiệu có giá trị

Review thủ công toàn bộ production không mở rộng được. Thay vì cố xem tất cả, hãy thiết kế một lớp monitoring nhẹ để tìm những tương tác đáng điều tra. Với chatbot, các tín hiệu thường hữu ích gồm người dùng phản đối câu trả lời, hỏi lại cùng vấn đề, thể hiện thất vọng, yêu cầu ngoài phạm vi hoặc câu trả lời có latency và cost bất thường.

Một phần tín hiệu có thể kiểm tra bằng code. JSON không hợp lệ, thiếu field bắt buộc, tool name ngoài allowlist, latency vượt ngưỡng hoặc output chứa một mẫu bị cấm không cần LLM-as-a-Judge. Code evaluator nhanh, rẻ, dễ tái hiện và nên được ưu tiên khi tiêu chí mang tính xác định.

LLM-as-a-Judge phù hợp hơn với relevance, helpfulness, groundedness, tone hoặc phân loại intent. Nhưng judge cũng là model: có bias, có drift và có thể bị ảnh hưởng bởi prompt. Hãy lưu phiên bản judge prompt, model, temperature, rubric và dữ liệu đầu vào. Trước khi tin score, so sánh judge với một tập nhãn do con người tạo và xem các trường hợp bất đồng.

Một cách triển khai thực tế là dùng nhiều lớp:

• Rule-based detector bắt lỗi chắc chắn và rẻ.
• Judge nhẹ chạy trên mẫu production hoặc nhóm trace có rủi ro.
• Annotation queue nhận trace bị gắn cờ cùng một mẫu ngẫu nhiên.
• Reviewer xác nhận lỗi và mô tả nguyên nhân bằng ghi chú ngắn.

Cách này biến câu hỏi “chất lượng hôm nay thế nào?” thành danh sách trường hợp có thể hành động, thay vì một điểm trung bình che mất các lỗi hiếm nhưng nghiêm trọng.

Xây golden dataset từ lỗi production

Golden dataset không phải tập câu hỏi được viết một lần trước ngày ra mắt rồi giữ nguyên. Bộ dữ liệu tốt phải phản ánh phân bố câu hỏi thật, failure mode thật và những tình huống mà sản phẩm không được phép thất bại. Nguồn tốt nhất thường là trace production đã được review và làm sạch dữ liệu nhạy cảm.

Mỗi dataset item nên có input, expected output khi phù hợp và metadata. Metadata có thể ghi nguồn của item, ngôn ngữ, intent, độ khó, failure mode, loại khách hàng, phiên bản tài liệu hoặc policy liên quan. Nhờ vậy, experiment không chỉ trả một điểm tổng mà còn cho phép biết phiên bản mới tốt hơn ở câu hỏi triển khai nhưng kém hơn ở self-hosting, hay tốt ở tiếng Anh nhưng giảm ở tiếng Việt.

Một dataset cân bằng thường kết hợp ba nhóm:

1. Mẫu production ngẫu nhiên: giữ sự đại diện cho traffic thật.
2. Lỗi đã xác nhận: bảo đảm regression cũ không quay lại.
3. Edge case có chủ đích: kiểm tra policy, tool, dữ liệu cũ, prompt injection hoặc tình huống hiếm nhưng rủi ro cao.

Không nên chỉ đưa các câu khó vào dataset. Khi đó score tổng thể phản ánh “bộ sưu tập lỗi” chứ không phản ánh sản phẩm. Ngược lại, chỉ lấy mẫu ngẫu nhiên có thể bỏ sót các lỗi quan trọng vì chúng xuất hiện ít. Metadata và tập con giúp giữ cả hai mục tiêu.

Thiết kế expected output để chấm đúng hành vi

Expected output không nhất thiết là một đoạn văn duy nhất mà model phải sao chép. Với chatbot, có thể lưu một object gồm câu trả lời mẫu, keyword bắt buộc, nguồn cần viện dẫn và behavior mong đợi. Behavior có thể là trả lời trực tiếp, hỏi thêm thông tin, từ chối vì ngoài phạm vi, gọi đúng tool hoặc chuyển cho con người.

Cấu trúc này cho phép dùng evaluator phù hợp với từng phần:

• Schema validator kiểm tra output có đúng JSON hay không.
• Keyword evaluator xác nhận tên sản phẩm hoặc thuật ngữ quan trọng xuất hiện.
• Tool evaluator kiểm tra agent có chọn đúng tool và arguments hay không.
• LLM judge so sánh correctness hoặc behavior với expected output.
• Human review xử lý trường hợp có nhiều câu trả lời hợp lệ.

Đừng viết expected output quá chi tiết nếu kiến thức thay đổi thường xuyên. Một câu trả lời mẫu chứa version hoặc giá có thể trở thành nguồn sai mới. Với dữ liệu hay đổi, hãy lưu tiêu chí và nguồn cần grounded thay vì đóng băng toàn bộ câu trả lời. Dataset cũng cần owner và ngày review; không có người chịu trách nhiệm, golden set sẽ dần biến thành legacy set.

Dataset riêng cho grounding và kiến thức thay đổi

RAG và chatbot tài liệu có một failure mode đặc biệt: model trả lời theo kiến thức huấn luyện cũ thay vì tài liệu vừa retrieval. Câu trả lời có thể trôi chảy, đúng với phiên bản trước nhưng sai với sản phẩm hiện hành. Expected answer cố định không phải lúc nào cũng phù hợp vì tài liệu tiếp tục thay đổi.

Trong trường hợp này, có thể tạo dataset reference-free: lưu câu hỏi và metadata, sau đó đánh giá xem output có bám vào tài liệu được lấy về hay không. Evaluator cần nhìn cả answer và evidence. Nếu answer nêu claim không có trong evidence, score groundedness phải giảm dù claim đó nghe hợp lý.

Với agent, dataset domain-specific có thể tập trung vào hành vi khác:

• Agent support phải chuyển người dùng cho nhân viên khi gặp khiếu nại tài chính.
• Agent browser không được gửi form khi chưa có approval.
• Coding agent phải chạy test liên quan sau khi sửa schema.
• Email agent không được gửi thư nếu người nhận chưa được xác minh.
• RAG agent phải dùng tài liệu đúng tenant và đúng quyền.

Không có evaluator “phổ quát” tự hiểu mọi failure mode của doanh nghiệp. Workflow đúng là tìm lỗi qua trace, mô tả failure mode, xây dataset riêng và chỉ sau đó chọn phương pháp chấm.

Chạy evaluator mà không làm chi phí mất kiểm soát

Evaluator production không nên chạy đồng đều trên mọi trace. Một judge model đắt chạy sau mỗi message có thể tạo chi phí gần bằng hoặc cao hơn chính ứng dụng. Hãy dùng routing: rule-based prefilter, sampling theo traffic, tăng tỷ lệ ở release mới và chạy judge đầy đủ cho trace bị gắn cờ.

Danh sách evaluator cần được quản lý như code. Mỗi evaluator nên có tên, mục tiêu, owner, input scope, model hoặc implementation, version, ngưỡng, cách xử lý lỗi và ngày review. Nếu evaluator đổi prompt nhưng giữ nguyên tên, dashboard sẽ trộn score trước và sau thay đổi, khiến trend mất ý nghĩa.

Với score số, cần biết thang điểm và phân bố chứ không chỉ average. Điểm trung bình 0,85 có thể che một nhóm intent chỉ đạt 0,4. Với score boolean, theo dõi tỷ lệ pass/fail theo release, environment và model. Với categorical score, xem tỷ trọng intent hoặc failure mode thay đổi ra sao.

Judge failure cũng cần được quan sát. Timeout, output sai schema, rate limit hoặc model từ chối không nên bị biến thành score 0 một cách im lặng. Hãy tách trạng thái evaluator error khỏi product failure để không gửi cảnh báo sai.

Theo dõi score, drift và chi phí trên dashboard

Dashboard hữu ích phải phục vụ quyết định cụ thể. Một màn hình đầy widget nhưng không gắn với hành động chỉ tạo cảm giác có observability. Với chatbot hoặc agent, bộ chỉ số khởi đầu có thể gồm relevance, groundedness, tool success, user disagreement, latency, cost, evaluator error và traffic theo intent.

Mỗi widget nên có breakdown theo ít nhất một dimension có khả năng giải thích thay đổi: model, release, environment, prompt version, language hoặc intent. Khi relevance giảm, breakdown giúp biết toàn bộ hệ thống giảm hay chỉ một model. Khi cost tăng, có thể xác định do traffic, token mỗi trace, vòng lặp agent hay judge model.

Cảnh báo nên dựa trên ngưỡng có ý nghĩa và cần cửa sổ thời gian phù hợp. Một trace lỗi không nhất thiết là incident. Nhưng tỷ lệ groundedness giảm liên tục sau release, tool failure tăng ở production hoặc evaluator cost tăng đột biến đều đáng điều tra. Với lưu lượng thấp, dùng số lượng tối thiểu để tránh alert từ mẫu quá nhỏ.

Langfuse cho phép kết nối score, dashboard, monitor và dataset trong cùng một hệ thống. Tuy vậy, hãy giữ một kênh giám sát bên ngoài cho chính Langfuse nếu tự host. Worker backlog, ClickHouse query chậm hoặc blob storage lỗi có thể làm telemetry thiếu; dashboard bên trong không nên là nguồn cảnh báo duy nhất khi chính nền tảng đang gặp sự cố.

Biến dataset thành regression gate trong CI

Một dataset chỉ có giá trị khi được chạy lại lúc hệ thống thay đổi. Trigger phổ biến gồm đổi model, sửa prompt, cập nhật retrieval, thay tool schema, nâng SDK hoặc thay tài liệu quan trọng. Experiment cần lưu version của code, prompt, model và dataset để kết quả có thể tái hiện.

Không nên chặn release bằng một điểm tổng duy nhất. Hãy chia gate:

• Hard gate cho schema, policy, tool argument và lỗi nghiêm trọng.
• Regression gate theo dimension, chẳng hạn groundedness không được giảm quá ngưỡng đã định.
• Budget gate cho latency và chi phí.
• Review gate khi kết quả nằm trong vùng không chắc chắn.

Baseline phải là phiên bản production hoặc bản candidate đã được chấp nhận, không phải một con số tùy ý. Khi dataset nhỏ, báo confidence và số mẫu; đừng tuyên bố cải thiện từ chênh lệch vài phần trăm nếu chỉ có một số ít item.

CI cũng không thay thế canary. Offline dataset không tái hiện hoàn toàn traffic, tool availability và dữ liệu production. Sau khi qua regression gate, phát hành cho một phần nhỏ traffic, theo dõi trace và score, rồi mới mở rộng.

Self-hosting, dữ liệu riêng tư và phạm vi license

Eval data có thể nhạy cảm hơn log thông thường vì nó tập trung prompt, output, feedback, nhãn lỗi và expected answer. Nếu self-host Langfuse, hãy xác định retention cho trace, score, dataset và attachment; tách project production/staging; giới hạn API key; cấu hình network và backup; đồng thời mask secret trước khi dữ liệu rời ứng dụng.

Bài Langfuse self-hosted, bảo mật và debug AI agent trên NextGZ đi sâu vào ClickHouse, PostgreSQL, Redis, blob storage, masking, RBAC và migration. Với workflow Eval, nguyên tắc quan trọng là không đưa dữ liệu người dùng vào golden set trước khi đã loại PII và xác định quyền lưu giữ.

Phần core của repository dùng MIT ngoại trừ các thư mục enterprise. Khi chọn self-hosting, cần đối chiếu edition cho evaluator, monitor, alert, SSO hoặc tính năng quản trị mà team dự định dùng. Không suy luận availability từ ảnh tài liệu hoặc project demo.

Phân vai cho developer, reviewer và AI agent

AI agent có thể hỗ trợ triage trace, đề xuất failure mode, tạo bản nháp dataset item hoặc chạy experiment. Nhưng agent không nên tự quyết định expected output cho policy quan trọng, tự thay evaluator production hoặc tự nới ngưỡng để release vượt gate.

Vai trò	Trách nhiệm chính	Không nên tự làm
Developer	Instrumentation, schema, experiment runner và CI	Tự định nghĩa chất lượng nghiệp vụ mà không có reviewer
Product/Domain reviewer	Expected behavior, nhãn lỗi và acceptance criteria	Thay đổi code evaluator trực tiếp trên production
Security/Operations	Data boundary, retention, key, network và incident	Dùng score sản phẩm thay cho security control
AI agent	Tóm tắt trace, nhóm lỗi, chuẩn bị candidate và chạy tác vụ lặp	Phê duyệt release hoặc thay policy của chính nó

Nếu dùng coding agent để tạo evaluator hoặc sửa CI, hãy áp guardrail trước tool, test thay đổi và yêu cầu review. Bài Cline Hooks thực chiến trình bày cách chặn tool, chạy validation và ghi log gần vòng đời agent.

Các lỗi triển khai AI Eval thường gặp

Score tăng nhưng người dùng vẫn phàn nàn

Rubric có thể không đo điều người dùng quan tâm, dataset không đại diện traffic hoặc judge đang ưu tiên văn phong hơn độ chính xác. Hãy lấy trace có phản hồi xấu, so với score và cập nhật failure taxonomy trước khi chỉnh ngưỡng.

Dataset ngày càng lớn nhưng không hữu ích hơn

Nhiều item trùng ý định hoặc expected output đã cũ. Thêm dedupe, owner, metadata và lịch review. Tách bộ regression cốt lõi khỏi kho trace dùng cho nghiên cứu.

Evaluator trả kết quả không ổn định

Pin model và prompt, giảm độ mở của rubric, yêu cầu output có schema, chạy lặp trên một tập nhỏ và đo agreement. Với tiêu chí xác định, thay judge bằng code evaluator.

Chi phí judge tăng nhanh

Dùng sampling, prefilter, model nhỏ hơn cho phân loại đơn giản và chỉ chạy judge mạnh ở vùng không chắc chắn. Theo dõi riêng token và latency của evaluator.

CI mất quá nhiều thời gian

Chia dataset theo risk. Pull request chạy smoke set và hard gate; nightly chạy bộ rộng; thay model hoặc retrieval chạy full regression. Cache phần retrieval khi hợp lý nhưng không cache đến mức che thay đổi cần đo.

Trace chứa dữ liệu không nên lưu

Dừng ingestion nếu cần, xoay credential bị lộ, xác định phạm vi ảnh hưởng và sửa masking ở client. Xóa dữ liệu sau khi đã chảy vào hệ thống không thay thế phòng ngừa trước khi gửi.

Checklist triển khai trong 14 ngày

1. Chọn một workflow có traffic và failure mode rõ.
2. Định nghĩa trace, observation name, session và release metadata.
3. Mask secret và PII trước khi gửi telemetry.
4. Tạo hai code evaluator cho schema và policy xác định.
5. Tạo một judge rubric cho tiêu chí ngữ nghĩa quan trọng nhất.
6. Gắn score vào trace và kiểm tra evaluator error.
7. Tạo annotation queue gồm trace bị gắn cờ và mẫu ngẫu nhiên.
8. Review thủ công, ghi pass/fail cùng failure note.
9. Chuyển lỗi đã xác nhận thành dataset item.
10. Thêm expected output và metadata theo intent, nguồn và ngôn ngữ.
11. Chạy experiment trên bản production và candidate.
12. Thiết lập hard gate, regression gate và budget gate.
13. Đưa smoke dataset vào pull request; chạy full set theo lịch.
14. Tạo dashboard theo score, model, release, intent và cost.
15. Canary bản vượt gate, tiếp tục lấy trace production về dataset.

Kết luận

AI Eval không bắt đầu từ việc chọn một judge model. Nó bắt đầu từ khả năng nhìn thấy đúng hành vi, chọn đúng trace để review và mô tả lỗi bằng ngôn ngữ có thể biến thành test. Langfuse giúp nối tracing, score, annotation, dataset, experiment và dashboard thành một vòng lặp thống nhất, nhưng chất lượng của hệ thống vẫn phụ thuộc vào acceptance criteria và dữ liệu mà đội ngũ đưa vào.

Hãy khởi đầu nhỏ: một workflow, vài evaluator có ý nghĩa và một golden dataset được tạo từ lỗi thật. Dùng code cho điều có thể kiểm tra xác định, dùng judge cho ngữ nghĩa, dùng con người cho tiêu chí quan trọng và giữ CI làm cổng lặp lại. Khi mỗi sự cố production tạo ra một test mới và mỗi release phải đi qua bằng chứng đó, evaluation mới chuyển từ một dashboard đẹp thành cơ chế kiểm soát chất lượng thực sự cho AI agent.