- Plexer: always-active terminal multiplexing. NativePlexerController/ TmuxPlexerController share one interface, chosen by which env var is already set (TAI_PLEXER_SOCKET vs TMUX_PANE); NativePlexerBackend is the pty.fork()-based wrapper (raw mode, SIGWINCH resize forwarding, a Unix-socket control protocol, continuous session logging, a Ctrl+A prefix key distinct from tmux's own Ctrl+B). Auto-wraps new interactive shells via a .bashrc hook mirroring the existing command-not-found install pattern, gated on $TMUX/$TAI_PLEXER_ACTIVE/ a $HOME/.tai-no-plexer bypass. New plexer_send/read/type/status tools, env-gated on a detected controller. - tests/container.py + docker-compose.yml + tests/docker/Dockerfile: a disposable podman/docker image for the tests that must never touch a real machine (installing the plexer hook into a real ~/.bashrc, a live tmux session). Required suite (test_seal.py, test_tai.py, tests/plexer.py, tests/bashrc.py) gates the result; tests/rag.py runs as best-effort since its real-LLM dependency can't be satisfied inside a disposable container with no nested engine. - tests/bashrc.py: real end-to-end hook install + bash -i auto-wrap, anti-recursion, tmux-active skip, non-interactive skip, a live TmuxPlexerController test, and an install/uninstall round-trip. - tests/plexer.py: NativePlexerBackend under a real pty, plus a dedicated robustness pass (file permissions, >64KB payload framing, a malformed control request, a genuine self-deadlock fix in the write-to-child path). - tai_test.py: the shared async process-driving framework (pipe/pty transport, group-wide kill-and-reap, a StdinBridge for --interactive) both test files build on. - ChatClient last-resort backend: when there's no local opencode CLI but the sandbox box is already running, install opencode into it (official Node tarball, not apt -- apt's nodejs/npm pull in webpack/babel/jest as transitive deps) and route through it instead of giving up. Only reachable after the first retry round already failed everything else; never creates the box itself. TmuxPlexerController.status() fixed to use `list-panes` instead of `display-message -p`, which silently fell back to the default pane instead of erroring against a dead target. - Fix 4 pre-existing test_tai.py bugs surfaced by running it in a clean environment for the first time: two stale mock signatures (subprocess.run's stdout= kwarg, Chat.complete's deadline= kwarg), one $TMUX-dependent catalog assertion, one tty-dependent color assertion. - research/: a sourced research archive (Source Dossier/Citation Card/Conclusion tiers) backing the above design decisions, with its own audit.py consistency checker. - .gitignore: fix a blanket *.md rule that was about to silently drop the entire research/ archive from version control; add __pycache__/ and the one-off debug transcript this session started from. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2.3 KiB
What Is Reciprocal Rank Fusion?
Metadata
| Field | Value |
|---|---|
| Institute | Molodetz Institute — Research & Retrieval Division |
| Subject | sqlite-rag-hybrid-search |
| Document type | Source Dossier |
| Tier | 1 |
| Source title | What is Reciprocal Rank Fusion? |
| Source URL | https://www.paradedb.com/learn/search-concepts/reciprocal-rank-fusion |
| Source publisher / author | ParadeDB (vendor "learn" page) |
| Source type | vendor docs |
| Source date (published) | Unknown — not stated |
| Date researched | 2026-10-09 |
| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
| Research method | web search synthesis |
| Confidence | Medium |
| Status | Active |
Summary
Covers the same RRF mechanism as the other two RRF sources in this subject, but is the specific source for RRF's main documented limitation: because RRF only uses rank position, it treats a document that is overwhelmingly the best match in one list only slightly better than the runner-up — the magnitude of the win is discarded, not just normalized.
Key findings
- RRF's score-magnitude blindness is named explicitly as the technique's main limitation, with the suggestion that a score-aware fusion or a post-RRF reranker can help when score gaps genuinely matter.
- Corroborates (independently of
spiceai-reciprocal-rank-fusion.md) the standard formula and the k=60 convention.
Pros / strengths
- The clearest, most direct statement among the three RRF sources of RRF's actual weakness, rather than treating RRF as a strictly-better free lunch.
Cons / limitations / caveats
- Vendor "learn" page (ParadeDB, a Postgres-search company); the limitation is stated plainly but no quantitative example or benchmark accompanies it in what was gathered during this research pass.
Relevance to tai
Directly informed the final proposal's framing (in the separate agent-memory-recency-tracking subject, not this one) that if tai ever revisits combining signals — e.g. lexical BM25 plus some future recency/frequency signal — it should go in eyes-open about RRF discarding score magnitude, which matters more for a small, low-cardinality signal like recency than for two large ranked lists. See conclusions/no-vectors-bm25-chunked-rag.md.
Changelog
| Date | Change |
|---|---|
| 2026-10-09 | Initial dossier created. |