Tháng trước, tôi đã ship một thay đổi pipeline mà tôi thực sự tự hào. Viết lại prompt. Một bước review với context đầy đủ. Một rubric chi tiết để phát hiện lặp lại và đảm bảo sự đa dạng cấu trúc giữa các segment.
Tôi đã deploy. Quan sát suốt sáu tuần. Tự nhủ là nó đang hoạt động.
Rồi tôi xây dựng một framework đánh giá. Chạy nó trên 40 tập production thực tế bằng 7 ngôn ngữ. Và phát hiện ra rằng bước review — cái bước mà tôi đã thiết kế cẩn thận đến vậy — đang làm scripts tệ đi một cách có thể đo lường được.
Không phải trung tính. Tệ hơn.
Điểm dialogue mỗi segment là 3.34 trên 5. Outline được 3.01. Còn script cuối cùng, sau khi qua review? 2.91.
Bước được thiết kế để cải thiện scripts đang làm giảm chất lượng hơn 12%.
Sự chuyển dịch này — từ "tôi nghĩ nó đang hoạt động" sang "tôi biết là nó không" — bắt đầu cách đây vài tuần. Tôi đang xem khóa Agentic AI của Andrew Ng trên DeepLearning.AI, nơi anh ấy nhấn mạnh một điều nghe thì hiển nhiên nhưng thực ra không: đánh giá và traces là nền tảng của mọi hệ thống agentic. Không có chúng, bạn đang debug trong bóng tối. Có chúng, bạn biết chính xác mắt xích nào trong chuỗi đã gãy.
Tôi đã chạy các bài kiểm tra chất lượng script ad-hoc suốt nhiều tháng — các metric cấu trúc như tỷ lệ độ dài lượt nói và cân bằng người nói, cộng với một LLM judge so sánh các biến thể prompt A/B. Chúng phát hiện được những regression rõ ràng. Nhưng không toàn diện. Chúng chỉ bao phủ một stage (dialogue), mỗi lần một ngôn ngữ, và được thiết kế cho A/B testing prompt, không phải cho kiểm toán chất lượng toàn pipeline.
Điểm của Andrew về traces thực sự đánh trúng. Pipeline của tôi có năm lần gọi LLM chính cho mỗi tập — research, outline, dialogue từng segment, intro/outro, và review — cộng với một lần TTS từ ElevenLabs. Tôi có quality metrics cho một trong số đó. Bốn cái còn lại được tin tưởng chỉ dựa trên cảm giác.
Vậy nên tôi đã xây dựng một hệ thống đánh giá thực sự. Hoàn chỉnh. Đa chiều. Có thể chạy lại. Đây là những gì nó tìm thấy, sáu bản sửa tôi đã ship trong một ngày, và những gì thực sự cải thiện.
Baseline: Ba Con Số Thay Đổi Mọi Thứ
Tôi đã đánh giá 40 tập đã hoàn thành từ cơ sở dữ liệu production của mình — bao phủ tất cả 7 ngôn ngữ (en, vi, ja, ko, es, zh, fr) và 10 phong cách podcast — dựa trên ba rubric với năm chiều mỗi cái. Một LLM judge (GPT-5.6-terra) chấm điểm từng stage.
| Stage | Score | Worst Dimension |
|---|---|---|
| Dialogue (per-segment) | 3.34 | Factual Grounding: 2.17 |
| Outline (research + structure) | 3.01 | Citation Credibility: 1.28 |
| Final Script (post-review) | 2.91 | Publishability: 1.95 |
Ba điều nổi bật ngay lập tức:
1. Lượt review đang làm giảm chất lượng scripts 0.43 điểm. Dialogue được 3.34. Sau review? 2.91. Bước được thiết kế để cải thiện chất lượng đang lấy đi chất lượng.
2. Tất cả citation URLs đều là redirect không trong suốt. Mỗi "source URL" trong mỗi outline đều trỏ đến vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQ.... Chúng hoạt động với người click vào, nhưng trông hoàn toàn bịa đặt với reviewer tự động. 344 facts có source URLs. Số không có resolved_url — một trường thậm chí còn chưa tồn tại.
3. Publishability là chiều thấp nhất trên toàn pipeline (1.95). Những podcaster thực thụ, theo judge đánh giá, sẽ không publish những script này dưới tên của họ. Các pattern AI có thể phát hiện: câu mở segment giống hệt nhau, chuyển tiếp chung chung, thiếu cá tính người dẫn.
Bài đánh giá cho tôi một danh sách xếp hạng chính xác những gì cần sửa. Tôi dành phần còn lại của ngày để sửa nó.
Sáu Bản Sửa (Và Tác Động Đo Lường Được)
Sửa 1: Citation URLs — 0% đến 100% Giải Quyết
Trước: 0 trong số 344 research facts có resolved_url. Mỗi URL trông như bịa đặt.
Sửa: Một URL resolver 60 dòng chạy trong quá trình tạo outline, theo dấu redirect của Vertex AI đến nguồn thực tế, và lưu cả hai URL (bản gốc để tuân thủ ToS của Google, bản đã giải quyết cho mọi thứ khác).
def resolve_grounding_url(url: str) -> str:
if "grounding-api-redirect" not in url:
return url
response = requests.head(url, allow_redirects=True, timeout=5)
return response.url if response.url != url else url
Sau: 23 trong số 23 research facts trong các tập mới hôm nay có resolved_url — các URL thực như simonwillison.net, axios.com, thinkingmachines.ai. 100% giải quyết.
Sửa 2: Đổi Model Review (Gemini → DeepSeek)
Trước: Gemini 3.5 Flash chạy review pass. Nó thực hiện các chỉnh sửa nhẹ, bảo thủ: đổi "Exactly!" thành "No question about it!" nhưng phần lớn giữ nguyên văn bản gốc. Nó thêm filler làm phẳng dialogue. Mật độ audio tag giảm. Tỷ lệ type-token giảm. Số lượt nói phình lên.
Sửa: Đổi review pass sang DeepSeek v4-pro (384K max output, giới hạn 96K). Làm cho provider có thể cấu hình:
provider = get_provider("review") # reads REVIEW_PROVIDER env var
response = provider.generate(
prompt=prompt, temperature=0.0,
max_output_tokens=96000,
)
Kiểm chứng: Đã deploy lên production. Một tập tin tức công nghệ tiếng Việt chạy qua full pipeline với DeepSeek review — 10.3K → 11.6K tokens, hoàn thành trong 121 giây, 0 lần tightening pass cần thiết. Tập thứ hai (tiếng Anh) xử lý 7.9K → 17K tokens trong 203 giây. DeepSeek API key được lưu trong Google Cloud Secret Manager, tự động inject khi deploy qua service.yaml.
Sửa 3: Outline Tự Phê Bình (+0.50 Cải Thiện)
Trước: Outline đi thẳng từ Gemini đến người dùng mà không có bất kỳ kiểm tra chất lượng nội bộ nào. Điểm trung bình: 3.01.
Sửa: Thêm một bước critique tự động. DeepSeek v4-pro đánh giá outline dựa trên rubric 6 chiều (5 chiều outline cộng với số lượng segment), trả về điểm + phản hồi cụ thể, và lưu critique vào metadata của podcast.
Sau đó tôi chạy một thí nghiệm có kiểm soát: lấy 6 tập có outline điểm dưới 3.0, chạy critique của DeepSeek, đưa phản hồi ngược lại cho Gemini như hướng dẫn tạo lại, và chấm lại điểm.
Sau: Cải thiện tổng thể +0.50 trên 6 tập.
| Dimension | Before | After | Delta |
|---|---|---|---|
| Content Boundaries | 3.33 | 4.17 | +0.83 |
| Research Depth | 2.67 | 3.17 | +0.50 |
| Citation Credibility | 1.00 | 1.50 | +0.50 |
| Structural Logic | 3.67 | 4.17 | +0.50 |
| Audience Fit | 2.17 | 2.33 | +0.17 |
Tập tệ nhất đã tăng từ 1.80 lên 3.20 (+1.40). Chỉ 1 trong 6 tập tệ hơn. Critique hiện được bật mặc định trong production — mỗi outline mới đều trải qua kiểm tra chất lượng này trước khi người dùng nhìn thấy.
Sửa 4: Outline Một Segment Giờ Sẽ Fail Cứng
Trước: Bài đánh giá cho thấy các tập có một segment duy nhất và không có research facts đạt điểm thấp tới 2.07. Đây là những trường hợp thất bại mà pipeline không coi là thất bại.
Sửa: Nếu outline generator tạo ra ít hơn 3 segment hợp lệ sau một lần thử khôi phục, podcast sẽ bị đánh dấu FAILED. Không còn outline một segment nào đến được tay người dùng. Ở lần tạo tiếp theo, credit của người dùng được giải phóng để thử lại.
Sửa 5: Quy Tắc Bản Địa Hóa Tiếng Trung
Trước: Các tập tiếng Trung đạt 2.88 — thấp nhất trong 7 ngôn ngữ. Hiện tượng dịch máy (thành ngữ tiếng Anh dịch sát nghĩa), câu mở segment giống hệt, tên người dẫn mặc định tiếng Anh (Alex/Maya) thay vì tên tiếng Trung (明辉/晓雯).
Sửa: Viết các quy tắc dialogue đặc thù cho tiếng Trung: các mẫu hội thoại tự nhiên (cấu trúc 不是...而是...), trợ từ cuối câu phù hợp (吧/啊/呢), hướng dẫn chống dịch sát (không bao giờ dịch "medical miracle" theo nghĩa đen), ẩn dụ bóng đá Trung Quốc cho các tập World Cup, và hồ sơ người dẫn theo locale với cá tính riêng biệt.
Template dialogue tiếng Trung chuyển từ việc dùng lại mặc định tiếng Anh sang có hướng dẫn 80 dòng riêng bao gồm các mẫu hội thoại, cách diễn đạt bất đồng, và cách định khung theo đối tượng cho từng phong cách podcast.
Sửa 6: Tên Người Dẫn Mặc Định Cho Ngôn Ngữ Không Phải Tiếng Anh
Trước: Nhiều tập không phải tiếng Anh có người dẫn tên Alex và Maya. Hồ sơ người dẫn theo locale đã tồn tại nhưng đường dẫn fallback trong outline generator bị hardcode về mặc định tiếng Anh.
Sửa: Truy vết bản sửa qua pipeline phân giải hồ sơ theo locale. Các tập production gần đây hiện dùng 翔太/健一 (ja), Mạnh/Nga (vi), Hugo/Camille (fr), 明辉/晓雯 (zh). Các commit tháng 7 đã sửa edge function và luồng tạo — fallback còn lại nằm trong chính outline generator.
Framework Đánh Giá (Có Thể Tái Sử Dụng)
Framework đã tìm ra tất cả những điều này dài khoảng ~500 dòng Python, ba file rubric (mỗi cái 5 chiều), một judge GPT-5.6-terra dùng chung, và một orchestrator:
docs/pipeline/evals/
├── run.py # Orchestrator: extract → judge → report
├── judge.py # Shared LLM judge (rate with rubric)
├── rubric_outline.py # Stage 1: 5 dimensions, 1-5 scale
├── rubric_dialogue.py # Stage 2: 5 dimensions, 1-5 scale
├── rubric_final_script.py # Stage 3: 5 dimensions, 1-5 scale
├── dataset_40.json # Extracted production data
├── scores.json # Machine-readable scores
└── report.md # Auto-generated report
Tôi cũng xây dựng một lớp thí nghiệm cho so sánh A/B:
docs/pipeline/evals/experiments/
├── review_ab.py # Compare two review models
├── outline_critique_ab.py # Critique → regenerate → compare
├── shared.py # Score comparator, report generator
└── results/ # Archived by date
Chạy python docs/pipeline/evals/run.py --full sau mỗi lần thay đổi pipeline và nhận báo cáo trong ~8 phút. Chạy experiments/review_ab.py --episodes 10 để so sánh model. Kết quả được lưu trữ theo ngày để theo dõi xu hướng — muốn biết chất lượng có cải thiện tháng này so với tháng trước không? Diff điểm số.
Bài đánh giá đầy đủ 40 tập tốn khoảng $1-2 tiền API calls. Các thí nghiệm còn rẻ hơn. Với tín hiệu bạn nhận lại — một danh sách xếp hạng chính xác những stage và chiều nào của pipeline cần chú ý — đây là công cụ debug rẻ nhất tôi từng xây dựng.
Những Gì Vẫn Còn Hỏng
Thí nghiệm A/B review DeepSeek cần prompt production đầy đủ. Script thí nghiệm dùng prompt đơn giản 15 dòng. Review production dùng prompt 80 dòng với các quy tắc chống lặp, hạn mức catchphrase, rào chắn biên tập, và chính sách độ dài. Với prompt đơn giản, DeepSeek cho kết quả gần như trung tính (-0.04). Với prompt đầy đủ trong production, pipeline đang hoàn thành thành công với tiếng Anh và tiếng Việt. Tôi cần cập nhật thí nghiệm để phản ánh production và chạy lại.
Bản địa hóa tiếng Trung cần được kiểm chứng. Các quy tắc trông đúng trên giấy, hồ sơ người dẫn đã được viết, hướng dẫn dialogue đã có. Nhưng tôi chưa chạy đánh giá trên các tập tiếng Trung mới để xác nhận điểm đã tăng từ 2.88. Đó là ưu tiên tuần này.
Tôi cần chạy lại bài đánh giá đầy đủ 40 tập trên các tập mới. Tất cả sáu bản sửa đã được deploy. Bước tiếp theo là trích xuất 40 tập được tạo sau những thay đổi này, cho chúng qua cùng các bài đánh giá, và so sánh với baseline lịch sử. Nếu điểm script cuối cùng tăng từ 2.91 lên trên 3.0, và citation credibility tăng từ 1.28 lên mức hợp lý, tôi biết những thay đổi đã hoạt động end-to-end.
Kiểm Toán Pipeline Ba Câu Hỏi
Sau trải nghiệm này, giờ đây tôi kiểm toán mọi thay đổi pipeline dựa trên ba câu hỏi:
1. Có quality gate giữa mỗi bước không? Outline của tôi đi thẳng từ Gemini đến người dùng. Thêm bước critique đã bắt được những outline tệ nhất trước khi ai đó nhìn thấy. Mỗi bước pipeline cần một quality check — đánh giá LLM tự động dựa trên các tiêu chí rõ ràng.
2. Mỗi bước có thực sự cải thiện chất lượng khi được đo lường không? Chạy nó và cho rằng nó có ích là chưa đủ. Bạn cần điểm before/after theo nghĩa đen trên cùng một nội dung. Bước review của tôi đã làm giảm chất lượng scripts suốt sáu tuần trước khi tôi đo lường. Đo lường trước, đừng giả định gì cả.
3. Tôi có thể xác định chiều nào bị hỏng không? "Chất lượng kém" không thể hành động được. "Citation credibility là 1.28 vì 100% URL là redirect không trong suốt" thì có thể. Một rubric đa chiều cho mỗi stage cho bạn biết chính xác nơi cần xem xét. Tôi đã dành hàng giờ điều tra bước review trước khi có bài đánh giá. Với bài đánh giá, tôi chỉ mất vài giây — các con số chỉ thẳng vào publishability và model review.
Câu Hỏi Thường Gặp
Chạy đánh giá LLM không tốn kém sao?
Bài đánh giá đầy đủ 40 tập tốn khoảng $1-2 tiền API calls (GPT-5.6-terra, tổng ~420K tokens). Các thí nghiệm A/B còn rẻ hơn. Với tín hiệu bạn nhận lại — một danh sách xếp hạng chính xác những stage nào của pipeline cần chú ý — đây là công cụ debug rẻ nhất tôi từng xây dựng, và rẻ hơn số credits mà người dùng sẽ lãng phí cho những tập bị lỗi.
Tại sao 5 chiều mỗi stage? Sao không chỉ "chất lượng tổng thể"?
"Chất lượng tổng thể" nói với bạn rằng có gì đó sai. Nó không nói cho bạn biết là gì. Khi tôi thấy Citation Credibility ở 1.28, tôi biết ngay URL bị hỏng. Khi tôi thấy Publishability ở 1.95, tôi biết dấu hiệu AI có thể bị phát hiện. Năm chiều cho bạn một chẩn đoán phân biệt. Một chiều cho bạn một nhiệt kế đo sốt.
Làm thế nào bạn giữ LLM judge nhất quán?
Cùng model (GPT-5.6-terra), cùng temperature (0.0), cùng reasoning effort (medium), cùng rubric prompts mỗi lần. Điểm số được lưu trữ với timestamp để bạn có thể so sánh qua các ngày. Thay judge sẽ thay baseline — chọn một cái và giữ nguyên.
Chuyện gì xảy ra khi chính judge bị sai?
Rubric bao gồm các lý giải bắt buộc cho mỗi điểm — judge phải trích dẫn bằng chứng cụ thể từ nội dung. Tôi cũng đã thực hiện đánh giá định tính thủ công 10 tập trên tất cả 7 ngôn ngữ để hiệu chỉnh judge. Điểm LLM khớp chặt chẽ với đánh giá của con người tôi. Với các chiều quan trọng mà LLM có thể không đáng tin cậy (như "publishability", đòi hỏi đánh giá văn hóa), kiểm tra mẫu bởi con người là thiết yếu.
Tôi xây dựng DIALOGUE, một nền tảng podcast AI, một mình, vào các buổi tối và cuối tuần. Tôi viết về những gì mình học được trên đường đi.
Nếu bạn đã xây dựng một hệ thống đánh giá cho pipeline LLM của riêng mình, tôi tò mò: bạn đo lường chất lượng như thế nào, và bạn đã khám phá ra điều gì khiến bạn ngạc nhiên?
Vậy thôi, hết rồi.
Thân mến, Chandler