# Which Model Should You Use? MR.Q, EBT, SICQL, HRM, Tiny and PACS Compared
# Book: Models From First Principles
# Chapter URL: https://programmer.ie/books/models-from-first-principles/15-chapter/
# Prose fingerprint (sha256, normalized): 8a1ae794740d94d1426fdbe239388ae548661d7ad92b74af74b4cb447cd3c6be
# Snapshot generated at build time by Hugo. This is the complete rendered prose
# of the chapter; it is not a transcript of the source file.

Which Model Should You Use? MR.Q, EBT, SICQL, HRM, Tiny and PACS Compared This is the final post in Models From First Principles.
The earlier posts asked a sequence of architectural questions:
how do we score a context-response pair? when is one scalar no longer enough? when should Q, V and policy become explicit components? when is one forward pass insufficient? when does recurrence help? when does hierarchy help? when is a smaller recursive model a better trade-off? when should attention or a sparse autoencoder be added? when should we change the optimizer rather than the model? This post asks the question that matters when building a real system:
Which one should I actually use?
The short answer is deliberately conservative:
Use the simplest model that solves the decision you actually have.
Do not choose HRM because it sounds more sophisticated than MR.Q.
Do not choose Tiny because recursion sounds more like reasoning.
Do not choose SICQL because three heads sound more intelligent than one.
Do not choose PACS because it is a custom optimizer.
Every additional component creates another hypothesis that must earn its place.
The family we have built can be summarized like this:
MR.Q | | one score is not enough v EBT | | the heads need to become explicit components v SICQL | | one forward pass is not enough v HRM | | hierarchy may be more machinery than we need v Tiny | | inspect the recursive model internally v Residual / Attention / SAE components Meanwhile: model architecture | | optimization itself becomes the bottleneck v PACS That diagram is not a leaderboard.
It is a decision path.
1. First: these models are not simply levels in a power ladder It would be easy to read the series as:
MR.Q < EBT < SICQL < HRM < Tiny That is the wrong interpretation.
A more complex architecture is not automatically a better architecture.
The right question is:
What does my task require? + What evidence do I have that the extra machinery helps? + What latency, memory, training and maintenance cost can I afford? A well-trained MR.Q can be the correct production model even if HRM exists.
A feed-forward scorer can beat a recursive model on a task that does not benefit from iterative computation.
A single scalar can be better than a multi-head system when the deployment decision itself is scalar.
A standard optimizer can be better than PACS if it reaches the same validation quality faster and with less tuning.
So throughout this post we will separate four things:
capability requirement architecture training objective evidence The model name is not the evidence.
2. The one-page decision table Here is the high-level selection guide.
Model Choose it when Main advantage Main disadvantage MR.Q You need one context-conditioned scalar score or ranking Small, fast, easy to debug and calibrate Limited diagnostic surface EBT You need Q, baseline/value and action-policy signals from one representation Cheap multi-head expansion and richer decisions Multi-task interference and ambiguous head semantics SICQL Q, V and Policy must be independently testable, trainable, replaceable or checkpointed Strong modularity and experimental control More interfaces, losses and failure modes HRM Evidence shows iterative computation and multiple timescales help Rich recurrent computation with reused parameters Highest architectural and compute complexity Tiny You want iterative refinement but need a smaller, simpler recurrent architecture Excellent parameter/compute trade-off and clean recursion control One latent state may lose useful hierarchy; recursion still costs runtime PACS The architecture is adequate but optimization dynamics remain the problem Explicit gradient smoothing + preconditioning you can inspect and modify Extra optimizer state/tuning; no guaranteed improvement over AdamW/SGD The rest of the article explains how to make each choice.
3. Start with the decision, not the model Before choosing architecture, write down the runtime decision your system must make.
Examples:
Score this candidate from bad to good. Rank these ten responses for the same prompt. Estimate candidate quality and how much better it is than the expected baseline. Choose one of three actions after evaluating the candidate. Spend more computation on difficult examples and less on easy examples. Provide a quality score plus uncertainty and OOD diagnostics. These are different problems.
The architecture should follow the problem.
A useful design rule is:
one decision variable -> start with one head multiple decision signals -> consider multiple heads iterative improvement -> consider recurrence multiple timescales -> consider hierarchy optimization instability -> investigate optimizer changes 4. MR.Q: use it when one good scalar is enough MR.Q is the default starting point.
Its essential architecture is:
context embedding + response embedding | v pair encoder | v latent representation | v scalar predictor | v Q value The model answers one question:
How valuable is this candidate in this context, according to the target we trained on?
That target might be:
preference; relevance; acceptance probability; human quality score; downstream reward; ranking utility; task success. The architecture itself does not decide which.
When MR.Q is the right choice Use MR.Q when your production decision is fundamentally scalar.
Examples:
Reranking You have 20 generated candidates and need the best one.
scores = model(context.repeat(20, 1), candidates) best = candidates[scores.argmax()] You may not need V.
You may not need a policy head.
You may not need recurrent state.
You need a good ordering.
Filtering You want to reject candidates below a threshold.
Q < threshold -> reject Q >= threshold -> keep Again, one calibrated scalar can be sufficient.
A cheap critic in a larger pipeline A larger model generates candidates.
MR.Q scores them locally.
expensive generator | v N candidates | v cheap MR.Q scorer | v best candidate This is often a very attractive deployment shape.
MR.Q advantages 1. Lowest conceptual complexity There is very little machinery to misunderstand.
2. Low latency One encoder pass and one scalar head.
3. Easy debugging The diagnostic chain is short:
inputs -> representation -> scalar -> loss -> gradient -> update 4. Easy calibration If the scalar is supposed to behave like a probability, calibration is straightforward to inspect.
5. Strong baseline Any more complex model should beat MR.Q on the actual metric that matters before it replaces it.
MR.Q disadvantages 1. Everything is compressed into one number You cannot naturally distinguish:
candidate value baseline expectation recommended action uncertainty OOD risk unless you derive or bolt those on separately.
2. Limited internal diagnostics A bad score tells you less about why the model reached it.
3. No iterative computation It processes the pair once.
If repeated refinement genuinely helps the task, MR.Q cannot express that directly.
Upgrade from MR.Q only when… Upgrade when you can state the missing variable clearly.
Good reason:
We need to distinguish absolute candidate value from value relative to the context baseline.
Weak reason:
EBT is more advanced.
5. EBT: use it when one representation must support several decisions EBT keeps the shared representation but adds several heads.
context + candidate | v shared encoder | v z / | \ v v v Q V Policy | | | +--Q-V logits | advantage This is the first important architectural expansion.
The representation is still computed once.
Several small models then interpret it differently.
When EBT is the right choice Use EBT when the application genuinely benefits from several related signals.
Candidate value plus baseline Suppose two candidates both score 0.8.
That can mean very different things depending on context.
context A baseline: 0.79 candidate score: 0.80 advantage: 0.01 versus:
context B baseline: 0.30 candidate score: 0.80 advantage: 0.50 A single Q score does not expose that distinction.
A Q/V decomposition can.
Scoring plus action recommendation Your runtime might need to decide:
ACCEPT REVISE REJECT You can force those decisions from thresholds on Q.
But a policy head allows the model to learn a separate action surface.
That can be useful when the optimal action is not a monotonic function of score.
Multi-task supervision You may have several labels per example:
quality score action label baseline expectation A shared representation can learn from all of them.
EBT advantages 1. Extra outputs are relatively cheap The expensive representation is shared.
Heads are small.
2. Richer runtime information Instead of:
Q = 0.73 you can have:
Q = 0.73 V = 0.51 A = 0.22 policy = [0.76, 0.19, 0.05] 3. Multi-task regularization can help Different objectives can force the representation to retain useful structure.
But this is an empirical possibility, not a guarantee.
4. Natural bridge to decision modelling You begin separating evaluation from action.
EBT disadvantages 1. Multi-task interference The Q objective may want to move the shared representation one way.
The policy objective may want to move it another.
The V objective may pull in a third direction.
You should inspect gradient conflict rather than assuming the heads cooperate.
2. Loss weighting becomes a real design problem loss = q_loss + 0.2 * v_loss + 0.1 * policy_loss Why 0.2?
Why 0.1?
Those weights can materially change the representation.
3. Head names can overclaim semantics If V sees the candidate as part of the shared representation, calling it a pure V(s) may be mathematically misleading.
4. More outputs create more calibration problems Each head can be wrong in a different way.
Prefer EBT over MR.Q when… The extra signals improve decisions enough to justify their training and maintenance cost.
Not merely because they exist.
6. SICQL: use it when the heads need to become real components EBT and SICQL can look similar from far away.
Both can expose:
Q V Policy Advantage The major practical difference is architectural explicitness.
SICQL makes the components first-class modules.
PairEncoder QHead VHead PolicyHead InContextQModel That changes what you can do experimentally and operationally.
When SICQL is the right choice Use SICQL when you need to manipulate these parts independently.
Independent head training Perhaps your Q labels are plentiful but policy labels are scarce.
You can train:
encoder + QHead first.
Then freeze them and train:
PolicyHead later.
Independent checkpointing You may want:
encoder_v7.pt q_head_v12.pt v_head_v4.pt policy_head_v9.pt That is much easier when the architecture recognizes those as real boundaries.
Head replacement You can test:
small Q head vs large Q head without rewriting the rest of the system.
Different value semantics You can replace a candidate-conditioned V with a true context-only V while leaving Q and Policy untouched.
That is a powerful experimental capability.
SICQL advantages 1. Maximum modularity among the one-pass family Every major semantic surface is explicit.
2. Better ablation discipline You can remove or replace one component cleanly.
3. Better checkpoint discipline Model compatibility becomes easier to reason about.
4. Better parameter ownership Optimizers can target selected modules explicitly.
optimizer = torch.optim.AdamW( model.q_head.parameters(), lr=1e-4, ) 5. Easier transfer and probing A head can be frozen, replaced or probed independently.
SICQL disadvantages 1. Software complexity Every explicit component creates an interface.
Interfaces can drift.
2. Representation compatibility matters A Q head trained against encoder version 3 may not behave correctly with encoder version 5.
3. More checkpoint combinations Modularity gives freedom.
Freedom creates configuration space.
4. The architecture can become over-engineered If you always train and deploy the entire model as one inseparable artifact, SICQL’s modularity may buy little over a simpler EBT-style implementation.
Prefer SICQL over EBT when… You can name an operation you want to perform independently:
replace freeze ablate checkpoint transfer probe retrain If you cannot, EBT may remain the cleaner choice.
7. HRM: use it when one forward pass has become the limitation Everything so far is mostly feed-forward.
The model sees its inputs and produces outputs.
HRM changes the computation itself.
input | v projection | v x_tilde | +------------------+ | | v | low-level state | zL -> zL -> zL | | | v | high-level state | zH -------> zH -----+ The low-level state updates several times.
The high-level state updates less frequently.
The parameters are reused across those steps.
This creates more computation without requiring a completely new set of weights at every step.
When HRM is the right choice Use HRM only when you have evidence that iterative, multi-timescale computation matters.
Difficult examples benefit from repeated computation Suppose validation accuracy changes with recurrence depth:
1 cycle -> 72.1% 2 cycles -> 75.8% 4 cycles -> 79.4% and the gain survives compute-matched baselines.
Now recurrence has evidence behind it.
Fast and slow latent features emerge You may find that probes trained on zL and zH behave differently.
For example:
zL predicts local formatting defects well zH predicts overall acceptance well That would be evidence that the hierarchy has learned specialization.
Adaptive computation becomes valuable Some examples may settle quickly.
Others may need more cycles.
If trajectory diagnostics show this reliably, an HRM-style architecture can support a more adaptive runtime.
HRM advantages 1. More computation per parameter The same recurrent blocks are reused.
2. Two explicit timescales The architecture can, in principle, learn different roles for low- and high-level state.
3. Rich trajectory information You can inspect:
zL at each step zH at each cycle score by cycle state delta convergence 4. Strong fit for tasks where refinement matters If the task genuinely benefits from repeated latent processing, HRM gives the model a mechanism for it.
HRM disadvantages 1. Highest inference cost in this family Parameter count can be modest while runtime compute is large.
Do not confuse those two quantities.
2. More difficult optimization Gradients pass through repeated recurrent applications.
3. More difficult debugging A failure can originate from:
input projection low-level recurrence high-level recurrence normalization cycle scheduling head behavior loss weighting 4. Hierarchy may not actually specialize Two states with two update frequencies do not prove hierarchical reasoning.
5. Latency can become unacceptable A model that is 2% better but 8× slower may be the wrong production model.
Prefer HRM over SICQL when… Your controlled tests show that additional recurrent computation itself creates useful gains, and that the hierarchical schedule beats a simpler recurrent control.
That second clause matters.
Because otherwise you may want Tiny.
8. Tiny: use it when recurrence helps but hierarchy does not earn its cost Tiny asks a very useful control question:
Do we need two recurrent states, or do we mostly need repeated latent refinement?
Its core is simpler:
context candidate latent z | v concatenate | v projection | v core block | v update | v z <- z + alpha * update | repeat One state.
One update rule.
Repeated computation.
When Tiny is the right choice Recurrence beats feed-forward, but HRM does not beat Tiny This is perhaps the clearest use case.
Suppose:
MR.Q / feed-forward: 74.0 Tiny: 80.1 HRM: 80.3 If HRM is materially slower and more complex, Tiny wins.
You need an explicit computation knob Tiny makes recursion depth easy to control.
model(x, y, n_steps=2) model(x, y, n_steps=4) model(x, y, n_steps=8) That makes it attractive for adaptive-compute experiments.
You want a compact critic or evaluator The recursive core can stay relatively small while reusing its weights multiple times.
You want to study latent refinement itself Tiny is easier to analyze than a two-level recurrent hierarchy.
Tiny advantages 1. Simple recurrent mechanism The recurrence is easy to draw and easy to inspect.
2. Good parameter efficiency Repeated compute comes from reused weights.
3. Natural computation-depth control This is valuable both scientifically and operationally.
4. Strong control model for HRM It lets you ask:
recurrence? versus:
hierarchical recurrence? 5. Easy internal experimentation The core can be swapped:
MLP attention other residual block The bottleneck can be swapped:
none dense AE sparse AE Tiny disadvantages 1. A single latent state may collapse useful structure If low-level and high-level state genuinely specialize in HRM, Tiny cannot represent that separation explicitly.
2. Recurrence still costs time A 2-million-parameter model executed eight times is not a one-pass 2-million-parameter model operationally.
3. Step scale becomes important z <- z + alpha * update A poor alpha can make updates too weak or unstable.
4. Halting is another learned claim A halt_head is not automatically a trustworthy compute controller.
5. Extra internals can become decorative Attention and sparse autoencoders should remain only if ablation says they help the relevant objective.
Prefer Tiny over HRM when… Recurrence helps, but the second timescale does not provide enough measurable benefit to justify its cost.
That is a very strong reason to prefer the simpler architecture.
9. What about the attention and SAE components inside Tiny? These are not separate top-level choices in the same sense as MR.Q or HRM.
They are component choices.
But they deserve explicit decision rules.
Use an MLP core when Your latent is a single vector and there is no meaningful sequence or set structure to route across.
[B, D] For many embedding-based scorers, an MLP is enough.
Use attention when There are meaningful positions or slots.
For example:
[context, candidate, latent] or a real token/segment sequence:
[B, T, D] Then attention can route information among distinct elements.
Do not add attention merely because it is available Self-attention over a sequence length of one has no meaningful routing choice.
Compare:
MLP vs one-position attention vs slot attention and measure the task outcome.
Use a sparse autoencoder when You have a concrete reason to impose or study a sparse latent code.
Examples:
interpretability experiments; feature interventions; latent dictionary learning; compact concept probes; decomposition of model behavior. Do not use an SAE merely because you want to call features “concepts” A sparse coordinate is not automatically semantically meaningful.
Look for:
sparsity stability non-redundancy predictive usefulness causal intervention effects replication across seeds If those do not appear, the SAE may simply be extra reconstruction machinery.
10. PACS: use it when the model is not the problem PACS belongs on a different axis.
MR.Q, EBT, SICQL, HRM and Tiny primarily change what is computed.
PACS changes how parameters are updated.
The core update is conceptually:
gradient | +------------+ | | v v EMA(g) EMA(g^2) | | | v | preconditioner | | +-------> divide | v update | v parameter When PACS is the right choice Use PACS only after you have reason to believe optimization dynamics are limiting you.
Training is noisy or unstable Gradient averaging may help stabilize the update direction.
Parameter scales differ dramatically Second-moment preconditioning can normalize updates coordinate-by-coordinate.
You want to study optimizer behavior directly Because PACS is small and explicit, it is easy to instrument.
You can inspect:
raw gradient norm first moment norm second moment preconditioned update norm effective learning rate parameter movement Standard optimizers fail a controlled comparison If PACS consistently beats tuned AdamW/SGD/RMSprop on the metric that matters, that is evidence.
PACS advantages 1. Mechanically simple The update can be understood line by line.
2. Inspectable optimizer state No need to treat optimizer.step() as magic.
3. Separate smoothing and preconditioning timescales The first and second moments can adapt at different rates.
4. Easy to modify experimentally You can remove smoothing, remove preconditioning or change weight-decay semantics independently.
PACS disadvantages 1. Familiar mechanisms are not automatically superior mechanisms Gradient EMA and squared-gradient EMA already exist in established optimizer families.
The burden is on PACS to beat good baselines.
2. More hyperparameters lr beta preconditioner_decay eps weight_decay 3. Extra optimizer state Two tensors per parameter are not free.
4. No automatic bias correction in the implementation we examined Early updates can therefore behave differently from Adam-style bias-corrected moments.
5. Coupled weight decay has different semantics from AdamW Do not compare the same numeric weight_decay and assume equivalence.
PACS is not “after Tiny” This is important.
You can have:
MR.Q + PACS EBT + PACS SICQL + PACS HRM + PACS Tiny + PACS or none of them.
The optimizer axis is orthogonal to the architecture axis.
11. The real architecture matrix A better way to view the family is with several axes.
Property MR.Q EBT SICQL HRM Tiny Context-conditioned scalar score Yes Yes Yes Yes Yes Multiple explicit heads No/Minimal Yes Yes Yes Yes Independent head modules Optional Partial Strong Strong Strong Q/V/Policy decomposition No Yes Yes Optional Optional Recurrent computation No No No Yes Yes Multiple recurrent timescales No No No Yes No Easy computation-depth control N/A N/A N/A Moderate Strong Easy component replacement Strong Moderate Strong Moderate Strong Parameter efficiency via reuse Low relevance Low relevance Low relevance High High Runtime compute cost Lowest Low Low Highest Medium/High Debugging complexity Lowest Low/Medium Medium Highest Medium/High PACS can be placed under any column because it affects optimization rather than forward architecture.
12. The practical selection algorithm If I were implementing a new system, I would use this sequence.
Step 1: Can a simple baseline solve it? Start with something embarrassingly simple.
cosine similarity linear classifier small MLP If that solves the task, stop.
Do not add architecture for aesthetic reasons.
Step 2: Do I need a learned context-conditioned scalar? If yes:
MR.Q Step 3: Do I need several distinct learned signals from the same representation? If yes:
EBT Step 4: Do those signals need independent lifecycle control? Do you need to independently:
freeze replace checkpoint probe train ablate If yes:
SICQL Step 5: Does one-pass computation fail in a way that recurrence fixes? Run the experiment.
feed-forward vs single-state recurrent If recurrence does not help, stop.
If it does:
Tiny becomes a candidate Step 6: Does hierarchical recurrence beat simple recurrence? Compare:
Tiny vs HRM under parameter-matched and compute-aware conditions.
If HRM wins materially:
HRM If not:
Tiny Step 7: Is optimization the remaining bottleneck? Only now consider a custom optimizer.
Compare:
SGD AdamW RMSprop PACS with tuned learning rates and repeated seeds.
13. The decision tree Here is the entire selection process as one tree.
Do you need a learned scorer? | +-- no --> use a deterministic/simple baseline | +-- yes | v Is one scalar enough for the runtime decision? | +-- yes --> MR.Q | +-- no | v Do you need Q/V/Policy-style multiple outputs? | +-- yes --> EBT | | | v | Need independent head lifecycle? | | | +-- yes --> SICQL | | | +-- no --> stay with EBT | +-- maybe other heads --> use the same shared-head principle Then separately: Does repeated computation improve the task? | +-- no --> stay feed-forward | +-- yes | v Does a single recurrent state capture the gain? | +-- yes --> Tiny | +-- no | v Does two-timescale hierarchy beat Tiny enough to pay for it? | +-- yes --> HRM | +-- no --> Tiny Finally: Is the architecture adequate but optimization still limiting? | +-- no --> use the standard optimizer that works best | +-- yes --> benchmark PACS against tuned standard optimizers 14. What I would choose for common scenarios Scenario A: rerank 32 LLM responses Requirement:
prompt + candidate -> quality score Choice:
MR.Q.
Why:
simple; fast; batchable; ranking metric matches runtime use; easy to cache prompt embeddings; easy to benchmark against cosine similarity. Do not start with HRM unless evidence says repeated computation materially improves ranking.
Scenario B: score, estimate baseline, and choose ACCEPT/REVISE/REJECT Requirement:
quality baseline expectation relative advantage action Choice:
EBT initially.
Why:
One representation can support all four outputs cheaply.
Move to SICQL only if the heads need independent training or deployment lifecycle.
Scenario C: Q is stable, policy changes frequently Requirement:
Q scoring is mature.
Policy rules or labels evolve often.
Choice:
SICQL.
Why:
Freeze the encoder and Q head.
Retrain or replace the policy head independently.
That is exactly where explicit component boundaries become valuable.
Scenario D: difficult cases improve when the model gets more internal steps Requirement:
Easy cases work in one pass.
Hard cases improve with more compute.
Choice:
Start with Tiny.
Why:
It is the cleaner test of whether recurrence itself is useful.
Only move to HRM if two-timescale recurrence beats Tiny in controlled comparisons.
Scenario E: the task genuinely contains fast local and slow global structure Suppose experiments show:
zL -> local defect detection zH -> overall quality / long-range decision and HRM beats Tiny at acceptable latency.
Choice:
HRM.
Now the hierarchy has empirical justification.
Scenario F: Tiny works, but training is highly noisy Architecture is already good.
Validation quality is sensitive to gradient noise and parameter scale.
Choice:
Keep Tiny and benchmark PACS.
Do not rewrite the architecture to solve an optimization problem.
Scenario G: production has a 2 ms budget Choice:
Probably MR.Q, possibly a very small EBT/SICQL.
HRM and deep Tiny recursion should have to demonstrate extraordinary value to justify violating the latency budget.
Architecture is constrained by the system it lives inside.
Scenario H: offline evaluator with no strict latency budget Choice:
Tiny or HRM become more plausible.
If evaluations happen offline, repeated computation may be cheap relative to the value of better ranking or diagnostics.
Runtime economics change the architecture decision.
15. Advantages are only advantages relative to the task This deserves emphasis.
Consider recurrence.
For one task:
more compute -> better decisions Recurrence is an advantage.
For another:
more compute -> same decisions Recurrence is pure cost.
Consider multiple heads.
For one dataset:
policy supervision improves shared features Multi-task learning is an advantage.
For another:
policy gradients fight Q gradients It is a disadvantage.
Consider an SAE.
For one research objective:
stable sparse features enable interventions The SAE is valuable.
For a pure ranking deployment:
same ranking accuracy + more parameters + more maintenance It may be pointless.
There are almost no architecture features that are universally good.
16. Compare models on the metric the system actually uses Do not compare models using a metric merely because it is easy to compute.
If production chooses the best candidate among ten responses, evaluate ranking.
Useful metrics include:
pairwise accuracy MRR NDCG precision@1 regret of selected candidate If production thresholds a calibrated probability, evaluate calibration.
Brier score ECE reliability curves precision/recall at operational threshold If production uses uncertainty to route expensive review, evaluate the routing policy itself.
For example:
fraction escalated error rate among non-escalated cases cost per accepted decision The best architecture is the one that improves the actual system objective.
17. Compare cost on more than parameter count A common mistake is to report:
Tiny has X parameters. HRM has Y parameters. and stop.
That misses repeated computation.
Track at least:
parameter count optimizer-state memory activation memory forward FLOPs backward FLOPs latency throughput energy or accelerator time if relevant A recurrent model can be parameter-efficient and compute-expensive at the same time.
Those are not contradictions.
18. The model should earn every upgrade The cleanest development strategy is progressive escalation.
baseline | v MR.Q | | evidence for extra signals v EBT | | evidence for modular lifecycle v SICQL | | evidence for recurrence v Tiny | | evidence for hierarchy v HRM At each arrow, ask:
What failure of the current model are we fixing? What new mechanism fixes it? What metric should improve if the hypothesis is true? What simpler control could explain the same gain? What new cost are we accepting? If you cannot answer those questions, do not upgrade yet.
19. Keep the old model as a control When moving from MR.Q to EBT, do not delete MR.Q.
When moving from Tiny to HRM, do not delete Tiny.
Keep them runnable.
The earlier model becomes your control.
That gives you a living experimental ladder:
MR.Q EBT SICQL Tiny HRM Run them against the same benchmark.
Track:
quality latency memory training stability calibration seed variance operational cost Then the architecture lineage becomes measurable rather than historical.
20. A model registry should store evidence, not only names If these architectures live in a real platform, the registry should not merely contain:
{ "mrq": MRQModel, "ebt": EBTModel, "sicql": SICQLModel, "hrm": HRMModel, "tiny": TinyModel, } It should also contain evidence and constraints.
Conceptually:
ModelCard( name="tiny", task="pair_ranking", embedding_version="v7", validation_ndcg=0.842, latency_ms=3.7, peak_memory_mb=81, seed_std=0.006, benchmark_version="2026-08-08", ) Then model selection can become an engineering decision.
Not folklore.
21. The system can route between models The choice does not always have to be global.
A production system can use models hierarchically.
For example:
100 candidates | v cheap MR.Q | v top 10 | v Tiny | v top 3 | v HRM | v final selection This can produce a better cost-quality frontier than running HRM over every candidate.
Another pattern:
MR.Q confidence high | +-- yes --> accept result | +-- no --> Tiny / HRM escalation Now the architectures become specialists at different compute tiers.
That can be more useful than declaring one universal winner.
22. But routing also has to earn its complexity A cascade introduces new failure modes:
cheap model filters out the true best candidate confidence router is miscalibrated later model never sees difficult examples latency becomes unpredictable multiple checkpoints drift So compare:
single strong model against:
cascade of cheap + expensive models at the same total cost.
Again: architecture is a hypothesis.
23. A concise pros-and-cons summary MR.Q Advantages
smallest conceptual surface; low latency; easy ranking/calibration; easy debugging; strong production baseline; ideal for reranking and filtering. Disadvantages
one scalar hides structure; limited diagnostics; no explicit baseline/action decomposition; no recurrent computation. EBT Advantages
multiple useful signals from one representation; cheap heads; natural Q/V/Policy decomposition; advantage becomes explicit; good multi-task learning test bed. Disadvantages
gradient conflict; loss-weight tuning; more calibration surfaces; head semantics can be ambiguous. SICQL Advantages
strongest modularity in the one-pass family; independent heads; clean ablations; partial checkpoints; component replacement; clearer parameter ownership. Disadvantages
interface complexity; checkpoint compatibility burden; more configuration combinations; can be unnecessary if components never vary independently. HRM Advantages
iterative computation; parameter reuse; multiple recurrent timescales; rich trajectories; potential adaptive compute; potential low/high state specialization. Disadvantages
highest runtime complexity; harder optimization; harder debugging; specialization is not guaranteed; latency can dominate any quality gain. Tiny Advantages
simpler recurrence; strong parameter efficiency; easy depth control; excellent HRM control model; swappable core; easy trajectory analysis. Disadvantages
one state may lose hierarchy; repeated compute still costs runtime; step-scale sensitivity; halting requires validation; optional internals can become decorative complexity. PACS Advantages
transparent custom optimization; gradient smoothing; coordinate-wise preconditioning; easy instrumentation; useful optimizer ablation platform. Disadvantages
more tuning; extra optimizer state; familiar mechanisms may not beat standard optimizers; weight-decay semantics matter; no automatic guarantee of better convergence. 24. My default choices If I had no benchmark results yet, my priors would be:
Need one score? MR.Q.
Need several related outputs? EBT.
Need those outputs independently manageable? SICQL.
Need recurrence? Tiny first.
Have evidence that two recurrent timescales matter? HRM.
Have evidence the architecture is fine but optimizer dynamics are limiting? Benchmark PACS.
That ordering deliberately gives simplicity the benefit of the doubt.
The complex model has to win the argument.
25. The most important comparison is not model versus model The most important comparison is:
complexity added versus measurable value created Suppose HRM improves NDCG from:
0.841 -> 0.844 but multiplies latency by five.
That may be a loss.
Suppose EBT improves ranking only slightly but its policy head eliminates a costly downstream model call 30% of the time.
That may be a major win.
Suppose Tiny gives the same accuracy as HRM but exposes a cleaner adaptive-compute mechanism.
Tiny may be preferable even at equal accuracy.
The deployment objective is larger than the model metric.
26. The whole series in one idea We began the series with a claim:
A sophisticated model becomes understandable when you recursively decompose it.
We can now go the other direction.
Start from basic operations:
matrix multiply normalization activation addition moving average Compose them into components:
encoder head residual block recurrent block autoencoder optimizer Compose those into models:
MR.Q EBT SICQL HRM Tiny Then compose models into systems:
generate score rank route refine select At no point do we need magic.
What changes is the arrangement of ordinary mechanisms.
27. Final rule: choose by evidence, not architectural prestige There is a temptation in machine learning to move toward the most sophisticated architecture available.
That reverses the engineering process.
The better process is:
start simple measure failure identify missing capability add the smallest mechanism that could fix it measure again keep it only if it earns its cost So:
Use MR.Q when one score solves the problem.
Use EBT when several related signals genuinely improve the decision.
Use SICQL when those signals need independent architectural lives.
Use Tiny when repeated latent refinement helps and a single recursive state is enough.
Use HRM when hierarchy itself demonstrates value beyond simple recurrence.
Use PACS when the remaining problem is parameter-update dynamics rather than model structure.
And if a linear model solves the task better at the required latency and cost?
Use the linear model.
That is not a failure to use the advanced architecture.
That is the point of understanding the architecture in the first place.
Series complete Models From First Principles has moved from the smallest pair scorer through multi-head decision models, modular Q/V/Policy components, hierarchical recurrence, compact recursive reasoning, residual/attention/SAE internals, and finally optimizer construction.
The goal was never to memorize model names.
The goal was to be able to open an unfamiliar architecture, reduce it to understandable parts, ask what each part contributes, and decide whether it deserves to exist.
Once you can do that, a model stops being a black box.
It becomes an engineering system.