Skip to content

perf: profile public recall latency with native reranker and replay costs separated #722

Open

Description

@cdeust

Problem

On the fixed SciFact campaign, Cortex warm public MCP latency averaged 3.550896 s (p95 4.105969 s) versus Hindsight HTTP 1.567441 s (p95 1.857700 s). These are configured product measurements, not an isolated algorithm comparison or a performance regression. Native telemetry confirms 150/150 Cortex recalls succeeded on PG with 300 passages reranked and 100 memories returned.

Proposed solution

Profile retrieval, embedding, cross-encoder inference, enrichments, persistent replay and response serialization before choosing an optimization. Preserve retrieval quality and intended memory-state effects.

Acceptance evidence

  • Reproduce with exact corpus, revisions, models, CPU and public-call parameters.
  • Provide a measured latency breakdown and actual ONNX/PyTorch thread behavior.
  • Any optimization has before/after quality, latency and persistence-correctness evidence under unchanged conditions.
  • Keep first-use/setup latency, warm latency and transport differences distinct.

Alternatives considered

Keep the current behavior and document its limits. This remains valid where the added guarantee has no user need; the issue should close with a documented product decision rather than assume that copying Hindsight is always appropriate. Reuse existing Cortex mechanisms before adding a second pipeline.

Scope assessment

MEDIUM. Raised from the October 10 Hindsight/Cortex comparison. Static observations refer to the pinned revisions below. They do not establish successful execution of Hindsight's whole pipeline or a repository-wide absence in Cortex. Priority is a proposal, not a release blocker.

Evidence

mcp_server/core/reranker.py:156; mcp_server/infrastructure/pg_schema.py:1190; mcp_server/handlers/replay_tracking.py:54

Conditions: Apple M4, 10 CPUs, 24 GiB RAM; separate ephemeral PostgreSQL17.9 databases; CPU models. Cortex all-MiniLM-L6-v2 and FlashRank ms-marco-MiniLM-L-12-v2; Hindsight BAAI/bge-small-en-v1.5 and cross-encoder/ms-marco-MiniLM-L-6-v2. 50 queries, first sweep excluded from warm timing, AB then reversed BA, 100 warm calls per arm. nDCG@10 H=.88664, C=.87956/.87695; Recall@10 H=.956, C=.936. Hindsight fixture imports prebuilt entities/relations, output volumes differ, and Cortex recalls mutate memory state. No general speed claim or causal attribution is established.

Related: #709 covers mechanism-benefit ablations; this issue concerns the latency breakdown of actual public recall.

Activity

  1. cdeust commented on Nov 5, 2026

    @cdeust
    OwnerAuthor

    Tranche 1 livrée dans #878 (Refs #722) : chaque échantillon de télémétrie recall porte désormais stage_ms, le temps par étape de l'appel (embedding de la requête, recherche fusionnée, triage de familiarité, recollection, cross-encoder, nudges post-rerank, étapes finales, enrichissements, suivi du replay, budget de réponse, reçu d'injection, encodage). Mesure seule : classement et réponses inchangés. Surcoût mesuré : environ 1,1 µs par étape.

    Tranches restantes :

    1. Mesurer la ventilation sur la campagne SciFact de l'issue (corpus, révisions, modèles, CPU et paramètres exacts ; PostgreSQL 17.9), en séparant premier usage, latence à chaud et transport.
    2. Relever le comportement réel des threads ONNX/PyTorch pendant l'inférence du cross-encoder et de l'embedding.
    3. Seulement ensuite, une optimisation éventuelle avec preuves avant/après sur la qualité, la latence et la correction de la persistance (replay), dans des conditions inchangées, ou une décision produit documentée de garder le comportement actuel.

    Generated by Claude Code

  2. cdeust commented on Nov 7, 2026

    @cdeust
    OwnerAuthor

    Mise en attente : les tranches restantes demandent un environnement de mesure que l'autopilot n'a pas.

    La tranche 1 (#878, fusionnée) instrumente stage_ms. Les tranches 2 et 3 exigent de rejouer la campagne SciFact de l'issue dans les mêmes conditions : Apple M4, PostgreSQL 17.9 éphémère, modèles CPU all-MiniLM-L6-v2 et FlashRank, mêmes révisions et paramètres, avec une mesure réelle des threads ONNX/PyTorch. Dans ce conteneur, il n'y a pas de PostgreSQL et torch ne s'installe pas (son hôte de téléchargement est bloqué). Une mesure faite ici ne serait pas comparable, et l'issue l'interdit (« under unchanged conditions »).

    Ce qu'un humain doit décider ou fournir : lancer la ventilation sur la machine de référence avec le stage_ms de #878 et en poster le reçu, ou désigner un runner qui reproduit ces conditions. Ensuite, l'autopilot peut reprendre l'éventuelle optimisation ou la décision produit documentée.


    Generated by Claude Code

  3. added
    autopilot:holdCI autopilot stood down: a human decision is required
    on Nov 7, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    autopilot:holdCI autopilot stood down: a human decision is requiredenhancementNew feature or request

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions