Valuable Build Recommendations dựa trên llm-verifier

Phân tích từ research về llm-verifierTurboAgent. 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
UniquenessCó sản phẩm nào làm cái này chưa? Gap cụ thể là gì?
LeverageBuild 1 lần, dùng được cho N use cases / N users
EffortEngineering effort: S/M/L
ValidationCó 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-verifier package
  • 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

  1. Lower barrier: 1 lệnh CLI thay vì setup pipeline.
  2. Defaults that work: Ship criteria templates, user không cần design từ đầu.
  3. 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

  1. Decision making: “Dùng model nào cho codebase mình” dựa trên data, không phải vibes.
  2. Regression safety: Catch khi model update làm tệ task types cũ.
  3. 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

  1. Automatic improvement: Agent tự học từ chính nó.
  2. No human in loop: Scale được.
  3. 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

  1. Multiple perspectives: Catch blind spots của single model.
  2. Explicit concerns: Không chỉ “approve/reject” mà list specific issues.
  3. 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

  1. Higher quality fine-tuning data → better model after fine-tune
  2. Automatic: Không cần human review từng sample
  3. 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

  1. Catch regressions early before users complain
  2. Quantify prompt engineering changes (A/B comparison)
  3. 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

RankRecommendationEffortUniquenessValidation ease
1Verified-CodeGen CLI (#1)MCaoRõ ràng
2Agent Eval Harness (#2)LTrung bìnhRõ ràng
3Training Data Quality Filter (#5)MTrung bìnhRõ ràng
4Multi-Model Consensus (#4)MTrung bìnhRõ ràng
5Quality Monitor (#6)MCaoCần instrumentation
6Self-Improving Worker Loop (#3)LCaoCầ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

  1. Bạn đang ở use case nào trong playbook? (refactor, eval, RLHF, monitoring…)
  2. Có existing tools nào đã cover một phần này không? (custom eval scripts, monitoring stack…)
  3. Who is user? (internal team, external customers, yourself…)
  4. Validation budget? (số tasks có thể test, time horizon)
  5. 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.