Çalıştırmalar arası cache

Bir çalıştırma içindeki yeniden kullanım zaten çözülmüş: replay tam olarak bunu yapıyor. Replay'in yapamadığı şey, farklı iki çalıştırma arasında işi paylaşmak — ve tekrarlanan maliyet genelde orada. Aynı RAG sorusunu soran iki çalıştırma aynı metni iki kez gömer; aynı belgeyi özetleyen iki çalıştırma bedelini iki kez öder.

Anahtar çalıştırmadan bağımsızdır (<namespace>:<hash>), yani bir runId altında hesaplanan sonuç başka birinin altında bulunur. Bütün fikir budur: daha hızlı bir journal değil, journal'ın hiç kapatmak için tasarlanmadığı boşluk.

Uzanacağınız fonksiyon getOrCompute: varsa cache'lenmiş değeri döner, yoksa hesaplar, saklar ve döner. İki yarıyı ayrı istediğinizde get ve set vardır; ttlMs ise depolama arka ucu TTL yeteneğini destekliyorsa geçerlidir.

import { createCache } from '@gnldev/cache';

const cache = createCache(storage.cache, 'embeddings', {
  onError: (op, err) => logger.warn({ op, err }, 'cache degraded'),
});

// run A computes it; run B finds it — the key does not carry a runId
const vector = await cache.getOrCompute(
  { text: question },
  () => embed(question),
  { ttlMs: 86_400_000 },
);

Cache bir hızlandırıcıdır, doğruluk kaynağı değil; o yüzden bir store hatası çalıştırmayı düşürmemelidir. Her işlem fırlatmak yerine geriler: başarısız bir get miss olur, başarısız bir set hiçbir şey yapmaz, getOrCompute yine hesaplar ve yine doğru cevabı döner. Hatalar sessizce yutulmaz, onError geri çağırmasıyla bildirilir.

Bu, çalıştırma journal'ı ile belleğin davranışının bilerek tersidir ve fark söylenmeye değer: onlar katıdır, çünkü bir journal yazımını kaybetmek garantiyi kaybetmektir. Bir cache yazımını kaybetmek yalnız zamana mal olur.

Gerçek bir hatayı önleyen küçük bir tasarım ayrıntısı: saklanan değer { v } ile sarılır. Sarmalayıcı olmasa cache'lenmiş bir undefined ile "burada hiçbir şey yok" ayırt edilemezdi ve meşru biçimde undefined olan her sonuç her seferinde yeniden hesaplanırdı.

stats() isabet ve ıskalama sayaçlarını, isabet oranını ve bir anahtar sayısını döner. Bunlar süreç içi sayaçlardır: süreç yeniden başlayınca sıfırlanırlar, çünkü store'un işi değer saklamaktır, saymak değil.

invalidate(key) o tek anahtarı siler. Argümansız invalidate() ise yalnız bu örneğin gördüğü anahtarları siler — CacheStore portu anahtar sıralaması sunmaz, yani buradan bir store'u toptan temizlemenin yolu yoktur. Bu bir flush değildir; sayfada yazıyor çünkü isim aksini düşündürüyor.

cache.stats();
// { hits: 41, misses: 9, hitRate: 0.82, size: 50 }

await cache.invalidate({ text: question });   // one key
await cache.invalidate();                     // only what THIS instance has seen