zeroshot research blog

Fast workflows with code and models in zeroshot

Zeroshot can run fast workflows that combine deterministic code with agents and language models. This case study examines that class of use cases through retrieval: code finds candidate passages, and a decision model assesses their relevance. We evaluate ranking quality and measure latency and model cost.

The retrieval task

Retrieval asks which passages in a document collection help answer a question. BM25 word matching and BGE embeddings find candidates, but a passage can match the topic without supplying useful evidence. We use Jev, a decision model that returns probabilities for the fixed options relevant and irrelevant, to score each question and passage pair. These independent judgments can run concurrently, and the model's low cost makes it practical to assess several candidates for every request.

Building the graph with zeroshot

One zeroshot graph runs the complete request. A script node retrieves eight candidates from a warm local service. One map evaluates all eight concurrently through a native decision node that calls Jev directly. A second script node sorts the relevance probabilities and returns the ranked passages.

One zeroshot graph accepts a question. A script retrieves eight passages from a warm local service. One map evaluates all eight with Jev concurrently. A final script sorts the scores and returns ranked passages. zeroshot graph retrieve candidates assess relevance sort and return passages warm service question + collection eight ranked passages + baseline rankings BM25 + BGE search document routing indexes and weights stay loaded one map, eight concurrent Jev requests script node → HTTP /retrieve HTTP /retrieve + /rank 1 2 3 4 5 6 7 8
Retrieval, relevance assessment and sorting belong to one graph. The local service loads indexes and embedding weights once, then reuses them across requests.

The retrieval node's runtime binding specifies an executable and its arguments:

{
  "retrieve": {
    "kind": "script",
    "command": [
      "python3",
      "script_client.py",
      "--url",
      "http://127.0.0.1:37877/retrieve"
    ]
  }
}
Excerpt from the runtime's nodes map. The local Python and script paths are shortened for readability.

A script node starts the command, sends the step's input as JSON on standard input and reads JSON from standard output. Here, script_client.py forwards that input to the service over HTTP. The service performs BM25, dense retrieval and document routing while keeping indexes and embedding weights loaded across requests.

The decision node declares the relevance instruction and answer options, and its runtime selects jev-1.14.0. Each call receives the question and one passage. Zeroshot passes the resulting probabilities to the sorting script through the graph's typed inputs and outputs.

The benchmark

We tested all 300 SciFact and 323 NFCorpus queries from the official BEIR test splits, plus a 128-query sample from LegalBench-RAG. Each domain's full corpus remained searchable. BM25 word matching and BGE dense embeddings supplied eight candidates per query, combining results from document routing and global search.

The main comparison holds those eight candidates constant and ranks them by hybrid retrieval scores or Jev's relevance probabilities. NDCG@3 rewards placing relevant evidence in the first three positions. The complete graph retrieved its candidates afresh, matching the frozen pools on all 751 queries.

Ranking quality

Jev reranking improved NDCG@3 in each domain. With equal weight for each of the three domains, average NDCG@3 rose from 0.3838 to 0.4416, an absolute improvement of 0.0579. Its paired 95% bootstrap interval was 0.0404 to 0.0765.

NDCG at three for hybrid retrieval and Jev reranking. SciFact: 0.6532 and 0.7399. NFCorpus: 0.3957 and 0.4279. Legal sample: 0.1025 and 0.1571.
Higher is better. The legal sample uses chunk-overlap judgments, while the BEIR datasets use document judgments.

Standalone BM25 scored 0.3496 on the same average, and dense retrieval scored 0.3780. These are local baselines.

Speed and cost

Across 751 queries, the graph made 6,008 Jev relevance decisions. It used 4.64 million input tokens, for an estimated model charge of $0.195. That is about $0.26 per 1,000 queries with eight candidates each, excluding local compute costs.

We measured latency separately on 60 queries, with 20 per domain. The retrieval service kept indexes and embedding weights loaded, and one graph ran at a time on a shared development host.1

The eight concurrent Jev requests completed in 90 ms median and 140 ms at p95, including network and provider time. The complete CLI invocation, including retrieval and sorting, took 607 ms median and 759 ms at p95.

Conclusion

Retrieval is a practical example of a workflow that combines deterministic code with model judgments. Here, that combination improved evidence ranking with a median execution time below one second. A similar graph could select documentation for a support assistant or retrieve evidence from an internal knowledge base.

The approach could also support workflows beyond search. A support workflow could fetch account information through a script, classify the issue with a decision model and ask an agent to draft a response. Document intake could combine code that validates structured fields with a model that interprets free-text entries. Zeroshot lets these operations share one graph, with explicit data flow and concurrent execution where the steps are independent.

Notes

  1. Latency measurements use workspaceCheckpoints: false. Zeroshot enables workspace checkpoints by default. Run logs, outputs and usage remain durable with this setting. ↩
What is zeroshot? →