fix(memory): recall never reranks on a standard install — the OpenMP guard is always on

[itomek]

Problem

Agent memory recall silently skips its reranking stage on a normal install. The memory spec describes a five-stage retrieval pipeline ending in cross-encoder reranking, but GAIA refuses to load the cross-encoder whenever faiss is already imported and torch is not — which is exactly the state a running agent is in, because the memory index is faiss. So recall falls back to unreranked vector similarity on every conversation, and the only signal is one log line the user never sees.

The refusal itself is deliberate and correct in isolation: loading torch after faiss aborts the process with OMP: Error #15, which is a SIGABRT no except can catch. The problem is that the workaround has become the permanent state — the documented stage never runs, and nothing surfaces that to the user or to anyone reading recall quality.

Observed on every turn of a live flagship run on Ubuntu 24.04 / Ryzen AI 9 465.

Spec: docs/spec/agent-memory-architecture.md:439-447 (the Cross-Encoder Reranking stage, and stage 5 of the pipeline at :429).

Outcome

Either reranking actually runs on a standard install, or the spec and the module docstring stop claiming it does — and in both cases a user or a test can tell which state they are in without reading debug logs.

Acceptance criteria

• On a standard install, a memory recall either runs the cross-encoder or reports that it did not — pick one and make it observable; today _get_cross_encoder() returns None and only a logger.warning records it
• The state is readable without log scraping — e.g. gaia memory status (or the recall result) names the active retrieval stages, with reranking shown as on or off and the reason when off — expected off-state reason text: the OpenMP double-initialisation refusal, naming GAIA_ALLOW_FAISS_TORCH_OMP as the override
• If reranking cannot be made to run by default, docs/spec/agent-memory-architecture.md:439-447 and the pipeline list at :429 say so, and src/gaia/agents/base/memory.py:17 ("Hybrid search: vector + BM25 + RRF fusion + cross-encoder reranking") is corrected to match
• Unit test asserts the guard's outcome for both module states: faiss imported without torch → reranking reported off with the override named; GAIA_ALLOW_FAISS_TORCH_OMP=1 → reranking reported on

Scope & expectations

• Where: src/gaia/agents/base/memory.py — _get_cross_encoder() (:387-430), the OpenMP guard helpers (:283-334), and the module docstring (:17); spec at docs/spec/agent-memory-architecture.md
• Out of scope: the extraction-timeout finding from the same run — that belongs to fix(memory): extraction timeout does not bound the turn's latency #3519, where new live evidence has been added
• Constraints: do not remove the guard without proving the two runtimes coexist on the target platform — the failure it prevents is a process abort, not an exception

How to verify

CLI surface: start an agent, run a memory recall, and show whether reranking ran — the status output or recall result, plus the same command with GAIA_ALLOW_FAISS_TORCH_OMP=1 for contrast.

🔍 Technical details

Claim class: reproduced (executed) — relayed. The observation comes from a live flagship run executed by another session on an Acer Swift (Ryzen AI 9 465, Radeon 880M, Ubuntu 24.04) at 572e8b79, where reranking was reported disabled on every turn. The code citations below were opened and checked against the tree.

src/gaia/agents/base/memory.py:405-417:

if (
    "faiss" in sys.modules
    and "torch" not in sys.modules
    and not _omp_conflict_override()
):
    logger.warning(
        "[MemoryMixin] cross-encoder reranking disabled: faiss is already "
        "loaded and importing torch alongside it aborts the process ...
    )
    _CROSS_ENCODER_UNAVAILABLE = True
    return None

_CROSS_ENCODER_UNAVAILABLE is a module-level sentinel, so once the guard trips the process never retries for its lifetime.

Citation correction: the finding was reported against src/gaia/memory.py:408. No such file exists; the code is at src/gaia/agents/base/memory.py, guard block :405-417, warning at :407.

[github-actions]

Confirmed against the tree, and there's a detail that makes this more fixable than it looks: GAIA already knows the process-abort risk is a macOS problem, but the check that switches reranking off doesn't check the platform — it trips everywhere, including the Ubuntu box you saw it on. So on Linux and Windows reranking is being disabled to prevent a crash that wouldn't happen there.

🟡 Two things worth deciding together:

1. Limiting the switch-off to macOS would make reranking run by default on your machine without weakening the protection where the crash is real. The existing override env var stays as the escape hatch for anyone who hits trouble.
2. The reranker model only ships with the ui extra, so a core install genuinely has no reranking — the spec's claim that it's "already in GAIA's dependencies" is wrong for that case too, and should be fixed alongside.

Either way your ask for an observable state (status output naming the active stages + the reason when off) holds.

🔍 Technical details

_loaded_omp_runtimes() (src/gaia/agents/base/memory.py:307-316) returns early on sys.platform != "darwin", with the docstring stating "on Linux libgomp and libomp coexist routinely, so reporting a 'conflict' there would disable recall on healthy hosts". assert_faiss_omp_safe() (the search-direction guard) therefore no-ops off macOS.

The import-direction guard in _get_cross_encoder() (:405-417) has no such gate — it only tests "faiss" in sys.modules and "torch" not in sys.modules, which is true on every platform once the memory index loads. Adding sys.platform == "darwin" to that condition aligns the two guards and satisfies the "don't remove the guard" constraint, since the abort it prevents is dyld-level.

Second point: sentence-transformers is in the ui extra only (setup.py:204), not install_requires. So for a core install the ImportError branch at :424 is the real path and docs/spec/agent-memory-architecture.md:447 ("already in GAIA's dependencies") is inaccurate independently of the OMP guard. The docstring at memory.py:17 needs the same treatment per your third acceptance criterion.

For the unit test, note _CROSS_ENCODER_UNAVAILABLE and _cross_encoder_model are module-level and sticky — tests need to reset both plus patch sys.platform and sys.modules.