💡 Deep Analysis
5
What core problem does ADHD solve, and how is it more effective than simple Chain-of-Thought or Tree-of-Thought?
Core Analysis¶
Project Positioning: ADHD addresses premature convergence and anchoring in autoregressive reasoning. Instead of relying on prompt tricks or more random samples, it spawns multiple isolated cognitive frames to diverge in parallel, then runs an independent critic pass to score, cluster, prune traps, and deepen survivors into actionable candidates.
Technical Features¶
- Parallel isolated divergence: Frames do not share context during divergence, preventing cross-branch anchoring.
- Generator/critic split: Allows different models or metrics for generation and evaluation, reducing shared bias.
- Clustering/pruning + trap annotations: De-duplicates similar candidates and attaches short risk notes to help decision-making.
Practical Recommendations¶
- Try on design/fuzzy problems first: Naming, API surface design, strategy, and fuzzy debugging benefit most.
- Start small: Run a few frames with cheap scout models to validate diversity before scaling up.
Cautions¶
- Parallel runs increase API calls, cost, and latency—tune frame counts and use tiered model strategies.
- If underlying LLMs or critics are unreliable, the architecture cannot fully eliminate hallucinations.
Important: Record each frame’s intended bias (e.g., conservative/cost-first/contrarian) in metadata to improve interpretability and reproducibility.
Summary: ADHD engineers diversified search and evaluation into a pluggable agent skill, offering measurable benefits on creative and decision-heavy tasks by expanding candidate breadth and providing explainable pruning and deepening.
Why does ADHD separate generator and critic, and what practical advantages and risks does this bring?
Core Analysis¶
Issue: ADHD separates generator and critic to reduce shared bias between generation and evaluation and to improve trap detection and explainability.
Technical Analysis¶
- Advantages:
- Reduces shared bias: Independent models reduce the chance of repeating the same systematic error.
- Tiered efficiency: Cheap scouts explore widely; higher-quality critics sift promising candidates to balance cost and quality.
-
Explainable pruning: Critics can produce short trap reasons for quick human review.
-
Risks:
- Critic bottleneck: A poorly designed critic can prune good options or keep noise; calibration is required.
- Increased system complexity: More models, calls, and operational surface.
- Inconsistent scoring scales: Different critics need normalization or a voting mechanism.
Practical Recommendations¶
- Multi-critic approach: Use multiple independent critics or a hybrid rule+model critic for critical decisions.
- Calibration and audit: Maintain critic logs and periodically recalibrate thresholds with human-labeled samples.
- Cost control via layering: Run inexpensive scouts first, then run expensive critics only on survivors.
Cautions¶
Important: Treat critics as helpers, not infallible judges. Keep a human-in-the-loop for correcting mis-pruning.
Summary: The generator/critic split is a core innovation that boosts diversity and trap detection, but it requires engineering controls—calibration, multi-critic voting, and observability—to avoid new failure modes.
How to balance frame count (N) against cost, latency, and search breadth in production? What deployment strategies are practical?
Core Analysis¶
Issue: Increasing frame count raises search breadth but also increases API calls, cost, and latency. You must balance quality gains against resource investment.
Technical Analysis¶
- Layered models (scout → critic → deepen): Run cheap scouts across many frames; only pass top-K survivors to expensive critics and deepen steps to save cost.
- Early-stop and budgeting: Enforce token/time caps per frame; stop spawning new frames when diversity or cluster thresholds are met.
- Distributed execution: Map frames to temporary orchestrator peers and apply priority queues and rate limits to control concurrency spikes.
Practical Recommendations¶
- Start with 3–6 frames: Track incremental clusters gained per extra frame and scale by marginal utility.
- Deepen only survivors: Limit expensive model calls to the top 3–5 candidates.
- Metric-driven scaling: Use ‘new clusters per call’ as a signal—stop scaling when it drops below a threshold.
Cautions¶
Important: Avoid running many parallel frames on the interactive critical path; use ADHD for background suggestions or in scenarios where some latency is acceptable.
Summary: Use ‘wide then deep’ plus layered models, early stops, and observability to keep costs and latency manageable while retaining most diversity benefits.
How should one design high-quality, complementary cognitive frames to ensure the divergent stage yields valuable candidates?
Core Analysis¶
Issue: The quality of frames determines the signal-to-noise ratio and complementarity in the divergence stage. Random or similar frames produce redundant or low-value candidates.
Technical Analysis¶
-
Three Essentials:
1. Explicit bias: Document each frame’s goal/metric (e.g., maximize novelty, minimize cost, prioritize safety).
2. Executable template: Turn the bias into concrete prompts (constraints, required failure modes, or specific metrics).
3. Coverage metrics: Measure clustering, redundancy, and score distributions to quantify complementarity. -
Experimental loop: Start with 4–6 manually complementary frames, run small experiments, and adjust based on output characteristics.
Practical Recommendations¶
- Begin with opposing perspectives: E.g., conservative vs. aggressive vs. cost-focused vs. safety-first vs. contrarian vs. UX-first.
- Record frame metadata: For auditability, provenance, and reproducibility.
- Automate metrics: Use clustering stats (dedup rate, number of clusters, avg score per cluster) to guide frame adjustments.
Cautions¶
Important: Too many non-complementary frames waste resources; too few miss blind spots. Aim for a moderate number with high complementarity.
Summary: Treat frames as experimental variables and iterate with small-scale tests and clustering/coverage metrics to achieve cost-efficient, high-quality diversity.
How should ADHD's critic be validated and calibrated to avoid false pruning, and what engineering practices reduce this risk?
Core Analysis¶
Issue: Critics can false-prune high-value candidates, so their decision boundaries must be validated and calibrated with engineering controls.
Technical Analysis¶
- Multi-critic / hybrid approach: Use multiple independent critics (or rules+models) and decide via voting/weights for critical pruning actions.
- Confidence-tiered decisions: Classify outputs into high-confidence (auto prune), medium-confidence (human review), and low-confidence (retain/retry).
- Audit replay & labeled sets: Save critic reasons and human outcomes to build calibration datasets for tuning critics.
- Online experiments: Run A/B tests to measure business impact of pruning choices (rollbacks, manual remedies).
Practical Recommendations¶
- Conservative defaults: Start with conservative pruning thresholds to minimize false-pruning; tighten gradually.
- Keep snapshots: Store pruned candidates and critic rationales for sampling audits and training data creation.
- Cross-model judgment: Use models with different architectures/training objectives to reduce shared bias.
Cautions¶
Important: Treat critics as assistive filters, not infallible authorities—maintain human-in-the-loop for critical decisions.
Summary: False-pruning can be mitigated with multi-critic voting, confidence-tiering, audit/replay logs, and staged rollouts, providing both protection and data for continuous critic improvement.
✨ Highlights
-
Architectural fix for premature convergence
-
Adopted and integrated by multiple OSS projects
-
Independent evals show increased novelty and breadth
-
License and language-stack information are unclear
-
Risk: contributor and commit records are missing/inconsistent
🔧 Engineering
-
Spawns parallel isolated reasoning frames, then scores and prunes survivors
-
Suitable for design decisions, fuzzy debugging, naming, and strategy tasks
⚠️ Risks
-
No clear license; adoption may incur legal, compliance and distribution risk
-
Repo lacks language metadata and contributor history, affecting maintainability and trust
-
Relies on closed models (Claude/Codex); availability and cost may limit use
👥 For who?
-
Targeted at multi-agent system developers, researchers, and skill maintainers
-
Well suited for engineering teams and product designers needing multi-solution exploration and creativity