Skip to content

Add OrcaReplay - #602

Open
xizhuomengcontin wants to merge 2 commits into
deepset-ai:mainfrom
xizhuomengcontin:add-orcareplay
Open

xizhuomengcontin wants to merge 2 commits into
deepset-ai:mainfrom
xizhuomengcontin:add-orcareplay

Conversation

@xizhuomengcontin

Copy link
Copy Markdown

Adds integrations/orcareplay.md.

What it is

OrcaReplay (Apache-2.0, npm, Node 20+) records a Haystack run at the HTTP boundary to the model provider — from outside the process — and serves the recording back so the same run happens again with no provider contacted and no key needed.

There is nothing to register and no component to add, because OpenAIChatGenerator leaves api_base_url=None and the OpenAI SDK then falls back to OPENAI_BASE_URL — the variable the recorder sets for the child process it launches, and only for that process.

Verified before submitting

haystack-ai 3.1.1 on Python 3.12, both a standalone OpenAIChatGenerator and a full Pipeline (ChatPromptBuilder → OpenAIChatGenerator), each recorded and then replayed with the origin process killed:

$ orca replay last
info replaying exchanges=1 egress=blocked
info replay.done reused=1/1 exact=1 divergences=0 unmatched=0 exit=0

exact=1 is a byte-for-byte match against a deterministic local origin standing in for a provider, so it is a real comparison rather than a model happening to repeat itself.

I filed the same result as a Show and tell in the main repo — mentioning it here so the overlap is visible rather than discovered.

Type and limits

I filed it under type: Monitoring Tool as the closest existing category — it is really a record/replay debugger, so if you would rather see a different type (or a new one), say the word and I will change it.

The page has an explicit Limits section, because two things here are easy to overstate and one is a genuine gap:

  • blocked egress is model-provider egress, not network isolation — retrievers and custom components still run for real, so it is not a sandbox;
  • a matching replay is not a determinism result, since the model is not re-asked;
  • /v1/embeddings is not captured. I measured this rather than assuming it: embedding traffic is passed through to the live provider and is absent from the recording, so a replay refuses it with a named error instead of serving a wrong vector. A pipeline that embeds at query time cannot be fully replayed today. I would rather say that on the integration page than let someone find out at replay time.

No PyPI package — it is an npm CLI that launches your Python process, so only repo is set, which the README allows. No logo included; happy to add one if you would like.

Disclosure: I maintain it.

@xizhuomengcontin
xizhuomengcontin requested a review from a team as a code owner September 13, 2026 17:26
@vercel

vercel Bot commented Sep 13, 2026

Copy link
Copy Markdown

@xizhuomengcontin is attempting to deploy a commit to the deepset Team on Vercel.

A member of the Team first needs to authorize it.

xizhuomengcontin added a commit to Continuum-AI-Corp/OrcaReplay that referenced this pull request Sep 16, 2026
…ey did not

`haystack_rag.py` runs the ordinary RAG shape — `OpenAIDocumentEmbedder` to build the store,
`OpenAITextEmbedder` on the query, `InMemoryEmbeddingRetriever`, then the generator. Measured with
the origin down: `exact=1 divergences=0 unmatched=0 retrieval=2/2`.

That number is the reason for a second check. Embeddings are not model exchanges, so `exact` says
nothing about them — a replay that served the chat turn and refused both embedding calls would
print the same `exact=1`. Only `retrieval=2/2` distinguishes them, which is why the runner's
`retrieval` assertion is set rather than left off.

It also corrects a claim we were making in public. The OrcaReplay card pending at
deepset-ai/haystack-integrations#602 says "Embedding calls are not captured ... a pipeline that
embeds at query time cannot be fully replayed today". Both embedder components reach the proxy
exactly as the generator does, and both replay from the recording.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The Limits section said embedding calls are not captured and that a pipeline
embedding at query time cannot be fully replayed. That is wrong. The check
written to confirm it disproved it: OpenAIDocumentEmbedder, OpenAITextEmbedder,
InMemoryEmbeddingRetriever and the generator record and replay with the origin
down at exact=1 divergences=0 unmatched=0 retrieval=2/2.

Both embedder components leave api_base_url to the OpenAI client, exactly as the
generator does, so all three reach the proxy the same way.

retrieval=2/2 is quoted rather than exact=1 alone because embeddings are not
model exchanges: a replay that served the chat turn and refused both embedding
calls would print the same exact=1.

Now covered by a CI check in OrcaReplay (test/integrations, haystack-rag), so
the claim fails a build if it stops being true.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant