Skip to content

Implementation / Field notes

Evaluate exact caching before semantic caching

Compare exact and semantic cache reuse on equivalent and deceptively similar questions while checking permission and freshness dependencies.

By DriftRail · Updated

Evaluate exact caching first where request equivalence is explicit, then test whether semantic reuse adds useful hits without changing the required answer. Similar meaning can still conceal differences in negation, dates, products, or account scope.

Start with a high-value false match

The example asks whether an opened item may be returned and whether an unopened item may be returned. A deliberately naive normalizer removes the distinction and produces a semantic collision. It illustrates why a high hit count does not establish correct reuse; it does not model an embedding service.

Compare the strategies on the same sample

  1. Define the equivalence fields: authenticated scope, question, policy or source revision, locale, and relevant model or prompt version.
  2. Measure exact matches and evaluate their answer validity.
  3. Add semantic candidates and review false matches, not just new hits.
  4. Test changed policies, expired entries, private answers, and requests that contain negation or time-sensitive facts.

Account for lookup and correction costs

A semantic search may add latency and operational cost even when it avoids generation. Wrong reuse can add human review, support contacts, or a repeated workflow. Compare cost per accepted answer and total task latency, while keeping correctness requirements fixed.

Choose the smallest justified cache

If exact reuse captures the useful repetition, a semantic layer may not earn its complexity. If semantic reuse helps a well-defined task, retain the evaluation cases that expose its dangerous matches. Both strategies still need permission enforcement, freshness control, and a policy for invalidation.

Run the worked example

Save the synthetic Node.js example and run node evaluate-exact-before-semantic-caching.mjs with Node.js 22 or newer. The assertions check the illustrated records and calculations; they do not test a deployed provider, SDK, or access control. No credentials or network connection are needed.

// Synthetic teaching fixture. No credentials, network calls, or production verification.
import assert from 'node:assert/strict';

const first = 'Can I return an opened item?';
const second = 'Can I return an unopened item?';
const exactEquivalent = first === second;
const naiveKey = text => text.toLowerCase().replace(/unopened|opened/g, 'item-state');
assert.equal(exactEquivalent, false);
assert.equal(naiveKey(first), naiveKey(second));
const reviewedEquivalent = false;
assert.equal(reviewedEquivalent, false);
console.log('A synthetic similarity collision is not evidence of answer equivalence.');

References and further reading

Maintained by DriftRail. AI assisted the October 2026 content and template revision. Examples are illustrative; they are not measured product benchmarks. Suggest a correction.

From understanding to evidence

Observe your AI in production.

Explore event logging, detections, and review workflows in DriftRail.

Open DriftRail ↗Read the documentation →