पिछले महीने मैंने pipeline में एक ऐसा change ship किया जिस पर मुझे सच में गर्व था। एक prompt rewrite. एक full-context review step. Repetition पकड़ने और segments के बीच structural variety enforce करने के लिए एक detailed rubric.
मैंने इसे deploy किया। छह हफ़्ते तक observe किया। खुद से कहा कि यह काम कर रहा है।
फिर मैंने एक eval framework बनाया। इसे 7 भाषाओं में 40 real production episodes पर run किया। और पाया कि review step — जिसे डिज़ाइन करने में मैंने इतनी सावधानी बरती थी — scripts को measurably worse बना रहा था।
Neutral नहीं। बदतर।
Per-segment dialogue को 5 में से 3.34 मिले। Outline को 3.01 मिले। और final script, review pass के बाद? 2.91।
Scripts को improve करने के लिए डिज़ाइन किया गया step, quality को 12% से ज़्यादा कम कर रहा था।
यह shift — "मुझे लगता है काम कर रहा है" से "मुझे पता है काम नहीं कर रहा" — कुछ हफ़्ते पहले शुरू हुआ। मैं Andrew Ng का DeepLearning.AI पर Agentic AI course देख रहा था, जहाँ वो एक ऐसी बात पर ज़ोर देते हैं जो सुनने में obvious लगती है लेकिन है नहीं: evals और traces किसी भी agentic system की foundation हैं। इनके बिना, आप अंधेरे में debugging कर रहे हैं। इनके साथ, आपको ठीक-ठीक पता है कि chain की कौन सी कड़ी टूटी।
मैं महीनों से ad-hoc script quality checks चला रहा था — structural metrics जैसे turn length ratios और speaker balance, plus एक LLM judge जो A/B prompt variants की compare करता था। ये obvious regressions पकड़ लेते थे। लेकिन comprehensive नहीं थे। एक stage (dialogue), एक बार में एक language को cover करते थे, और prompt A/B testing के लिए डिज़ाइन थे, न कि pipeline-wide quality audits के लिए।
Traces के बारे में Andrew की बात दिल पर लगी। मेरी pipeline में हर episode के लिए पाँच major LLM calls हैं — research, outline, per-segment dialogue, intro/outro, और review — plus एक ElevenLabs TTS pass। मेरे पास quality metrics सिर्फ़ एक के लिए थी। बाकी चार पर सिर्फ़ instinct से भरोसा किया जा रहा था।
तो मैंने एक real eval system बनाया। Complete. Multi-dimensional. Re-runnable. यहाँ बताया कि इसने क्या पाया, वो छह fixes जो मैंने एक दिन में ship किए, और क्या actually improve हुआ।
The Baseline: तीन Numbers जिन्होंने सब कुछ बदल दिया
मैंने अपने production database से 40 completed episodes evaluate किए — सभी 7 भाषाओं (en, vi, ja, ko, es, zh, fr) और 10 podcast styles को cover करते हुए — तीन rubrics के खिलाफ़ जिनमें हर एक में पाँच dimensions थीं। एक LLM judge (GPT-5.6-terra) ने हर stage को grade किया।
| 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 |
तीन चीज़ें तुरंत सामने आईं:
1. Review pass scripts को 0.43 से degrade कर रहा था। Dialogue को 3.34 मिले। Review के बाद? 2.91। Quality improve करने के लिए डिज़ाइन किया गया step उसे हटा रहा था।
2. सभी Citation URLs opaque redirects थीं। हर outline में हर "source URL" vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQ... पर point करती थी। ये click करने वाले humans के लिए काम करती हैं, लेकिन automated reviewers को पूरी तरह fabricated लगती हैं। 344 facts के पास source URLs थीं। Zero के पास resolved_url — एक field जो अभी तक exist भी नहीं करता था।
3. Publishability पूरी pipeline में सबसे कम dimension थी (1.95)। Real podcasters, eval judge ने determine किया, इन scripts को अपने नाम से publish नहीं करते। Detectable AI patterns: identical segment openers, generic transitions, missing host personality.
Eval ने मुझे exactly क्या fix करना है इसकी एक ranked list दे दी। मैंने बाकी का दिन उसे fix करने में बिताया।
छह Fixes (और उनका Measured Impact)
Fix 1: Citation URLs — 0% से 100% Resolution
Before: 344 में से 0 research facts के पास resolved_url था। हर URL fabricated लगती थी।
Fix: एक 60-line URL resolver जो outline generation के दौरान run होता है, vertex AI redirect को follow करके actual source तक जाता है, और दोनों URLs store करता है (original Google ToS compliance के लिए, resolved बाकी सबके लिए)।
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
After: आज के new episodes में 23 में से 23 research facts के पास resolved_url populated है — real URLs जैसे simonwillison.net, axios.com, thinkingmachines.ai। 100% resolution.
Fix 2: Review Model Swap किया (Gemini → DeepSeek)
Before: Gemini 3.5 Flash review pass run करता था। वो light, conservative edits करता था: "Exactly!" को "No question about it!" में बदल देता था, लेकिन mostly original text को preserve करता था। Filler जोड़ता था जो dialogue को flatten कर देता था। Audio tag density गिर जाती थी। Type-token ratio गिर जाता था। Turn count फूल जाता था।
Fix: Review pass को DeepSeek v4-pro (384K max output, 96K cap set) पर swap किया। Provider को configurable बनाया:
provider = get_provider("review") # reads REVIEW_PROVIDER env var
response = provider.generate(
prompt=prompt, temperature=0.0,
max_output_tokens=96000,
)
Verification: Production में deploy किया। एक Vietnamese tech news episode DeepSeek review के साथ full pipeline से गुज़रा — 10.3K → 11.6K tokens, 121 seconds में complete, 0 tightening passes की ज़रूरत। दूसरा episode (English) 7.9K → 17K tokens, 203 seconds में process हुआ। DeepSeek API key Google Cloud Secret Manager में रहती है, deploy time पर service.yaml के ज़रिए automatically inject होती है।
Fix 3: Outline Self-Critique (+0.50 Improvement)
Before: Outlines सीधे Gemini से user के पास जाती थीं, बिना किसी internal quality check के। Average score: 3.01।
Fix: एक automated critique step जोड़ा। DeepSeek v4-pro outline को 6-dimension rubric (5 outline dimensions plus segment count) के खिलाफ़ evaluate करता है, scores + specific feedback return करता है, और critique को podcast metadata में store करता है।
फिर मैंने एक controlled experiment run किया: 6 episodes लो जिनकी outlines 3.0 से नीचे score करती थीं, DeepSeek critique run करो, feedback को Gemini को regeneration instructions के तौर पर feed करो, और re-score करो।
After: 6 episodes में +0.50 overall improvement।
| 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 |
सबसे खराब episode 1.80 से 3.20 (+1.40) पर चला गया। 6 में से सिर्फ़ 1 खराब हुआ। Critique अब production में default रूप से enabled है — हर new outline user के देखने से पहले यह quality check पाती है।
Fix 4: One-Segment Outlines अब Hard Fail होती हैं
Before: Eval ने दिखाया कि single segment और zero research facts वाले episodes 2.07 जितना कम score कर रहे थे। ये failure cases थे जिन्हें pipeline failures की तरह treat नहीं कर रही थी।
Fix: अगर outline generator एक recovery attempt के बाद 3 से कम valid segments produce करता है, तो podcast को FAILED mark किया जाता है। अब कोई one-segment outline users तक नहीं पहुँचेगी। अगली creation attempt पर, user का credit retry के लिए free कर दिया जाता है।
Fix 5: Chinese Localization Rules
Before: Chinese episodes ने 2.88 score किया — सभी 7 भाषाओं में सबसे कम। Translation artifacts (English idioms literally translated), identical segment openers, Chinese names (明辉/晓雯) की बजाय default English host names (Alex/Maya)।
Fix: Chinese-specific dialogue rules लिखीं: native conversational patterns (不是...而是... constructions), proper sentence-final particles (吧/啊/呢), anti-translation guidelines (कभी "medical miracle" को literally translate मत करना), World Cup episodes के लिए Chinese football metaphors, और distinct personalities के साथ locale-specific host profiles।
Chinese dialogue template, English defaults reuse करने से हटकर अब अपनी 80-line guide रखता है जो conversational patterns, disagreement phrasing, और हर podcast style के लिए audience-specific framing को cover करती है।
Fix 6: Non-English के लिए Host Name Defaults
Before: कई non-English episodes में hosts के नाम Alex और Maya थे। Locale-specific host profiles exist करते थे लेकिन outline generator में fallback path English defaults पर hardcoded था।
Fix: Fix को locale-aware profile resolution pipeline के ज़रिए trace किया। Recent production episodes अब 翔太/健一 (ja), Mạnh/Nga (vi), Hugo/Camille (fr), 明辉/晓雯 (zh) use करते हैं। July commits ने पहले ही edge function और creation flow को fix कर दिया था — remaining fallback खुद outline generator में था।
Eval Framework (Reusable)
जिस framework ने यह सब पाया वो ~500 lines of Python, तीन rubric files (5 dimensions each), एक shared GPT-5.6-terra judge, और एक 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
मैंने A/B comparisons के लिए एक experiments layer भी बनाया:
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
किसी भी pipeline change के बाद python docs/pipeline/evals/run.py --full run करो और ~8 minutes में एक report पाओ। Models compare करने के लिए experiments/review_ab.py --episodes 10 run करो। Results date के हिसाब से archive होते हैं trend tracking के लिए — जानना है कि quality इस महीने पिछले महीने से improve हुई या नहीं? Scores को diff करो।
Full 40-episode eval की cost लगभग $1-2 API calls में आती है। Experiments की cost और कम है। बदले में जो signal मिलता है — एक ranked list जो exactly बताती है कि pipeline के कौन से stages और dimensions पर ध्यान चाहिए — यह मेरा बनाया सबसे सस्ता debugging tool है।
अभी भी क्या टूटा हुआ है
DeepSeek review A/B experiment को full production prompt की ज़रूरत है। Experiment script ने 15-line simplified prompt use किया था। Production review 80-line prompt use करता है जिसमें anti-repetition rules, catchphrase quotas, editorial guardrails और duration policy है। Simplified prompt के साथ, DeepSeek ने essentially neutral results (-0.04) दिखाए। Production में full prompt के साथ, pipeline English और Vietnamese में successfully complete हो रही है। मुझे experiment को production mirror करने और rerun करने की ज़रूरत है।
Chinese localization को validation की ज़रूरत है। Rules कागज़ पर सही दिखती हैं, host profiles लिखे जा चुके हैं, dialogue guides जगह पर हैं। लेकिन मैंने अभी तक new Chinese episodes पर eval run नहीं किया है ताकि confirm कर सकूँ कि score 2.88 से ऊपर गया। यह इस हफ़्ते की priority है।
मुझे new episodes पर full 40-episode eval rerun करने की ज़रूरत है। सभी छह fixes deploy हो चुके हैं। अगला step है कि इन changes के बाद generate हुए 40 episodes extract करो, उन्हें same evals से run करो, और historical baseline के खिलाफ़ compare करो। अगर final script score 2.91 से 3.0 के ऊपर जाता है, और citation credibility 1.28 से reasonable level पर आती है, तो मुझे पता चलेगा कि changes ने end-to-end काम किया।
Three-Question Pipeline Audit
इस experience के बाद, मैं अब हर pipeline change को तीन सवालों के खिलाफ़ audit करता हूँ:
1. क्या हर step के बीच एक quality gate है? मेरी outline Gemini से सीधे user के पास जा रही थी। Critique step जोड़ने से worst outlines किसी के देखने से पहले पकड़ में आ गईं। हर pipeline step को एक quality check चाहिए — explicit criteria के खिलाफ़ automated LLM evaluation।
2. क्या हर step measured होने पर actually quality improve करता है? इसे run करना और assume करना कि इससे मदद हो रही है, काफी नहीं है। आपको same content पर literal before/after scores चाहिए। मेरे review step ने छह हफ़्तों तक scripts को degrade किया इससे पहले कि मैंने measure किया। पहले measure करो, कुछ भी assume मत करो।
3. क्या मैं बता सकता हूँ कि कौन सी dimension टूटी? "Quality खराब है" actionable नहीं है। "Citation credibility 1.28 है क्योंकि 100% URLs opaque redirects हैं" actionable है। हर stage के लिए एक multi-dimensional rubric exactly बताती है कि कहाँ देखना है। मैंने eval से पहले अपने review step की investigation में घंटों बिताए। Eval के साथ, मैंने seconds बिताए — numbers ने सीधे publishability और review model की ओर इशारा किया।
अक्सर पूछे जाने वाले सवाल
LLM evaluations run करना expensive नहीं हो जाता?
Full 40-episode eval की cost लगभग $1-2 API calls में आती है (GPT-5.6-terra, ~420K total tokens)। A/B experiments की cost और भी कम है। बदले में जो signal मिलता है — एक ranked list जो exactly बताती है कि pipeline के कौन से stages पर ध्यान चाहिए — यह मेरा बनाया सबसे सस्ता debugging tool है, और उन credits से भी सस्ता जो users broken episodes पर waste करते।
हर stage के लिए 5 dimensions क्यों? सिर्फ़ "overall quality" क्यों नहीं?
"Overall quality" बताती है कि कुछ गड़बड़ है। यह नहीं बताती कि क्या। जब मैंने Citation Credibility 1.28 पर देखी, तो मुझे तुरंत पता चल गया कि URLs टूटी हैं। जब मैंने Publishability 1.95 पर देखी, तो पता चला कि AI tells detectable हैं। पाँच dimensions एक differential diagnosis देती हैं। एक dimension एक बुखार का थर्मामीटर देती है।
LLM judge को consistent कैसे रखते हो?
Same model (GPT-5.6-terra), same temperature (0.0), same reasoning effort (medium), same rubric prompts हर बार। Scores timestamps के साथ archive होते हैं ताकि आप dates के across compare कर सकें। Judge बदलने से baseline बदल जाती है — एक चुनो और उसी पर टिके रहो।
जब judge खुद गलत हो तो क्या होता है?
Rubric में हर score के लिए required justifications शामिल हैं — judge को content से specific evidence cite करनी होती है। मैंने judge को calibrate करने के लिए सभी 7 भाषाओं में 10 episodes की manual qualitative review भी की। LLM scores मेरे human judgment से closely match करते थे। Critical dimensions के लिए जहाँ LLM unreliable हो सकता है (जैसे "publishability," जिसके लिए cultural judgment चाहिए), human spot-checks ज़रूरी हैं।
मैं DIALOGUE बना रहा हूँ, एक AI podcast platform, अकेले, अपनी शाम और weekends में। मैं रास्ते में जो सीखता हूँ उसके बारे में लिखता हूँ।
अगर आपने अपने LLM pipeline के लिए एक eval system बनाया है, तो मुझे उत्सुकता है: आप quality कैसे measure करते हैं, और आपने ऐसा क्या discover किया जिसने आपको चौंका दिया?
बस, मेरी तरफ से इतना।
शुभकामनाओं सहित, Chandler