Phân tích từ research về llm-verifier và TurboAgent. Focus: cái gì đáng build dựa trên gaps trong ecosystem hiện tại.
Framework đánh giá
Mỗi recommendation được đánh giá trên 4 trục:
| Trục | Ý nghĩa |
|---|---|
| Uniqueness | Có sản phẩm nào làm cái này chưa? Gap cụ thể là gì? |
| Leverage | Build 1 lần, dùng được cho N use cases / N users |
| Effort | Engineering effort: S/M/L |
| Validation | Có cách nào verify nó work không? |
Recommendation #1: Verified-CodeGen CLI Wrapper
Effort: M | Uniqueness: Cao | Leverage: Cao | Validation: Rõ ràng
Vấn đề
Hiện tại nếu bạn muốn “code được verified”, bạn phải tự setup:
llm-verifierpackage- Backend logprob (DeepSeek hoặc Vertex)
- Generate N candidates manually
- Wire criteria + scoring
- Track output
Đây là 30-60 phút setup cho mỗi người. Quá nhiều friction cho “tôi chỉ muốn refactor module này cho đúng”.
Giải pháp
Một CLI wrapper đơn giản:
verified-codegen \
--task "Migrate this Vue 2 component to Vue 3" \
--files src/components/UserProfile.vue \
--candidates 3 \
--verifier deepseek \
--criteria correctness,compatibility,performance
Output:
Generating 3 candidates...
✓ Candidate 1 (claude-opus-4-5): 4.2s
✓ Candidate 2 (claude-opus-4-5): 3.8s
✓ Candidate 3 (claude-opus-4-5): 4.1s
Running verification (deepseek-v4-flash)...
Pairwise comparisons: 3
Criterion scores:
correctness: 0.92
compatibility: 0.87
performance: 0.74
Winner: Candidate 1 (overall: 0.876)
Apply diff? [y/n/diff]
Tech stack
- Python Click/Typer cho CLI
- Wrap
llm-verifier.select() - Default criteria templates cho common tasks (refactor, migration, bugfix)
- Output diff viewer integration
Why this is valuable
- Lower barrier: 1 lệnh CLI thay vì setup pipeline.
- Defaults that work: Ship criteria templates, user không cần design từ đầu.
- Visible ROI: Diff + scores = user thấy ngay tại sao winner thắng.
Validation
- Pilot trên 5 internal refactoring tasks
- Measure: candidate 1 (no verification) vs candidate 1 (with verification) trên test suite pass rate
- Expected: verified version pass rate > 80%, unverified < 60%
Recommendation #2: Agent Eval Harness
Effort: L | Uniqueness: Trung bình | Leverage: Rất cao | Validation: Rõ ràng
Vấn đề
Nếu bạn đang xây agents (Claude Code workers, pi coding agents, custom harnesses), bạn cần biết:
- Agent A tốt hơn agent B trên task type X?
- Update version mới có regression không?
- Model mới (Opus 4.5 → 4.6) có cải thiện cho domain của mình không?
Hiện tại: anecdotal evidence, không có data. “Tôi thấy nó tốt hơn” ≠ measured improvement.
Giải pháp
Eval harness chạy N trajectories per (agent, task) pair, dùng llm-verifier.select() để rank + score:
import agent_eval
results = agent_eval.run(
agents=["claude-opus-4-5", "gemini-3-flash", "deepseek-v4"],
tasks=load_internal_tasks("tasks/refactoring.jsonl"),
n_trajectories=5,
verifier="deepseek/deepseek-v4-flash",
criteria=load_criteria("criteria/internal_code_quality.md"),
)
# Outputs: leaderboard, per-task scores, regression detection
results.leaderboard()
# | Agent | Pass@1 | Verified-Select@5 | Oracle |
# |--------------------|--------|-------------------|--------|
# | claude-opus-4-5 | 0.72 | 0.84 | 0.91 |
# | gemini-3-flash | 0.68 | 0.79 | 0.88 |
# | deepseek-v4 | 0.65 | 0.77 | 0.85 |
Features
- Leaderboard: rank agents across task categories
- Regression detection: rerun on commit, alert nếu score drop > threshold
- Cost tracking: input/output/cached tokens per agent
- Trajectory diff: xem agents approach tasks khác nhau thế nào
Tech stack
- Python, wrap
llm-verifier - Web UI cho leaderboard (Vite + React, như TurboAgent visualizer)
- SQLite/Postgres cho results storage
- GitHub Actions integration cho CI regression
Why this is valuable
- Decision making: “Dùng model nào cho codebase mình” dựa trên data, không phải vibes.
- Regression safety: Catch khi model update làm tệ task types cũ.
- ROI tracking: Measure improvement qua các iteration.
Validation
- Run trên 30 internal tasks × 3 agents = 450 trajectories
- Correlate verified scores với human evaluation (subset)
- Expected: correlation > 0.7 nếu verifier well-calibrated
Recommendation #3: Self-Improving Worker Loop
Effort: L | Uniqueness: Cao | Leverage: Cao | Validation: Cần iteration
Vấn đề
Agents (Claude Code, pi, custom) generate trajectories. Mỗi trajectory có quality khác nhau. Hiện tại: chỉ giữ winner, throw away losers.
Đây là waste data. Nếu biết cách extract signal từ losers, bạn có training data tự động.
Giải pháp
Self-improving loop:
┌─────────────────────────────────────────┐
│ 1. Agent chạy task → N trajectories │
│ │
│ 2. Verifier rank trajectories │
│ → winner: high score │
│ → losers: low score, với reason │
│ │
│ 3. Extract learning signal: │
│ - Winner trajectory → "good pattern" │
│ - Loser trajectories → "anti-pattern"│
│ │
│ 4. Update agent context/prompts: │
│ - Add good patterns to few-shot │
│ - Add anti-patterns to avoid list │
│ │
│ 5. Rerun task với updated context │
│ → verify improvement │
└─────────────────────────────────────────┘
Implementation sketch
import llm_verifier
def self_improve_step(agent, task, iteration=0):
# Generate N candidates
candidates = [agent.run(task) for _ in range(5)]
# Verify
result = llm_verifier.select(
problem=task.description,
candidates=candidates,
criteria=task.criteria,
n_evaluations=4,
)
# Extract patterns (đây là phần cần build)
patterns = extract_patterns(
winner=candidates[result.index],
losers=[c for i, c in enumerate(candidates) if i != result.index],
verifier_scores=result.scores,
)
# Update agent context
agent.update_context(
good_patterns=patterns["good"],
anti_patterns=patterns["bad"],
)
return result
def extract_patterns(winner, losers, verifier_scores):
# Use LLM to analyze WHY winner won
analysis = llm_verifier.compare(
problem="Why did the winner succeed where losers failed?",
a=winner,
b=losers[0],
criteria={"Pattern analysis": "What specific patterns differentiate winner from loser?"},
)
# Returns structured patterns
return parse_analysis(analysis)
Why this is valuable
- Automatic improvement: Agent tự học từ chính nó.
- No human in loop: Scale được.
- Compound gains: Mỗi iteration cải thiện một chút → compound over time.
Gotchas
- Local minima: Agent có thể converge sớm vào sub-optimal pattern. Cần diversity injection.
- Verifier bias: Nếu verifier model biased, improvement loop amplify bias.
- Cost: N candidates × M iterations × verifier cost = expensive.
Validation
- Pick task domain có measurable metric (test pass rate, code coverage)
- Baseline: agent without self-improvement loop
- Treatment: agent with loop, 3-5 iterations
- Expected: +5-10% improvement over 5 iterations trên test metric
Recommendation #4: Multi-Model Consensus for Critical Decisions
Effort: M | Uniqueness: Trung bình | Leverage: Trung bình | Validation: Rõ ràng
Vấn đề
Một số decisions critical không nên trust single model:
- Security review của PR
- Architecture decision cho hệ thống mới
- Database migration plan
Multiple perspectives tốt hơn single perspective.
Giải pháp
Multi-model consensus wrapper:
critical-review \
--input "PR #234: Add OAuth flow" \
--models claude-opus-4-5,gemini-3-flash,deepseek-v4 \
--reviewer deepseek-v4-flash \
--threshold 0.8
Output:
Model perspectives:
claude-opus-4-5: Score 0.91 (approve, 1 concern: token storage)
gemini-3-flash: Score 0.88 (approve, 2 concerns: token storage, rate limit)
deepseek-v4: Score 0.72 (concerns, 4 concerns including CSRF protection)
Consensus: NOT APPROVED (concerns unaddressed)
Critical concerns (across all models):
1. CSRF protection missing on /callback endpoint (deepseek-v4, gemini-3-flash)
2. Token storage in localStorage (XSS risk) (all 3 models)
3. No rate limiting on token endpoint (gemini-3-flash)
Action: Address concerns before merge.
Tech stack
- Wrap
llm-verifier.compare()cho pairwise + multi-model - GitHub PR integration (bot comment)
- Configurable criteria per review type (security, performance, style)
- Slack/email alerts cho critical findings
Why this is valuable
- Multiple perspectives: Catch blind spots của single model.
- Explicit concerns: Không chỉ “approve/reject” mà list specific issues.
- Audit trail: Reasoning visible, không phải black box.
Validation
- Run trên 20 PRs với known issues
- Compare: single-model review vs multi-model consensus
- Metric: catch rate of critical issues, false positive rate
Recommendation #5: Training Data Quality Filter
Effort: M | Uniqueness: Trung bình | Leverage: Cao (nếu bạn đang fine-tune) | Validation: Rõ ràng
Vấn đề
Nếu bạn đang fine-tune models trên synthetic data, data quality quyết định model quality. Hiện tại: generate N candidates, pick “best” = unclear decision.
Giải pháp
Filter pipeline:
from verified_dataset import filter
raw_dataset = load_synthetic_data("raw.jsonl") # 100k samples
filtered = filter(
raw_dataset,
criteria={
"Correctness": "Is the response factually correct?",
"Relevance": "Does it answer the prompt?",
"Coherence": "Is it logically consistent?",
},
n_candidates_per_prompt=5,
verifier="deepseek/deepseek-v4-flash",
quality_threshold=0.7, # only keep samples with verifier score > 0.7
)
filtered.save("filtered_dataset.jsonl")
# 100k → 60k (40% rejected as low quality)
Features
- Quality scoring: Verifier score per sample
- Threshold filtering: Drop below threshold
- Diversity preservation: Don’t collapse to single pattern
- Statistics: Distribution of scores, reasons for rejection
Why this is valuable
- Higher quality fine-tuning data → better model after fine-tune
- Automatic: Không cần human review từng sample
- Auditable: Score distribution shows dataset health
Validation
- Fine-tune same base model với (a) raw data, (b) filtered data
- Compare on held-out eval set
- Expected: filtered version +5-15% trên eval
Recommendation #6: Continuous Quality Monitor (Production)
Effort: M | Uniqueness: Cao (niche) | Leverage: Cao nếu ship LLM products | Validation: Cần instrumentation
Vấn đề
LLM apps in production drift:
- Model updates change behavior
- Prompt changes break edge cases
- User input distribution shifts
Không có continuous monitor = phát hiện vấn đề khi users complain.
Giải pháp
Sample-based quality monitor:
from quality_monitor import Monitor
monitor = Monitor(
sample_rate=0.01, # 1% of production traffic
criteria={
"Correctness": "Is the response correct?",
"Helpfulness": "Is it useful for the user?",
"Safety": "No harmful content?",
},
verifier="deepseek/deepseek-v4-flash",
)
@monitor.track
def my_llm_function(prompt):
return llm_call(prompt)
# Outputs to dashboard:
# - Daily quality scores
# - Regression alerts (score drops > threshold)
# - Failure mode clustering
Dashboard
- Time series of quality scores per criterion
- Alert khi score drops > 2σ from baseline
- Failure clusters (similar failing prompts grouped)
- Export to existing observability stack (Datadog, Grafana)
Why this is valuable
- Catch regressions early before users complain
- Quantify prompt engineering changes (A/B comparison)
- Detect distribution shift in user inputs
Gotchas
- Verifier cost: Even 1% of traffic = significant volume
- Verifier latency: Async batch processing recommended
- False positives: Need careful threshold tuning
Validation
- Inject known bad responses, verify monitor catches them
- A/B test prompt changes, measure quality delta
Priority ranking
| Rank | Recommendation | Effort | Uniqueness | Validation ease |
|---|---|---|---|---|
| 1 | Verified-CodeGen CLI (#1) | M | Cao | Rõ ràng |
| 2 | Agent Eval Harness (#2) | L | Trung bình | Rõ ràng |
| 3 | Training Data Quality Filter (#5) | M | Trung bình | Rõ ràng |
| 4 | Multi-Model Consensus (#4) | M | Trung bình | Rõ ràng |
| 5 | Quality Monitor (#6) | M | Cao | Cần instrumentation |
| 6 | Self-Improving Worker Loop (#3) | L | Cao | Cần iteration |
Why ranking này
- Top 3: Clear problem, clear solution, easy to validate. Ship nhanh, ROI sớm.
- #4: Useful nhưng narrower audience (chỉ ai có critical decisions).
- #5: Powerful nhưng cần production scale mới worthwhile.
- #6: High upside nhưng high uncertainty. Build sau khi có proven value từ simpler tools.
Build sequence đề xuất
Phase 1 (1-2 tuần):
- Verified-CodeGen CLI (#1)
- Validate trên internal tasks
- Nếu proven valuable → continue
Phase 2 (2-4 tuần):
- Training Data Quality Filter (#5)
- Nếu bạn đang fine-tune models: integrate vào pipeline
- Nếu không: skip, move to #2
Phase 3 (4-6 tuần):
- Agent Eval Harness (#2)
- Long-term infrastructure investment
- Enable data-driven decisions về model/agent choice
Phase 4 (tùy nhu cầu):
- Multi-Model Consensus (#4) nếu có security-critical reviews
- Quality Monitor (#6) nếu ship LLM products ở scale
- Self-Improving Loop (#3) nếu proven value từ Phase 1-3
Open questions cần answer trước khi build
- Bạn đang ở use case nào trong playbook? (refactor, eval, RLHF, monitoring…)
- Có existing tools nào đã cover một phần này không? (custom eval scripts, monitoring stack…)
- Who is user? (internal team, external customers, yourself…)
- Validation budget? (số tasks có thể test, time horizon)
- Maintenance appetite? (one-off tool, long-term infra…)
Trả lời 5 câu này → narrow down recommendation #1-#6 thành 1-2 cái đáng build ngay.