mirror of https://github.com/diegosouzapw/OmniRoute.git synced 2026-09-21 14:22:14 +03:00

Files

Diego Rodrigues de Sa e Souza 8feea123bb feat(docs): mirror every docs/ page in all 65 locales (#14106 )

* feat(docs): mirror every docs/ page in all 65 locales

Extends the documentation mirrors from the 22-page core set (#13940) to
every Markdown page under docs/: 152 sources x 65 locales = 9,880 mirrors
(6,208 new), language bars rewritten for the full locale list, state
adopted so the blocking drift gate now covers all 152 pages.

run-translation.mjs: an oversized block made only of table rows or list
items (PROVIDER_REFERENCE.md 244-row table, FREE_TIERS.md 71-item list) is
cut at item boundaries and rejoined without a blank line — the single
16-40 KB request outlived the backend socket for verbose scripts. 48
older mirrors whose tables had lost rows were retranslated with --force.

* docs(i18n): refresh mirrors for the sources the base changed since the branch cut

Section-level retranslation of the 29 docs (and README.md) whose source
or mirrors moved on release/v3.8.51 during the run, then state adoption;
the drift gate is green again on the merged tree.

2026-09-18 13:16:46 -03:00

106 KiB

Raw Blame History

Memory System (ਪੰਜਾਬੀ)

🌐 Languages: 🇺🇸 English · 🇪🇹 am · 🇸🇦 ar · 🇦🇿 az · 🇧🇬 bg · 🇧🇩 bn · 🇨🇿 cs · 🇩🇰 da · 🇩🇪 de · 🇬🇷 el · 🇪🇸 es · 🇪🇪 et · 🇮🇷 fa · 🇫🇮 fi · 🇫🇷 fr · 🇮🇪 ga · 🇮🇳 gu · 🇳🇬 ha · 🇮🇱 he · 🇮🇳 hi · 🇭🇷 hr · 🇭🇺 hu · 🇦🇲 hy · 🇮🇩 id · 🇳🇬 ig · 🇮🇹 it · 🇯🇵 ja · 🇬🇪 ka · 🇰🇭 km · 🇮🇳 kn · 🇰🇷 ko · 🇱🇹 lt · 🇱🇻 lv · 🇮🇳 ml · 🇮🇳 mr · 🇲🇾 ms · 🇲🇹 mt · 🇲🇲 my · 🇳🇵 ne · 🇳🇱 nl · 🇳🇴 no · 🇮🇳 or · 🇵🇭 phi · 🇵🇱 pl · 🇵🇹 pt · 🇧🇷 pt-BR · 🇷🇴 ro · 🇷🇺 ru · 🇱🇰 si · 🇸🇰 sk · 🇸🇮 sl · 🇷🇸 sr · 🇸🇪 sv · 🇰🇪 sw · 🇮🇳 ta · 🇮🇳 te · 🇹🇭 th · 🇹🇷 tr · 🇺🇦 uk-UA · 🇵🇰 ur · 🇺🇿 uz · 🇻🇳 vi · 🇳🇬 yo · 🇨🇳 zh-CN · 🇹🇼 zh-TW

ਸੱਚਾਈ ਦਾ ਸਰੋਤ: src/lib/memory/ ਅਤੇ src/app/api/memory/ ਆਖਰੀ ਵਾਰ ਅੱਪਡੇਟ ਕੀਤਾ: 2026-06-28 — v3.8.40 (ਮੂਲ ਰੂਪ ਵਿੱਚ ਬੰਦ + int8 ਕੁਆਂਟਾਈਜ਼ੇਸ਼ਨ ਕੈਚ-ਅੱਪ)

OmniRoute API ਕੁੰਜੀ (ਅਤੇ ਵਿਕਲਪਿਕ ਤੌਰ 'ਤੇ ਸੈਸ਼ਨ id) ਦੇ ਆਧਾਰ 'ਤੇ ਨਿਰੰਤਰ ਗੱਲਬਾਤੀ ਮੈਮੋਰੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਹਲਕੇ regex ਪੈਟਰਨ ਮਿਲਾਨ ਰਾਹੀਂ LLM ਜਵਾਬਾਂ ਵਿੱਚੋਂ ਮੈਮੋਰੀਆਂ ਆਪਣੇ-ਆਪ ਕੱਢੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ ਅਗਲੀਆਂ ਬੇਨਤੀਆਂ ਵਿੱਚ ਇੱਕ ਸ਼ੁਰੂਆਤੀ ਸਿਸਟਮ ਸੁਨੇਹੇ ਵਜੋਂ (ਜਾਂ ਉਨ੍ਹਾਂ ਪ੍ਰਦਾਤਾਵਾਂ ਲਈ ਪਹਿਲੇ ਵਰਤੋਂਕਾਰ ਸੁਨੇਹੇ ਵਜੋਂ ਜੋ ਸਿਸਟਮ ਭੂਮਿਕਾ ਨੂੰ ਅਸਵੀਕਾਰ ਕਰਦੇ ਹਨ) ਮੁੜ ਸ਼ਾਮਲ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।

ਮੈਮੋਰੀ ਮੂਲ ਰੂਪ ਵਿੱਚ ਬੰਦ ਹੈ (v3.8.30+ ਤੋਂ)। DEFAULT_MEMORY_SETTINGS.enabled ਹੁਣ false ਹੈ (src/lib/memory/settings.ts)। ਮੈਮੋਰੀ ਸਮਰੱਥ ਕਰਨ ਨਾਲ ਪ੍ਰਾਪਤ ਕੀਤੇ ਸੰਦਰਭ ਦੇ maxTokens (~2k) ਤੱਕ ਹਰੇਕ ਚੈਟ ਬੇਨਤੀ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਜਿਸਦਾ ਬਿਲ ਲੱਗਦਾ ਹੈ — ਇਹ ਨਵੀਆਂ ਇੰਸਟਾਲੇਸ਼ਨਾਂ ਅਤੇ ਆਪਣਾ ਸੰਦਰਭ ਖੁਦ ਸੰਭਾਲਣ ਵਾਲੇ ਕਲਾਇੰਟਾਂ ਲਈ ਇੱਕ ਅਣਕਿਆਸੀ ਲਾਗਤ ਹੋ ਸਕਦੀ ਹੈ। Settings → Memory ਹੇਠ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਚੋਣ ਕਰੋ (ਮੈਮੋਰੀ ਸਮਰੱਥ ਹੋਣ 'ਤੇ MemorySkillsTab ਟੋਕਨ-ਲਾਗਤ ਦੀ ਚੇਤਾਵਨੀ ਵਾਲਾ ਕਾਲਆਉਟ ਦਿਖਾਉਂਦਾ ਹੈ)। ਕਲਾਇੰਟ x-omniroute-no-memory ਬੇਨਤੀ ਹੈਡਰ (true/1/yes) ਨਾਲ ਕਿਸੇ ਇੱਕ ਬੇਨਤੀ ਨੂੰ ਇਸ ਤੋਂ ਬਾਹਰ ਰੱਖ ਸਕਦਾ ਹੈ — API_REFERENCE.md ਵਿੱਚ ਬੇਨਤੀ-ਹੈਡਰ ਸਾਰਣੀ ਵੇਖੋ। ਮੈਮੋਰੀ-ਰਹਿਤ ਬੇਨਤੀ memoryOwnerId = null ਸੈੱਟ ਕਰਦੀ ਹੈ, ਜੋ ਉਸ ਬੇਨਤੀ ਲਈ ਮੈਮੋਰੀ ਅਤੇ ਸਕਿੱਲ ਇੰਜੈਕਸ਼ਨ ਦੋਵਾਂ ਨੂੰ ਅਸਮਰੱਥ ਕਰ ਦਿੰਦੀ ਹੈ (open-sse/handlers/chatCore/headers.ts::isNoMemoryRequested)।

ਮੈਮੋਰੀ ਹਰੇਕ API ਕੁੰਜੀ ਮੁਤਾਬਕ ਸੀਮਿਤ ਹੈ, ਹਰੇਕ ਵਰਤੋਂਕਾਰ ਮੁਤਾਬਕ ਨਹੀਂ — ਇੱਕੋ API ਕੁੰਜੀ ਨਾਲ ਪ੍ਰਮਾਣਿਤ ਹਰੇਕ ਬੇਨਤੀ ਇੱਕੋ ਮੈਮੋਰੀ ਪੂਲ ਸਾਂਝਾ ਕਰਦੀ ਹੈ, ਜਿਸਨੂੰ ਵਿਕਲਪਿਕ ਤੌਰ 'ਤੇ sessionId ਰਾਹੀਂ ਹੋਰ ਸੀਮਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਆਰਕੀਟੈਕਚਰ

ਕਲਾਇੰਟ → /v1/chat/completions (apiKeyInfo ਨੂੰ ਅੱਪਸਟ੍ਰੀਮ ਵਿੱਚ ਹੱਲ ਕੀਤਾ ਗਿਆ)
  → handleChatCore() [open-sse/handlers/chatCore.ts]
    → resolveMemoryOwnerId(apiKeyInfo)        # id ਕੱਢਦਾ ਹੈ
    → getMemorySettings()                     # ਕੈਸ਼ ਕੀਤੀਆਂ ਸੈਟਿੰਗਾਂ
    → shouldInjectMemory(body, {enabled})     # ਗੇਟ
    → retrieveMemories(apiKeyId, config)      # SQL + FTS5 + ਵਿਕਲਪਿਕ ਵੈਕਟਰ
    → injectMemory(body, memories, provider)  # ਸਿਸਟਮ ਜਾਂ ਵਰਤੋਂਕਾਰ ਸੁਨੇਹਾ
  → ਅੱਪਸਟ੍ਰੀਮ ਪ੍ਰਦਾਤਾ ਕਾਲ
  → ਜਵਾਬ ਮਿਲਣ 'ਤੇ: extractFacts(text, apiKeyId, sessionId)  # ਗੈਰ-ਬਲਾਕਿੰਗ
    → setImmediate → createMemory(fact) ਹਰੇਕ ਮਿਲਾਨ ਲਈ
                   → embed(content) + upsertVector(id, vec)

ਇੰਜੈਕਸ਼ਨ ਅਤੇ ਐਕਸਟ੍ਰੈਕਸ਼ਨ ਕਾਲ-ਸਾਈਟਾਂ ਨੂੰ open-sse/handlers/chatCore.ts ਵਿੱਚ ਜੋੜਿਆ ਗਿਆ ਹੈ (retrieveMemories, injectMemory, ਅਤੇ extractFacts ਲੱਭੋ)।

ਇੰਜਣ ਆਰਕੀਟੈਕਚਰ (3-ਪੱਧਰੀ ਰਿਜ਼ੋਲਿਊਸ਼ਨ)

ਮੈਮੋਰੀ ਇੰਜਣ ਉਪਲਬਧ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਅਤੇ ਸੈਟਿੰਗਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਰਨਟਾਈਮ ਦੌਰਾਨ ਪ੍ਰਾਪਤੀ ਮਾਰਗ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ। ਤਿੰਨ ਪੱਧਰ ਮੌਜੂਦ ਹਨ, ਜਿਨ੍ਹਾਂ ਨੂੰ ਤਰਜੀਹ ਦੇ ਕ੍ਰਮ ਵਿੱਚ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ:

  ┌─────────────────────────────────────────────────────────────┐
  │  ਪੱਧਰ 0 — ਕੀਵਰਡ (FTS5)                                     │
  │  ਪ੍ਰੋਬ-ਆਧਾਰਿਤ ਉਪਲਬਧਤਾ: ਜਦੋਂ SQLite ਬਿਲਡ ਇਸਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ │
  │  ਤਾਂ FTS5 (better-sqlite3 / node:sqlite / bun:sqlite);       │
  │  FTS5-ਰਹਿਤ ਬਿਲਡਾਂ 'ਤੇ ਅਣਉਪਲਬਧ (ਉਦਾਹਰਨ: sql.js/WASM —       │
  │  "no such module: fts5")। strategy = "exact" ਹੋਣ 'ਤੇ ਜਾਂ     │
  │  ਫਾਲਬੈਕ ਵਜੋਂ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ; engine-status keyword ਪ੍ਰੋਬ ਨੂੰ │
  │  ਦਰਸਾਉਂਦਾ ਹੈ।                                               │
  └──────────────────────────────────┬──────────────────────────┘
                                     │ strategy = semantic|hybrid?
                                     ▼
  ┌─────────────────────────────────────────────────────────────┐
  │  ਪੱਧਰ 1 — ਐਮਬੈਡਡ ਵੈਕਟਰ (sqlite-vec)                         │
  │  sqlite-vec v0.1.9 ਨੂੰ db.loadExtension() ਰਾਹੀਂ ਲੋਡ ਕੀਤਾ।   │
  │  Float32 ਵੈਕਟਰਾਂ ਉੱਤੇ KNN ਬਰੂਟ-ਫੋਰਸ। ਸਰਗਰਮ ਜਦੋਂ:           │
  │   • sqlite-vec loadExtension ਸਫਲ ਹੁੰਦਾ ਹੈ                    │
  │   • ਇੱਕ ਐਮਬੈਡਿੰਗ ਸਰੋਤ ਉਪਲਬਧ ਹੈ (remote | static |           │
  │     transformers) ਜੋ Float32Array ਤਿਆਰ ਕਰ ਸਕਦਾ ਹੈ            │
  │   • vec_memories ਸਾਰਣੀ ਮੌਜੂਦ ਹੈ (ਪਹਿਲੇ ready() 'ਤੇ ਬਣਦੀ ਹੈ) │
  └──────────────────────────────────┬──────────────────────────┘
                                     │ qdrant.enabled?
                                     ▼
  ┌─────────────────────────────────────────────────────────────┐
  │  ਪੱਧਰ 2 — Qdrant (ਚੋਣਵਾਂ ਬਾਹਰੀ ਵੈਕਟਰ ਡਾਟਾਬੇਸ)              │
  │  ਸਮਰੱਥ ਹੋਣ 'ਤੇ semantic/hybrid ਲਈ sqlite-vec ਦੀ ਥਾਂ ਲੈਂਦਾ ਹੈ।│
  │  ਚੱਲ ਰਹੀ Qdrant ਇੰਸਟੈਂਸ + ਸੰਰਚਿਤ host/port ਦੀ ਲੋੜ ਹੈ।       │
  └─────────────────────────────────────────────────────────────┘

ਪੱਧਰ-ਘਟਾਅ ਆਪਣੇ-ਆਪ ਅਤੇ ਪਾਰਦਰਸ਼ੀ ਢੰਗ ਨਾਲ ਹੁੰਦਾ ਹੈ:

ਜੇ sqlite-vec ਲੋਡ ਹੋਣ ਵਿੱਚ ਅਸਫਲ ਰਹਿੰਦਾ ਹੈ, ਤਾਂ ਪੱਧਰ 1 ਅਣਉਪਲਬਧ ਹੁੰਦਾ ਹੈ → ਪੱਧਰ 0 'ਤੇ ਵਾਪਸ ਜਾਂਦਾ ਹੈ।
ਜੇ ਐਮਬੈਡਿੰਗ ਸਰੋਤ ਕੋਈ ਗਲਤੀ ਵਾਪਸ ਕਰਦਾ ਹੈ, ਤਾਂ ਪੱਧਰ 1 ਪੱਧਰ 0 'ਤੇ ਵਾਪਸ ਜਾਂਦਾ ਹੈ।
ਜੇ Qdrant ਠੀਕ ਤਰ੍ਹਾਂ ਕੰਮ ਨਹੀਂ ਕਰ ਰਿਹਾ, ਤਾਂ ਪੱਧਰ 2 ਪੱਧਰ 1 'ਤੇ ਵਾਪਸ ਜਾਂਦਾ ਹੈ (ਜਾਂ ਜੇ ਪੱਧਰ 1 ਵੀ ਅਣਉਪਲਬਧ ਹੈ ਤਾਂ ਪੱਧਰ 0 'ਤੇ)।

ਐਮਬੈਡਿੰਗ ਸਰੋਤ

ਐਮਬੈਡਿੰਗ ਲੇਅਰ (src/lib/memory/embedding/) ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ ਕਿ ਕਿਹੜਾ ਸਰੋਤ ਵਰਤਣਾ ਹੈ, ਜੋ MemorySettingsExtended.embeddingSource ਉੱਤੇ ਆਧਾਰਿਤ ਹੁੰਦਾ ਹੈ:

ਸਰੋਤ	ਵੇਰਵਾ	ਕੁੰਜੀ ਲੋੜੀਂਦੀ ਹੈ	ਕੋਲਡ ਸਟਾਰਟ
`remote`	ਕੌਂਫਿਗਰ ਕੀਤੇ ਪ੍ਰਦਾਤਾ ਦੀ ਐਮਬੈਡਿੰਗ API (OpenAI, Cohere, ਆਦਿ) ਵਰਤਦਾ ਹੈ	ਹਾਂ	ਕੋਈ ਨਹੀਂ
`static`	`potion-base-8M` ਰਾਹੀਂ ਲੋਕਲ ਲੁੱਕਅੱਪ-ਟੇਬਲ ਐਮਬੈਡਿੰਗ (WordPiece + ਮੀਨ ਪੂਲਿੰਗ)	ਨਹੀਂ	~200ms
`transformers`	`@huggingface/transformers` v4, `all-MiniLM-L6-v2` ਰਾਹੀਂ ਲੋਕਲ ONNX ਇਨਫਰੈਂਸ	ਨਹੀਂ	~3s + ~400MB RAM
`auto`	ਰਨਟਾਈਮ ਨਿਰਧਾਰਨ: ਰਿਮੋਟ (ਜੇ ਕੁੰਜੀ ਮੌਜੂਦ ਹੋਵੇ) → ਸਟੈਟਿਕ → ਟ੍ਰਾਂਸਫਾਰਮਰਜ਼ → null	ਨਿਰਭਰ ਕਰਦਾ ਹੈ	ਨਿਰਭਰ ਕਰਦਾ ਹੈ

auto ਲਈ ਨਿਰਧਾਰਨ ਕ੍ਰਮ:

listEmbeddingProviders() ਵਿੱਚ hasKey === true ਵਾਲਾ ਪਹਿਲਾ ਪ੍ਰਦਾਤਾ ਲੱਭੋ → remote।
ਜੇ settings.staticEnabled === true ਹੋਵੇ → static।
ਜੇ settings.transformersEnabled === true ਹੋਵੇ → transformers।
ਨਹੀਂ ਤਾਂ → null (FTS5 ਕੀਵਰਡ ਖੋਜ ਤੱਕ ਘਟ ਜਾਂਦਾ ਹੈ)।

ਐਮਬੈਡਿੰਗ ਕੈਸ਼ (src/lib/memory/embedding/cache.ts) ${source}:${model}:${dim}:${sha256(text)} ਦੁਆਰਾ ਕੁੰਜੀਬੱਧ ਇਨ-ਮੈਮਰੀ LRU ਮੈਪ ਵਰਤਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ MEMORY_EMBEDDING_CACHE_MAX ਐਂਟਰੀਆਂ (ਡਿਫਾਲਟ 1000) ਦੀ ਸੀਮਾ ਅਤੇ MEMORY_EMBEDDING_CACHE_TTL_MS (ਡਿਫਾਲਟ 5 ਮਿੰਟ) ਦਾ TTL ਹੁੰਦਾ ਹੈ। ਹਰ ਪ੍ਰੋਸੈੱਸ ਜੀਵਨ-ਚੱਕਰ ਦੌਰਾਨ ਇਹ ਸਾਰੇ ਕਾਲਰਾਂ ਵਿਚਕਾਰ ਸਾਂਝਾ ਹੁੰਦਾ ਹੈ।

ਹਾਈਬ੍ਰਿਡ RRF (k=60)

ਜਦੋਂ strategy = "hybrid" ਹੋਵੇ ਅਤੇ ਵੈਕਟਰ ਸਟੋਰ ਉਪਲਬਧ ਹੋਵੇ, ਤਾਂ ਪ੍ਰਾਪਤੀ FTS5 ਅਤੇ ਵੈਕਟਰ ਨਤੀਜਿਆਂ ਨੂੰ ਮਿਲਾਉਣ ਲਈ Reciprocal Rank Fusion ਵਰਤਦੀ ਹੈ:

RRF(d) = Σ  1 / (k + rank_i(d))      ਜਿੱਥੇ k = 60 (MEMORY_RRF_K ਰਾਹੀਂ ਕੌਂਫਿਗਰ ਕਰਨ ਯੋਗ)
          i

ਖਾਸ ਤੌਰ 'ਤੇ:

FTS5 ਖੋਜ ਚਲਾਓ → ਰੈਂਕ ਕੀਤੀ ਸੂਚੀ R_fts (ਸਥਿਤੀ 1..N)।
KNN ਵੈਕਟਰ ਖੋਜ ਚਲਾਓ → ਰੈਂਕ ਕੀਤੀ ਸੂਚੀ R_vec (ਸਥਿਤੀ 1..M)।
ਹਰ ਵਿਲੱਖਣ memoryId ਲਈ:
rrf_score = 1/(60 + fts_rank) + 1/(60 + vec_rank) (ਜੇ ਸੂਚੀ ਵਿੱਚ ਨਾ ਹੋਵੇ ਤਾਂ 0)।
rrf_score ਅਨੁਸਾਰ ਘਟਦੇ ਕ੍ਰਮ ਵਿੱਚ ਕ੍ਰਮਬੱਧ ਕਰੋ, ਫਿਰ ਟੋਕਨ ਬਜਟ ਵਾਕ ਲਾਗੂ ਕਰੋ।

RRF ਨੂੰ ਵਿਭਿੰਨ ਪ੍ਰਾਪਤੀ ਸਿਸਟਮਾਂ ਵਿੱਚ ਸਕੋਰ ਨਾਰਮਲਾਈਜ਼ੇਸ਼ਨ ਦੀ ਲੋੜ ਤੋਂ ਬਿਨਾਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੋਣ ਲਈ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ। ਡਿਫਾਲਟ k=60 ਮੂਲ Cormack ਆਦਿ ਦੇ ਪੇਪਰ ਤੋਂ ਲਿਆ ਗਿਆ ਹੈ ਅਤੇ ਛੋਟੇ ਕਾਰਪਸਾਂ (<10k ਮੈਮੋਰੀਆਂ) ਲਈ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ।

ਬੈਕਫ਼ਿਲ (ਲੇਜ਼ੀ + ਰੀਇੰਡੈਕਸ)

ਜਦੋਂ ਐਮਬੈਡਿੰਗ ਮਾਡਲ ਬਦਲਦਾ ਹੈ (embedding_signature ਰਾਹੀਂ ਪਤਾ ਲਗਾਇਆ ਜਾਂਦਾ ਹੈ), ਤਾਂ ਵੈਕਟਰ ਸਟੋਰ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਸਾਰੀਆਂ ਮੌਜੂਦਾ ਮੈਮੋਰੀਆਂ ਨੂੰ memories ਟੇਬਲ ਵਿੱਚ needs_reindex = 1 ਵਜੋਂ ਚਿੰਨ੍ਹਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਲੇਜ਼ੀ ਬੈਕਫ਼ਿਲ: ਅਗਲੀ ਪ੍ਰਾਪਤੀ ਦੌਰਾਨ, ਜਿਸ ਵੀ ਮੈਮੋਰੀ ਦੀ ਵੈਕਟਰ ਐਂਟਰੀ ਮੌਜੂਦ ਨਹੀਂ ਹੁੰਦੀ, ਉਸ ਨੂੰ ਖੋਜ ਚੱਲਣ ਤੋਂ ਪਹਿਲਾਂ ਐਮਬੈਡ ਕਰਕੇ vec_memories ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਸਟਾਰਟਅੱਪ ਨੂੰ ਬਲੌਕ ਕੀਤੇ ਬਿਨਾਂ ਅਸਲ ਬੇਨਤੀਆਂ ਵਿੱਚ ਬੈਕਫ਼ਿਲ ਦੀ ਲਾਗਤ ਨੂੰ ਵੰਡ ਦਿੰਦਾ ਹੈ।

ਸਪਸ਼ਟ ਰੀਇੰਡੈਕਸ: /dashboard/memory ਵਿੱਚ Engine ਟੈਬ ਇੱਕ "ਹੁਣੇ ਰੀਇੰਡੈਕਸ ਕਰੋ" ਬਟਨ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ, ਜੋ POST /api/memory/reindex ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ। ਹੈਂਡਲਰ src/lib/memory/reindex.ts ਤੋਂ runReindexBatch() ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ, ਜੋ ਹਰ ਬੇਨਤੀ ਵਿੱਚ ਵੱਧ ਤੋਂ ਵੱਧ limit ਲੰਬਿਤ ਐਂਟਰੀਆਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਦਾ ਹੈ। ਪ੍ਰਗਤੀ ਨੂੰ GET /api/memory/engine-status (vectorStore.needsReindex) ਰਾਹੀਂ ਪੋਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

memory_vec_meta ਟੇਬਲ (ਮਾਈਗ੍ਰੇਸ਼ਨ 083_memory_vec.sql) ਇਹ ਸਟੋਰ ਕਰਦੀ ਹੈ:

active_dim — ਮੌਜੂਦਾ ਵੈਕਟਰ ਡਾਇਮੈਂਸ਼ਨ (null = ਅਜੇ ਕੈਲੀਬਰੇਟ ਨਹੀਂ ਕੀਤਾ ਗਿਆ)।
embedding_signature — ਬਦਲਾਅ ਪਛਾਣਨ ਲਈ ਵਰਤਿਆ ਜਾਣ ਵਾਲਾ ${source}:${model}:${dim}।
last_reset_at — ਪਿਛਲੇ ਪੂਰੇ ਰੀਸੈੱਟ ਦਾ ਟਾਈਮਸਟੈਂਪ।
vec_loaded — 0/1 ਫਲੈਗ ਕਿ sqlite-vec ਸਫਲਤਾਪੂਰਵਕ ਲੋਡ ਹੋਇਆ ਸੀ ਜਾਂ ਨਹੀਂ।

ਸੈਟਿੰਗਾਂ ਦਾ ਵਿਸਤਾਰ

MemorySettingsExtended ਵਿੱਚ ਨੌਂ embedding ਅਤੇ vector ਫੀਲਡ ਉਪਲਬਧ ਹਨ, ਜੋ src/shared/schemas/memory.ts ਵਿੱਚ ਹਨ ਅਤੇ src/lib/db/settings.ts ਰਾਹੀਂ ਸਥਾਈ ਤੌਰ 'ਤੇ ਸੰਭਾਲੇ ਜਾਂਦੇ ਹਨ:

ਫੀਲਡ	ਕਿਸਮ	ਡਿਫਾਲਟ	ਵੇਰਵਾ
`embeddingSource`	`"remote" \| "static" \| "transformers" \| "auto"`	`"auto"`	ਵਰਤਿਆ ਜਾਣ ਵਾਲਾ embedding ਸਰੋਤ
`embeddingProviderModel`	`string \| null`	`null`	`provider/model` ਫਾਰਮੈਟ ਵਿੱਚ ਪ੍ਰਦਾਤਾ/ਮਾਡਲ
`customBaseUrl`	`string \| null`	`null`	ਸਿਰਫ਼ Memory ਲਈ OpenAI-ਅਨੁਕੂਲ endpoint ਦਾ ਬੇਸ URL
`customModelId`	`string \| null`	`null`	ਕਸਟਮ endpoint ਨੂੰ ਭੇਜੀ ਜਾਣ ਵਾਲੀ ਮਾਡਲ ID
`transformersEnabled`	`boolean`	`false`	Transformers.js (MiniLM, ~400MB) ਲਈ ਚੋਣਵੀਂ ਸਹਿਮਤੀ
`staticEnabled`	`boolean`	`false`	static potion-base-8M ਲੋਕਲ ਮਾਡਲ ਲਈ ਚੋਣਵੀਂ ਸਹਿਮਤੀ
`rerankEnabled`	`boolean`	`false`	ਮੁੜ-ਰੈਂਕਿੰਗ ਪੜਾਅ ਸਮਰੱਥ ਕਰੋ (ਹਰ ਬੇਨਤੀ ਵਿੱਚ +200-500ms ਜੋੜਦਾ ਹੈ)
`rerankProviderModel`	`string \| null`	`null`	`provider/model` ਫਾਰਮੈਟ ਵਿੱਚ ਮੁੜ-ਰੈਂਕ ਪ੍ਰਦਾਤਾ/ਮਾਡਲ
`vectorStore`	`"sqlite-vec" \| "qdrant" \| "auto"`	`"auto"`	ਵਰਤਿਆ ਜਾਣ ਵਾਲਾ vector backend

ਇਨ੍ਹਾਂ ਨੂੰ GET /PUT /api/settings/memory (ਸਕੀਮਾ MemorySettingsExtendedSchema) ਰਾਹੀਂ ਉਪਲਬਧ ਕਰਵਾਇਆ ਗਿਆ ਹੈ।

remote ਸਰੋਤ ਲਈ, Memory ਚੋਣਵੀਆਂ customBaseUrl ਅਤੇ customModelId ਸੈਟਿੰਗਾਂ ਵੀ ਸਵੀਕਾਰ ਕਰਦੀ ਹੈ। ਇਕੱਠਿਆਂ ਇਹ ਗਲੋਬਲ embedding ਰਜਿਸਟਰੀ ਨੂੰ ਬਦਲੇ ਬਿਨਾਂ ਇੱਕ OpenAI-ਅਨੁਕੂਲ /embeddings endpoint ਅਤੇ ਮਾਡਲ ਚੁਣਦੀਆਂ ਹਨ। ਵਰਤੋਂ ਤੋਂ ਪਹਿਲਾਂ endpoint ਨੂੰ ਸਧਾਰਣ ਰੂਪ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਪ੍ਰਦਾਤਾ ਦੀ outbound URL ਨੀਤੀ ਦੁਆਰਾ ਜਾਂਚਿਆ ਜਾਂਦਾ ਹੈ: HTTP(S) ਲਾਜ਼ਮੀ ਹੈ, ਸ਼ਾਮਲ ਕੀਤੇ credentials ਅਤੇ query strings ਰੱਦ ਕਰ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ cloud-metadata ਪਤੇ ਬਲਾਕ ਰਹਿੰਦੇ ਹਨ। ਖਾਲੀ ਮੁੱਲ ਚੁਣੇ ਹੋਏ ਰਜਿਸਟਰੀ ਪ੍ਰਦਾਤਾ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਦੇ ਹਨ। ਡੈਸ਼ਬੋਰਡ ਨੂੰ ਵਾਪਸ ਕੀਤੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ ਅਤੇ endpoint credentials ਨੂੰ ਕਦੇ ਵੀ ਲੌਗ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ।

TODO (D20): global ਸਕੋਪ (ਸਾਰੀਆਂ API keys ਵਿੱਚ memories ਸਾਂਝੀਆਂ ਕਰਨਾ) ਇਸ ਰਿਲੀਜ਼ ਵਿੱਚ ਲਾਗੂ ਨਹੀਂ ਕੀਤਾ ਗਿਆ। ਇਸ ਲਈ ਸਕੀਮਾ ਬਦਲਾਅ ਅਤੇ ਇੱਕ ਗਲੋਬਲ retrieval ਪਾਥ ਦੀ ਲੋੜ ਹੈ। ਇਸਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਟਰੈਕ ਕਰੋ।

ਸਟੋਰੇਜ ਪਰਤਾਂ

ਮੁੱਖ: SQLite (`memories` ਟੇਬਲ)

ਮਾਈਗ੍ਰੇਸ਼ਨ 015_create_memories.sql ਦੁਆਰਾ ਬਣਾਈ ਗਈ:

ਕਾਲਮ	ਕਿਸਮ	ਨੋਟਸ
`id`	`TEXT PRIMARY KEY`	`crypto.randomUUID()` ਰਾਹੀਂ ਬਣਾਇਆ UUID
`api_key_id`	`TEXT NOT NULL`	ਮਾਲਕੀ ਵਾਲੀ API key
`session_id`	`TEXT`	ਪ੍ਰਤੀ-conversation ਚੋਣਵਾਂ ਸਕੋਪ
`type`	`TEXT NOT NULL`	`factual`, `episodic`, `procedural`, `semantic` ਵਿੱਚੋਂ ਇੱਕ
`key`	`TEXT`	ਸਥਿਰ upsert key, ਜਿਵੇਂ `preference:i_prefer_python`
`content`	`TEXT NOT NULL`	ਅਸਲ ਤੱਥ ਦਾ ਟੈਕਸਟ
`metadata`	`TEXT`	JSON blob (ਸ਼੍ਰੇਣੀ, ਕੱਢਣ ਦਾ ਸਮਾਂ, ਸਰੋਤ, ...)
`created_at` / `updated_at`	`TEXT`	ISO 8601 strings
`expires_at`	`TEXT`	ਚੋਣਵੀਂ ਮਿਆਦ; `NULL` ਦਾ ਅਰਥ ਸਥਾਈ ਹੈ
`memory_id`	`INTEGER UNIQUE`	UUIDs ↔ FTS5 rowids ਨੂੰ ਜੋੜਨ ਲਈ `023_fix_memory_fts_uuid.sql` ਦੁਆਰਾ ਸ਼ਾਮਲ ਕੀਤਾ ਗਿਆ

ਇੰਡੈਕਸ: api_key_id, session_id, type, expires_at, ਅਤੇ ਵਿਲੱਖਣ memory_id ਇੰਡੈਕਸ।

Upsert ਅਰਥ-ਵਿਹਾਰ: createMemory() ਸਮਾਨ (api_key_id, key) ਵਾਲੀ ਮੌਜੂਦਾ row ਲੱਭਦਾ ਹੈ ਅਤੇ ਮਿਲਣ 'ਤੇ ਉਸੇ ਥਾਂ ਉਸਨੂੰ ਅੱਪਡੇਟ ਕਰਦਾ ਹੈ (metadata ਨੂੰ shallow spread ਰਾਹੀਂ ਮਿਲਾਉਂਦੇ ਹੋਏ)। ਇਹ ਦੁਹਰਾਏ ਗਏ ਤਰਜੀਹ ਬਿਆਨਾਂ ਕਾਰਨ ਟੇਬਲ ਨੂੰ ਬੇਹੱਦ ਵਧਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।

ਪੂਰੇ-ਟੈਕਸਟ ਦੀ ਖੋਜ (`memory_fts` virtual table)

022_add_memory_fts5.sql, content ਅਤੇ key ਉੱਤੇ ਇੱਕ FTS5 virtual table ਬਣਾਉਂਦੀ ਹੈ। 023_fix_memory_fts_uuid.sql ਇੱਕ ਅਸਲ ਵਰਤੋਂ ਵਾਲੇ ਬੱਗ ਨੂੰ ਠੀਕ ਕਰਦੀ ਹੈ, ਜਿਸ ਵਿੱਚ UUID primary key, FTS5 ਦੇ integer rowid ਨਾਲ join ਨਹੀਂ ਹੁੰਦੀ ਸੀ — ਮਾਈਗ੍ਰੇਸ਼ਨ memory_id ਕਾਲਮ ਜੋੜਦੀ ਹੈ, FTS table ਨੂੰ ਮੁੜ ਬਣਾਉਂਦੀ ਹੈ, ਅਤੇ triggers (memory_fts_ai, memory_fts_ad, memory_fts_au) ਜੋੜਦੀ ਹੈ ਜੋ INSERT, DELETE ਅਤੇ UPDATE ਉੱਤੇ FTS ਨੂੰ sync ਵਿੱਚ ਰੱਖਦੇ ਹਨ।

semantic ਅਤੇ hybrid ਰਣਨੀਤੀਆਂ ਲਈ retrieval.ts ਦੁਆਰਾ ਵਰਤੀ ਜਾਂਦੀ ਹੈ (ਹੇਠਾਂ ਵੇਖੋ)। retrieval ਕੋਡ hasTable("memory_fts") ਨਾਲ ਸੁਰੱਖਿਆ ਜਾਂਚ ਕਰਦਾ ਹੈ ਅਤੇ ਜੇ FTS table ਮੌਜੂਦ ਨਾ ਹੋਵੇ ਜਾਂ FTS query ਵਿੱਚ ਗਲਤੀ ਆਵੇ ਤਾਂ ਕਾਲਕ੍ਰਮਿਕ ਕ੍ਰਮ ਉੱਤੇ ਵਾਪਸ ਚਲਾ ਜਾਂਦਾ ਹੈ।

ਚੋਣਵਾਂ: Qdrant (vector store tier 2)

src/lib/memory/qdrant.ts tier 2 vector store ਵਜੋਂ ਇੱਕ ਚੋਣਵਾਂ Qdrant ਏਕੀਕਰਨ ਲਾਗੂ ਕਰਦੀ ਹੈ। Retrieval ਕੇਵਲ ਉਦੋਂ ਹੀ Qdrant ਵੱਲ route ਹੁੰਦੀ ਹੈ ਜਦੋਂ engine selector memoryVectorStore === "qdrant" ਹੋਵੇ — ਡਿਫਾਲਟ "auto" (ਅਤੇ "sqlite-vec") Qdrant ਨੂੰ ਕਦੇ ਵੀ ਨਹੀਂ ਚੁਣਦੇ। Engine-tab toggle ਦੋਵੇਂ qdrantEnabled ਅਤੇ memoryVectorStore ਨੂੰ ਇਕੱਠੇ ਸੈੱਟ ਕਰਦਾ ਹੈ: ਸਮਰੱਥ ਕਰਨ ਨਾਲ Qdrant ਮੁੱਖ store ਬਣ ਜਾਂਦਾ ਹੈ, ਜਦਕਿ ਅਸਮਰੱਥ ਕਰਨ ਨਾਲ ਇਹ "auto" 'ਤੇ ਰੀਸੈੱਟ ਹੋ ਜਾਂਦਾ ਹੈ (#5597 — ਉਸ ਸੁਧਾਰ ਤੋਂ ਪਹਿਲਾਂ, ਸਮਰੱਥ ਕਰਨਾ ਬੇਅਸਰ ਸੀ ਕਿਉਂਕਿ ਕੁਝ ਵੀ engine selector ਨੂੰ ਲਿਖਦਾ ਨਹੀਂ ਸੀ)। ਜੇ Qdrant ਤੱਕ ਪਹੁੰਚ ਨਾ ਹੋਵੇ ਜਾਂ ਉਹ ਕੁਝ ਵਾਪਸ ਨਾ ਕਰੇ, ਤਾਂ retrieval sqlite-vec → FTS5 ਉੱਤੇ ਵਾਪਸ ਚਲੀ ਜਾਂਦੀ ਹੈ।

upsertSemanticMemoryPoint() — ਸੰਰਚਿਤ embedding ਮਾਡਲ ਨਾਲ key + content ਨੂੰ embed ਕਰਦਾ ਹੈ, ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ collection ਮੌਜੂਦ ਹੋਵੇ (ਪਹਿਲੀ ਵਰਤੋਂ ਦੌਰਾਨ cosine-distance vectors ਬਣਾਉਂਦਾ ਹੈ), ਅਤੇ payload {memoryId, apiKeyId, sessionId, key, content, metadata, createdAtUnix, expiresAtUnix} ਨਾਲ ਇੱਕ point ਨੂੰ upsert ਕਰਦਾ ਹੈ।
searchSemanticMemory(query, topK, scope) — query ਨੂੰ embed ਕਰਦਾ ਹੈ, kind = "omniroute_memory" ਮੁਤਾਬਕ filter ਕੀਤੀ collection ਵਿੱਚ ਖੋਜ ਕਰਦਾ ਹੈ ਅਤੇ ਵਿਕਲਪਿਕ ਤੌਰ 'ਤੇ apiKeyId / sessionId ਮੁਤਾਬਕ ਵੀ filter ਕਰਦਾ ਹੈ। topK ਨੂੰ [1, 20] ਤੱਕ ਸੀਮਿਤ ਕਰਦਾ ਹੈ।
deleteSemanticMemoryPoint(id) — ਇੱਕ point ਨੂੰ ਮਿਟਾਉਂਦਾ ਹੈ। SQLite row ਹਟਾਏ ਜਾਣ ਤੋਂ ਬਾਅਦ deleteMemory() ਦੁਆਰਾ ਕਾਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (D15)।
cleanupSemanticMemoryPoints({retentionDays}) — ਉਹ points ਇਕੱਠੇ ਮਿਟਾਉਂਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦਾ expiresAtUnix ਬੀਤੇ ਸਮੇਂ ਵਿੱਚ ਹੈ ਜਾਂ ਜਿਨ੍ਹਾਂ ਦਾ createdAtUnix, retention cutoff ਤੋਂ ਪੁਰਾਣਾ ਹੈ। ਪਹਿਲਾਂ ਗਿਣਤੀ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ dashboard ਅਸਲ ਸੰਖਿਆਵਾਂ ਦਿਖਾ ਸਕੇ।
checkQdrantHealth() — latency ਸਮੇਤ GET /readyz health probe।

settings UI, /dashboard/memory ਦੀ Engine tab ਵਿੱਚ Qdrant config, health check, semantic search test, ਅਤੇ cleanup ਉਪਲਬਧ ਕਰਵਾਉਂਦੀ ਹੈ। src/app/api/settings/qdrant/ ਅਧੀਨ ਸੰਬੰਧਿਤ routes, v3.8.6 ਤੋਂ ਸਾਰੇ wired ਹਨ:

Route	ਵਿਧੀ	ਵੇਰਵਾ
`/api/settings/qdrant`	`GET` / `PUT`	Qdrant settings ਪੜ੍ਹੋ / ਅੱਪਡੇਟ ਕਰੋ
`/api/settings/qdrant/health`	`GET`	Liveness probe + latency
`/api/settings/qdrant/search`	`POST`	Semantic search test
`/api/settings/qdrant/cleanup`	`POST`	ਮਿਆਦ ਪੁੱਗੇ / ਪੁਰਾਣੇ points ਹਟਾਓ
`/api/settings/qdrant/embedding-models`	`GET`	ਉਪਲਬਧ embedding models ਦੀ ਸੂਚੀ

ਵਿਹਾਰ ਸੰਬੰਧੀ ਨੋਟਸ (ਕੀ ਉਮੀਦ ਕਰਨੀ ਹੈ):

Engine ਚੋਣ — Engine tab ਵਿੱਚ Qdrant ਨੂੰ ਸਮਰੱਥ ਕਰਨ ਨਾਲ ਇਹ ਮੁੱਖ store ਬਣ ਜਾਂਦਾ ਹੈ (memoryVectorStore="qdrant" ਸੈੱਟ ਕਰਦਾ ਹੈ); ਅਸਮਰੱਥ ਕਰਨ ਨਾਲ ਇਹ "auto" 'ਤੇ reset ਹੋ ਜਾਂਦਾ ਹੈ (#5597)।
ਕੋਈ back-fill ਨਹੀਂ — Qdrant ਸਮਰੱਥ ਹੋਣ ਤੋਂ ਬਾਅਦ ਬਣਾਈਆਂ/ਅੱਪਡੇਟ ਕੀਤੀਆਂ memories ਹੀ ਇਸ ਵਿੱਚ ਲਿਖੀਆਂ ਜਾਂਦੀਆਂ ਹਨ (fire-and-forget dual-write)। ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ SQLite memories ਨੂੰ migrate ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ; "Reindex Now" ਸਿਰਫ਼ sqlite-vec index ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਂਦਾ ਹੈ, Qdrant ਨੂੰ ਨਹੀਂ।
Vector dimension ਆਪਣੇ ਆਪ ਪਛਾਣਿਆ ਜਾਂਦਾ ਹੈ — ਪਹਿਲੀ ਵਰਤੋਂ ਦੌਰਾਨ ਅਸਲ embedding ਤੋਂ; ਭਰਨ ਲਈ ਕੋਈ dimension field ਨਹੀਂ ਹੈ। Collection ਮੌਜੂਦ ਹੋਣ ਤੋਂ ਬਾਅਦ embedding ਮਾਡਲ ਬਦਲਣਾ ਆਪਣੇ ਆਪ ਨਹੀਂ ਸੰਭਾਲਿਆ ਜਾਂਦਾ: ਮੌਜੂਦਾ collection ਨੂੰ ਬਿਨਾਂ ਬਦਲੇ ਛੱਡ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, dimension- mismatched writes/searches ਅਸਫਲ ਹੋ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ sqlite-vec 'ਤੇ fallback ਕਰਦੀਆਂ ਹਨ। Embedder ਬਦਲਣ ਲਈ collection ਨੂੰ ਮੁੜ ਬਣਾਓ (ਨਵਾਂ ਨਾਮ, ਜਾਂ Qdrant ਵਿੱਚ ਇਸ ਨੂੰ ਮਿਟਾਓ)।
Distance metric — ਹਮੇਸ਼ਾ Cosine (collection ਬਣਾਉਣ ਵੇਲੇ hardcoded; ਸੰਰਚਿਤ ਕਰਨ ਯੋਗ ਨਹੀਂ)।
Auth — ਕੇਵਲ API key (api-key header ਵਜੋਂ ਭੇਜੀ ਜਾਂਦੀ ਹੈ; ਬਿਨਾਂ authentication ਵਾਲੇ local Docker ਲਈ ਵਿਕਲਪਿਕ)। JWT/RBAC ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ।
Config fields — UI host, port, collection, embeddingModel, apiKey ਉਪਲਬਧ ਕਰਵਾਉਂਦੀ ਹੈ। vectorSize / hnswEfConstruct ਸਿਰਫ਼ env/DB ਹਨ ਅਤੇ collection ਬਣਾਉਣ ਲਈ vectorSize ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ (dimension embedding ਤੋਂ ਆਉਂਦਾ ਹੈ)।

Vector quantization (int8 — opt-in, ਦੋਵੇਂ backends)

ਦੋਵੇਂ vector backends, ਸਟੋਰ ਕੀਤੇ vectors ਦੀ memory footprint ਘਟਾਉਣ ਲਈ (~Float32 ਨਾਲੋਂ 4× ਛੋਟੀ), recall ਵਿੱਚ ਥੋੜ੍ਹੀ ਕਮੀ ਨਾਲ opt-in int8 quantization ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ। ਦੋਵਾਂ 'ਤੇ default off ਹੈ — ਜਦੋਂ ਤੱਕ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਸਮਰੱਥ ਨਾ ਕੀਤਾ ਜਾਵੇ, vectors full-precision ਹੀ ਰਹਿੰਦੇ ਹਨ।

Backend	Setting	ਕਿਸਮ	Default	ਕਿੱਥੇ ਪੜ੍ਹੀ ਜਾਂਦੀ ਹੈ
Qdrant	`qdrantQuantization` (DB key)	`"none" \| "int8" \| "binary"`	`"none"`	`src/lib/memory/qdrant.ts::normalizeQdrantConfig()`
sqlite-vec	`MEMORY_VEC_QUANTIZATION` (env)	`"none" \| "int8"`	`"none"`	`src/lib/memory/vectorStore.ts::requestedVecQuantization()`

Qdrant ਨੂੰ qdrantQuantization setting key ਰਾਹੀਂ ਹਰੇਕ instance ਲਈ ਸੰਰਚਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (PUT /api/settings/qdrant 'ਤੇ quantization field ਵਜੋਂ ਉਪਲਬਧ)। ਜਦੋਂ "int8" ਹੋਵੇ, buildQuantizationConfig() scalar quantization (always_ram, quantile 0.99) ਦੀ ਬੇਨਤੀ ਕਰਦਾ ਹੈ ਅਤੇ searches rescore: true ਨੂੰ ਸਮਰੱਥ ਕਰਦੀਆਂ ਹਨ ਤਾਂ ਜੋ full-precision vectors, int8 candidate set ਨੂੰ ਸੁਧਾਰ ਸਕਣ।
sqlite-vec quantization ਸਿਰਫ਼ environment-only ਹੈ (DB setting ਨਹੀਂ): local vectors ਨੂੰ int8[dim] column ਵਜੋਂ ਸਟੋਰ ਕਰਨ ਲਈ MEMORY_VEC_QUANTIZATION=int8 ਸੈੱਟ ਕਰੋ, ਜਿਸ ਲਈ vec_quantize_int8(?, 'unit') ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਚੁਣੇ ਹੋਏ mode ਨੂੰ embedding_signature ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਇੱਕ :int8 suffix), ਇਸ ਲਈ modes ਬਦਲਣ ਨਾਲ vec_memories table ਦੀ ਪੂਰੀ reindex ਸ਼ੁਰੂ ਹੋ ਜਾਂਦੀ ਹੈ — ਉਹੀ lazy-backfill path ਜੋ embedding ਮਾਡਲ ਬਦਲਣ ਵੇਲੇ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ।

ਮੈਮੋਰੀ ਦੀਆਂ ਕਿਸਮਾਂ

MemoryType (src/lib/memory/types.ts):

ਕਿਸਮ	ਵਰਤੋਂ
`factual`	ਤਰਜੀਹਾਂ, ਸਥਿਰ ਵਰਤੋਂਕਾਰ ਤੱਥ, ਵਿਹਾਰਕ ਪੈਟਰਨ
`episodic`	ਕਿਸੇ ਖਾਸ ਪਲ ਨਾਲ ਸੰਬੰਧਿਤ ਫ਼ੈਸਲੇ ("ਮੈਂ Postgres ਚੁਣਿਆ")
`procedural`	ਵਰਕਫ਼ਲੋ / ਕਿਵੇਂ-ਕਰਨਾ ਮੈਮੋਰੀ (ਰਾਖਵੀਂ; ਅੱਜ ਕੋਈ ਆਟੋ-ਐਕਸਟ੍ਰੈਕਟਰ ਨਹੀਂ)
`semantic`	ਵੈਕਟਰ-ਸਟੋਰ ਐਂਟਰੀਆਂ ਲਈ ਰਾਖਵੀਂ

MemoryConfig ਦੀ ਪ੍ਰਾਪਤੀ ਰਣਨੀਤੀ exact, semantic, ਜਾਂ hybrid ਵਿੱਚੋਂ ਇੱਕ ਹੈ, ਅਤੇ ਸਕੋਪ session, apiKey, ਜਾਂ global ਵਿੱਚੋਂ ਇੱਕ ਹੈ। getMemorySettings() ਤੋਂ ਡਿਫੌਲਟ ਸਕੋਪ apiKey ਹੈ।

ਤੱਥ ਕੱਢਣਾ (`extraction.ts`)

ਐਕਸਟ੍ਰੈਕਸ਼ਨ regex-ਅਧਾਰਿਤ ਹੈ, LLM-ਅਧਾਰਿਤ ਨਹੀਂ — ਇਹ setImmediate() ਨਾਲ ਇਨ-ਪ੍ਰੋਸੈਸ ਚੱਲਦਾ ਹੈ, ਇਸ ਲਈ ਇਹ ਜਵਾਬ ਸਟ੍ਰੀਮ ਨੂੰ ਕਦੇ ਬਲੌਕ ਨਹੀਂ ਕਰਦਾ:

ਤਰਜੀਹ ਪੈਟਰਨ → MemoryType.FACTUAL (ਜਿਵੇਂ ਮੈਂ … ਨੂੰ ਤਰਜੀਹ ਦਿੰਦਾ ਹਾਂ, ਮੈਨੂੰ … ਬਹੁਤ ਪਸੰਦ ਹੈ, ਮੇਰਾ ਮਨਪਸੰਦ … ਹੈ, ਮੈਨੂੰ … ਤੋਂ ਨਫ਼ਰਤ ਹੈ)
ਫ਼ੈਸਲਾ ਪੈਟਰਨ → MemoryType.EPISODIC (ਜਿਵੇਂ ਮੈਂ … ਵਰਤਾਂਗਾ, ਮੈਂ … ਚੁਣਿਆ, ਮੈਂ … ਨਾਲ ਜਾਣ ਦਾ ਫ਼ੈਸਲਾ ਕੀਤਾ, ਮੈਂ … ਅਪਣਾਉਣ ਜਾ ਰਿਹਾ ਹਾਂ)
ਵਿਹਾਰ ਪੈਟਰਨ → MemoryType.FACTUAL (ਜਿਵੇਂ ਮੈਂ ਆਮ ਤੌਰ 'ਤੇ …, ਮੈਂ ਹਮੇਸ਼ਾ …, ਮੇਰਾ ਰੁਝਾਨ … ਵੱਲ ਹੁੰਦਾ ਹੈ)

ਹਰੇਕ ਮਿਲਾਣ ਨੂੰ ਸੈਨਿਟਾਈਜ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (trim, ਖਾਲੀ ਥਾਵਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰਨਾ, ਵੱਧ ਤੋਂ ਵੱਧ 500 ਅੱਖਰ), ਇੱਕ ਸਥਿਰ factKey(category, content) ਰਾਹੀਂ ਬੈਚ ਦੇ ਅੰਦਰ ਡੀਡੁਪਲੀਕੇਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ createMemory() ਰਾਹੀਂ ਮੈਟਾਡੇਟਾ {category, extractedAt, source: "llm_response"} ਸਮੇਤ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਨਪੁੱਟ ਟੈਕਸਟ ਨੂੰ 64 KiB (MAX_EXTRACTION_TEXT_LENGTH) ਤੱਕ ਸੀਮਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ — ਜੇ ਇਹ ਇਸ ਤੋਂ ਲੰਮਾ ਹੋਵੇ, ਤਾਂ ਟੈਕਸਟ ਦਾ ਅੰਤਲਾ ਹਿੱਸਾ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਜੋ ਸਭ ਤੋਂ ਹਾਲੀਆ ਸਹਾਇਕ ਸਮੱਗਰੀ ਹਮੇਸ਼ਾ ਸ਼ਾਮਲ ਹੋਵੇ।

extractFactsFromText(text) ਨੂੰ ਟੈਸਟਾਂ ਲਈ ਐਕਸਪੋਰਟ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਇਹ ਤੱਥਾਂ ਨੂੰ ਸਟੋਰ ਕੀਤੇ ਬਿਨਾਂ ਉਨ੍ਹਾਂ ਦੀ ਸੰਰਚਿਤ ਰੂਪ ਵਿੱਚ ਵਾਪਸੀ ਕਰਦਾ ਹੈ।

ਪ੍ਰਾਪਤੀ (`retrieval.ts`)

retrieveMemories(apiKeyId, config) ਮੁੱਖ ਐਂਟਰੀ ਪੁਆਇੰਟ ਹੈ। ਇਹ:

MemoryConfigSchema ਰਾਹੀਂ ਕੌਂਫਿਗ ਨੂੰ ਸਧਾਰਨ ਅਤੇ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ।
ਜਦੋਂ enabled false ਹੋਵੇ ਜਾਂ maxTokens <= 0 ਹੋਵੇ, ਤਾਂ ਤੁਰੰਤ [] ਵਾਪਸ ਕਰਦਾ ਹੈ।
maxTokens ਨੂੰ [1, 8000] ਦੀ ਸੀਮਾ ਵਿੱਚ ਰੱਖਦਾ ਹੈ।
ਪਤਾ ਲਗਾਉਂਦਾ ਹੈ ਕਿ ਆਧੁਨਿਕ memories ਟੇਬਲ ਮੌਜੂਦ ਹੈ ਜਾਂ ਨਹੀਂ (ਪੁਰਾਣੀ memory ਟੇਬਲ ਦੇ ਮੁਕਾਬਲੇ), ਤਾਂ ਜੋ ਪੁਰਾਣੇ ਡੇਟਾਬੇਸ ਕੰਮ ਕਰਦੇ ਰਹਿਣ।
ਮਿਆਦ-ਸਮਾਪਤੀ ਗਾਰਡ (expires_at IS NULL OR datetime(expires_at) > datetime('now')), ਵਿਕਲਪਿਕ ਸੈਸ਼ਨ ਸਕੋਪ, ਅਤੇ ਵਿਕਲਪਿਕ retentionDays ਕਟਆਫ਼ ਨਾਲ ਬੇਸ ਕਵੇਰੀ ਬਣਾਉਂਦਾ ਹੈ।
ਰਣਨੀਤੀ ਦੇ ਆਧਾਰ 'ਤੇ ਸ਼ਾਖਾਬੰਦੀ ਕਰਦਾ ਹੈ:
- exact (ਡਿਫੌਲਟ): ਕਾਲਕ੍ਰਮ ਅਨੁਸਾਰ ORDER BY created_at DESC LIMIT 100।
- semantic: ਜੇ config.query ਅਤੇ memory_fts ਮੌਜੂਦ ਹੋਣ, ਤਾਂ memory_fts MATCH ? ਨਾਲ JOIN ਕਰਦਾ ਹੈ ਅਤੇ FTS ਰੈਂਕ ਅਨੁਸਾਰ ਕ੍ਰਮਬੱਧ ਕਰਦਾ ਹੈ; ਜਦੋਂ FTS 0 ਕਤਾਰਾਂ ਵਾਪਸ ਕਰੇ, ਤਾਂ ਕਾਲਕ੍ਰਮਿਕ ਕ੍ਰਮ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ।
- hybrid: FTS ਨਤੀਜਿਆਂ (ਵੱਧ ਪ੍ਰਸੰਗਿਕਤਾ) ਅਤੇ ਕਾਲਕ੍ਰਮਿਕ ਸੈੱਟ ਦਾ ਯੂਨੀਅਨ, ਜਿਸ ਨੂੰ id ਮੁਤਾਬਕ ਡੀਡੁਪਲੀਕੇਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
ਜਦੋਂ ਕੋਈ ਕਵੇਰੀ ਦਿੱਤੀ ਗਈ ਹੋਵੇ, ਤਾਂ content, key, ਅਤੇ metadata JSON ਉੱਤੇ ਕੀਵਰਡ ਪ੍ਰਸੰਗਿਕਤਾ ਸਕੋਰ (getRelevanceScore) ਦੀ ਗਣਨਾ ਕਰਦਾ ਹੈ। ਸਿਫ਼ਰ ਸਕੋਰ ਵਾਲੀਆਂ ਕਤਾਰਾਂ ਨੂੰ ਫਿਲਟਰ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।
ਪਹਿਲਾਂ ਸਕੋਰ ਨੂੰ ਘਟਦੇ ਕ੍ਰਮ ਵਿੱਚ, ਫਿਰ createdAt ਨੂੰ ਘਟਦੇ ਕ੍ਰਮ ਵਿੱਚ ਲੜੀਬੱਧ ਕਰਦਾ ਹੈ।
ਰੈਂਕ ਕੀਤੀ ਸੂਚੀ ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ ਅਤੇ ਐਂਟਰੀਆਂ ਨੂੰ ਉਦੋਂ ਤੱਕ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਜਦੋਂ ਤੱਕ ਚੱਲਦਾ ਹੋਇਆ estimateTokens(content) (≈ length / 4) ਬਜਟ ਦੇ ਅੰਦਰ ਰਹਿੰਦਾ ਹੈ। ਕੋਈ ਵੀ ਮਿਲਾਣ ਹੋਣ 'ਤੇ ਹਮੇਸ਼ਾ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਐਂਟਰੀ ਵਾਪਸ ਕਰਦਾ ਹੈ।

estimateTokens ਨੂੰ ਐਕਸਪੋਰਟ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਇਸਦੀ ਵਰਤੋਂ ਪ੍ਰਾਪਤੀ, ਸਾਰਾਂਸ਼ ਬਣਾਉਣ, ਅਤੇ MCP omniroute_memory_search ਟੂਲ ਦੁਆਰਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

ਇੰਜੈਕਸ਼ਨ (`injection.ts`)

injectMemory(request, memories, provider):

ਸਾਰੀਆਂ ਮੈਮੋਰੀ ਸਮੱਗਰੀਆਂ ਨੂੰ ਇੱਕ ਇਕੱਲੀ Memory context: … ਸਟਰਿੰਗ ਵਿੱਚ ਜੋੜਦਾ ਹੈ।
ਪ੍ਰੋਵਾਈਡਰ ਦੇ ਨਾਮ ਦੇ ਆਧਾਰ 'ਤੇ ਇੱਕ ਰਣਨੀਤੀ ਚੁਣਦਾ ਹੈ:
- ਸਿਸਟਮ ਸੁਨੇਹਾ (OpenAI, Anthropic, Gemini, … ਲਈ ਡਿਫੌਲਟ) — ਕਿਸੇ ਵੀ ਮੌਜੂਦਾ ਸਿਸਟਮ ਸੁਨੇਹੇ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ {role: "system", content: memoryText} ਜੋੜਦਾ ਹੈ, ਤਾਂ ਜੋ ਯੂਜ਼ਰ ਦੇ ਸਿਸਟਮ ਪ੍ਰੌਮਪਟਾਂ ਨੂੰ ਫਿਰ ਵੀ ਤਰਜੀਹ ਮਿਲੇ।
- ਯੂਜ਼ਰ ਸੁਨੇਹਾ (ਫਾਲਬੈਕ) — PROVIDERS_WITHOUT_SYSTEM_MESSAGE ਵਿੱਚ ਮੌਜੂਦ ਪ੍ਰੋਵਾਈਡਰਾਂ ਲਈ: o1, o1-mini, o1-preview, glm, glmt, glm-cn, zai, qianfan। ਇਹ ਸਿਸਟਮ ਰੋਲ ਨੂੰ ਅਸਵੀਕਾਰ ਕਰਦੇ ਹਨ ਅਤੇ ਨਹੀਂ ਤਾਂ 400 ਵਾਪਸ ਕਰਨਗੇ (GLM/Zhipu ਲਈ ਮੁੱਦਾ #1701 ਵੇਖੋ)।
ਗਿਣਤੀ, ਰਣਨੀਤੀ ਅਤੇ ਮਾਡਲ ਨੂੰ memory.injection.injected ਅਧੀਨ ਲੌਗ ਕਰਦਾ ਹੈ।

providerSupportsSystemMessage(provider) ਉਹਨਾਂ ਕਾਲਰਾਂ ਲਈ ਐਕਸਪੋਰਟ ਕੀਤਾ ਗਿਆ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਆਪਣੇ ਰਾਊਟਿੰਗ ਫੈਸਲੇ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਸੁਰੱਖਿਆ ਲਈ ਅਣਜਾਣ ਪ੍ਰੋਵਾਈਡਰਾਂ ਵਾਸਤੇ ਡਿਫੌਲਟ true (ਸਿਸਟਮ ਰੋਲ ਦੀ ਆਗਿਆ ਹੈ) ਹੁੰਦਾ ਹੈ।

ਸੈਟਿੰਗਾਂ (`settings.ts`)

ਮੈਮੋਰੀ ਸੰਰਚਨਾ env vars ਵਿੱਚ ਨਹੀਂ, ਸਗੋਂ DB ਸੈਟਿੰਗਾਂ ਟੇਬਲ ਵਿੱਚ ਸਟੋਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। getMemorySettings() getSettings() ਤੋਂ ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ ਨਤੀਜੇ ਨੂੰ ਪ੍ਰੋਸੈਸ ਦੇ ਅੰਦਰ ਕੈਸ਼ ਕਰਦਾ ਹੈ; ਲਿਖਤਾਂ ਤੋਂ ਬਾਅਦ ਸੈਟਿੰਗਾਂ ਦੇ PUT ਰੂਟ ਵੱਲੋਂ invalidateMemorySettingsCache() ਨੂੰ ਕਾਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਪੁਰਾਣੇ ਫੀਲਡ (ਸਾਰੇ ਵਰਜਨ)

DB ਕੁੰਜੀ	ਕਿਸਮ	ਡਿਫੌਲਟ	UI ਕੰਟਰੋਲ
`memoryEnabled`	ਬੂਲੀਅਨ	`false` (v3.8.30 ਤੋਂ ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ ਬੰਦ)	ਮੈਮੋਰੀ ਚਾਲੂ/ਬੰਦ
`memoryMaxTokens`	ਪੂਰਨ ਅੰਕ	`2000` (ਰੇਂਜ `0–16000`)	ਇੰਜੈਕਸ਼ਨ ਲਈ ਟੋਕਨ ਬਜਟ
`memoryRetentionDays`	ਪੂਰਨ ਅੰਕ	`30` (ਰੇਂਜ `1–365`)	ਰਿਟੇਨਸ਼ਨ ਵਿੰਡੋ
`memoryStrategy`	enum	`"hybrid"` (`recent`, `semantic`, `hybrid` ਵਿੱਚੋਂ ਇੱਕ)	ਪ੍ਰਾਪਤੀ ਰਣਨੀਤੀ
`skillsEnabled`	ਬੂਲੀਅਨ	`false`	ਪ੍ਰਤੀ-ਕੁੰਜੀ ਹੁਨਰ ਇੰਜੈਕਸ਼ਨ ਨੂੰ ਟੌਗਲ ਕਰਦਾ ਹੈ (SKILLS.md ਵੇਖੋ)

ਨੋਟ: UI ਰਣਨੀਤੀ "recent", toMemoryRetrievalConfig() ਰਾਹੀਂ ਅੰਦਰੂਨੀ "exact" ਪ੍ਰਾਪਤੀ ਰਣਨੀਤੀ ਨਾਲ ਮੈਪ ਹੁੰਦੀ ਹੈ (ਕਾਲਕ੍ਰਮਿਕ ਕ੍ਰਮ)।

ਨਵੇਂ ਫੀਲਡ (v3.8.6, ਯੋਜਨਾ 21 D9)

ਫੀਲਡ ਵੇਰਵਿਆਂ ਲਈ ਉੱਪਰ ਦਿੱਤਾ "ਸੈਟਿੰਗਾਂ ਦਾ ਵਿਸਤਾਰ" ਭਾਗ ਵੀ ਵੇਖੋ।

DB ਕੁੰਜੀ	API ਫੀਲਡ	ਡਿਫੌਲਟ
`memoryEmbeddingSource`	`embeddingSource`	`"auto"`
`memoryEmbeddingModel`	`embeddingProviderModel`	`null`
`memoryTransformersEnabled`	`transformersEnabled`	`false`
`memoryStaticEnabled`	`staticEnabled`	`false`
`memoryRerankEnabled`	`rerankEnabled`	`false`
`memoryRerankModel`	`rerankProviderModel`	`null`
`memoryVectorStore`	`vectorStore`	`"auto"`

Qdrant-ਸੰਬੰਧੀ DB ਕੁੰਜੀਆਂ (qdrantEnabled, qdrantHost, qdrantPort, qdrantApiKey, qdrantCollection ਡਿਫੌਲਟ "omniroute_memory", qdrantEmbeddingModel ਡਿਫੌਲਟ "openai/text-embedding-3-small") ਨੂੰ qdrant.ts ਵਿੱਚ normalizeQdrantConfig() ਵੱਲੋਂ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ।

ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ (v3.8.6)

ਛੇ ਵਿਕਲਪਿਕ env vars ਇੰਜਣ ਦੇ ਰਨਟਾਈਮ ਵਿਵਹਾਰ ਨੂੰ ਟਿਊਨ ਕਰਦੇ ਹਨ (.env.example ਵਿੱਚ ਦਸਤਾਵੇਜ਼ਬੱਧ):

ਵੇਰੀਏਬਲ	ਡਿਫੌਲਟ	ਵੇਰਵਾ
`MEMORY_EMBEDDING_CACHE_TTL_MS`	`300000`	ਐਮਬੈਡਿੰਗ ਕੈਸ਼ TTL (5 ਮਿੰਟ)
`MEMORY_EMBEDDING_CACHE_MAX`	`1000`	ਐਮਬੈਡਿੰਗ LRU ਕੈਸ਼ ਵਿੱਚ ਵੱਧ ਤੋਂ ਵੱਧ ਐਂਟਰੀਆਂ
`MEMORY_TRANSFORMERS_MODEL`	`Xenova/all-MiniLM-L6-v2`	Transformers.js ਮਾਡਲ ਲਈ HF ਰੈਪੋ
`MEMORY_STATIC_MODEL`	`minishlab/potion-base-8M`	ਸਟੈਟਿਕ potion ਮਾਡਲ ਲਈ HF ਰੈਪੋ
`MEMORY_STATIC_CACHE_DIR`	`<DATA_DIR>/embeddings`	ਡਾਊਨਲੋਡ ਕੀਤੇ ਮਾਡਲ ਕਿੱਥੇ ਸਟੋਰ ਕਰਨੇ ਹਨ
`MEMORY_VEC_TOP_K`	`20`	ਵੈਕਟਰ ਖੋਜ ਲਈ ਡਿਫੌਲਟ ਟੌਪ-K
`MEMORY_RRF_K`	`60`	ਹਾਈਬ੍ਰਿਡ ਖੋਜ ਲਈ RRF k ਸਥਿਰਾਂਕ
`MEMORY_VEC_QUANTIZATION`	`none`	ਸਥਾਨਕ sqlite-vec ਵੈਕਟਰਾਂ ਨੂੰ ਕੁਆਂਟਾਈਜ਼ਡ ਰੂਪ ਵਿੱਚ ਸਟੋਰ ਕਰਨ ਲਈ `int8` ਸੈੱਟ ਕਰੋ (~4× ਛੋਟੇ; ਔਪਟ-ਇਨ)। ਮੋਡ ਬਦਲਣ ਨਾਲ ਮੁੜ ਇੰਡੈਕਸਿੰਗ ਲਾਜ਼ਮੀ ਹੁੰਦੀ ਹੈ।

ਸੰਖੇਪੀਕਰਨ (`summarization.ts`)

ਜਦੋਂ ਕਿਸੇ ਕੁੰਜੀ ਦੀਆਂ ਮੈਮੋਰੀਆਂ ਵਿੱਚ ਚੱਲ ਰਿਹਾ ਕੁੱਲ ਟੋਕਨ ਬਜਟ ਤੋਂ ਵੱਧ ਜਾਂਦਾ ਹੈ, ਤਾਂ summarizeMemories(apiKeyId, sessionId?, maxTokens = 4000) ਪੁਰਾਣੀ ਸਮੱਗਰੀ ਨੂੰ ਸੰਖੇਪ ਕਰਦਾ ਹੈ। ਇਹ created_at ਅਨੁਸਾਰ DESC ਕ੍ਰਮ ਵਿੱਚ ਕਤਾਰਾਂ ਉੱਤੇ ਦੁਹਰਾਉਂਦਾ ਹੈ, ਸੀਮਾ ਵਿੱਚ ਫਿੱਟ ਹੋਣ ਵਾਲੀਆਂ ਕਤਾਰਾਂ ਨੂੰ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਬਾਕੀਆਂ ਲਈ content ਨੂੰ ਉਸੇ ਥਾਂ ਮੂਲ ਸਮੱਗਰੀ ਦੇ ਪਹਿਲੇ ਤਿੰਨ ਵਾਕਾਂ ਨਾਲ ਬਦਲ ਦਿੰਦਾ ਹੈ। tokensSaved, ਪੁਰਾਣੀ ਅਤੇ ਨਵੀਂ ਸਮੱਗਰੀ ਦੇ estimateTokens ਵਿਚਲਾ ਅੰਤਰ ਹੈ।

ਇਹ ਰੂਟੀਨ ਮੌਜੂਦਾ ਚੈਟ ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਉਪਲਬਧ ਹੈ ਪਰ ਆਪਣੇ-ਆਪ ਨਹੀਂ ਚਲਾਇਆ ਜਾਂਦਾ — ਜੇ ਤੁਹਾਨੂੰ ਲਗਾਤਾਰ ਸੰਖੇਪੀਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਕਿਸੇ cron, ਐਡਮਿਨ ਕਾਰਵਾਈ, ਜਾਂ MemoryConfig.autoSummarize ਗਲੂ ਤੋਂ ਕਾਲ ਕਰੋ। ਡਾਟਾ ਦਾ ਨੁਕਸਾਨ ਇਕ-ਤਰਫ਼ਾ ਹੈ: ਮੂਲ ਲਿਖਤ ਉੱਤੇ ਨਵੀਂ ਸਮੱਗਰੀ ਲਿਖ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ।

REST API

ਸਾਰੇ ਐਂਡਪੌਇੰਟਾਂ ਲਈ ਪ੍ਰਬੰਧਨ ਪ੍ਰਮਾਣੀਕਰਨ (requireManagementAuth) ਲੋੜੀਂਦਾ ਹੈ।

ਮੁੱਖ ਮੈਮੋਰੀ ਐਂਡਪੌਇੰਟ (ਮੌਜੂਦਾ + ਅੱਪਡੇਟ ਕੀਤੇ)

ਢੰਗ	ਪਾਥ	ਵੇਰਵਾ
`GET`	`/api/memory`	ਫਿਲਟਰਾਂ ਸਮੇਤ ਪੰਨਾ-ਵੰਡ ਸੂਚੀ: `apiKeyId`, `type`, `sessionId`, `q`, `limit`, `page`, `offset`। ਜਵਾਬ ਵਿੱਚ `stats.total`, `stats.tokensUsed`, `stats.hitRate`, `cacheStats` ਸ਼ਾਮਲ ਹਨ
`POST`	`/api/memory`	ਐਂਟਰੀ ਬਣਾਓ (Zod ਦੁਆਰਾ ਪ੍ਰਮਾਣਿਤ: `content`, `key`, ਵਿਕਲਪਿਕ `type`, `sessionId`, `apiKeyId`, `metadata`, `expiresAt`)। `createMemory()` ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ, ਜੋ `(apiKeyId, key)` ਉੱਤੇ upsert ਕਰਦਾ ਹੈ
`GET`	`/api/memory/[id]`	UUID ਦੁਆਰਾ ਇੱਕ ਐਂਟਰੀ ਪ੍ਰਾਪਤ ਕਰੋ
`PUT`	`/api/memory/[id]`	ਐਂਟਰੀ ਦੇ ਖੇਤਰ (`type`, `key`, `content`, `metadata`) ਅੱਪਡੇਟ ਕਰੋ। ਬਾਡੀ: `MemoryUpdatePutSchema`। ਜੇ embedding ਸਰੋਤ ਉਪਲਬਧ ਹੋਵੇ ਤਾਂ vector ਨੂੰ ਵੀ ਸਿੰਕ ਕਰਦਾ ਹੈ।
`DELETE`	`/api/memory/[id]`	ਇੱਕ ਐਂਟਰੀ ਮਿਟਾਓ; `vec_memories` (D15) ਅਤੇ Qdrant ਤੋਂ ਵੀ ਸਰਵੋਤਮ-ਯਤਨ ਦੇ ਆਧਾਰ 'ਤੇ ਮਿਟਾਉਂਦਾ ਹੈ। ਨਾ ਮਿਲਣ 'ਤੇ 404 ਵਾਪਸ ਕਰਦਾ ਹੈ।
`GET`	`/api/memory/health`	`verifyExtractionPipeline("health-check")` ਚਲਾਉਂਦਾ ਹੈ — ਰਾਊਂਡ-ਟ੍ਰਿਪ ਬਣਾਓ→ਸੂਚੀਬੱਧ ਕਰੋ→ਮਿਟਾਓ। `{working, latencyMs, error?}` ਵਾਪਸ ਕਰਦਾ ਹੈ

ਨਵੇਂ ਮੈਮੋਰੀ ਇੰਜਣ ਐਂਡਪੌਇੰਟ (ਯੋਜਨਾ 21)

ਢੰਗ	ਪਾਥ	ਵੇਰਵਾ
`POST`	`/api/memory/retrieve-preview`	`retrieveMemories` ਦਾ ਡ੍ਰਾਈ-ਰਨ — ਸਕੋਰ, ਟੀਅਰ ਅਤੇ ਟੋਕਨਾਂ ਸਮੇਤ ਰੈਂਕ ਕੀਤੇ ਨਤੀਜੇ ਵਾਪਸ ਕਰਦਾ ਹੈ। ਬਾਡੀ: `RetrievePreviewSchema`। ਮੈਮੋਰੀਆਂ ਨੂੰ ਇੰਜੈਕਟ ਜਾਂ ਸੋਧਦਾ ਨਹੀਂ ਹੈ।
`GET`	`/api/memory/embedding-providers`	embedding ਮਾਡਲਾਂ ਵਾਲੇ ਪ੍ਰਦਾਤਾਵਾਂ ਦੀ ਸੂਚੀ ਦਿੰਦਾ ਹੈ ਅਤੇ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਕਿਹੜਿਆਂ ਲਈ API ਕੁੰਜੀ ਕੌਂਫਿਗਰ ਕੀਤੀ ਗਈ ਹੈ।
`GET`	`/api/memory/engine-status`	ਇੰਜਣ ਦੀ ਪੂਰੀ ਸਥਿਤੀ ਵਾਪਸ ਕਰਦਾ ਹੈ: ਕੀਵਰਡ ਟੀਅਰ, embedding ਰੈਜ਼ੋਲਿਊਸ਼ਨ, vector store ਅੰਕੜੇ, Qdrant ਸਿਹਤ, rerank ਕੌਂਫਿਗ। ਆਕਾਰ: `MemoryEngineStatusSchema`।
`POST`	`/api/memory/summarize`	ਮੈਮੋਰੀ ਸੰਖੇਪੀਕਰਨ ਨੂੰ ਹੱਥੀਂ ਟ੍ਰਿਗਰ ਕਰੋ। ਬਾਡੀ: `MemorySummarizeSchema` (`olderThanDays`, `apiKeyId?`, `dryRun`)। `{candidates, tokensSaved}` ਵਾਪਸ ਕਰਦਾ ਹੈ।
`POST`	`/api/memory/reindex`	`needs_reindex=1` ਵਾਲੀਆਂ ਮੈਮੋਰੀਆਂ ਲਈ vector reindex ਟ੍ਰਿਗਰ ਕਰੋ। ਬਾਡੀ: `MemoryReindexSchema` (`force`)। `{started, pending}` ਵਾਪਸ ਕਰਦਾ ਹੈ।

ਸੈਟਿੰਗਾਂ ਦੇ ਐਂਡਪੌਇੰਟ

ਢੰਗ	ਪਾਥ	ਵੇਰਵਾ
`GET`	`/api/settings/memory`	ਮੌਜੂਦਾ ਸਧਾਰਣੀਕ੍ਰਿਤ `MemorySettingsExtended` (7 ਨਵੇਂ ਖੇਤਰ + legacy)
`PUT`	`/api/settings/memory`	`MemorySettingsExtendedSchema` ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਖੇਤਰ ਅੱਪਡੇਟ ਕਰੋ (ਕੁੱਲ 12 ਖੇਤਰ)
`GET`	`/api/settings/qdrant`	ਮੌਜੂਦਾ Qdrant ਸੈਟਿੰਗਾਂ (`QdrantSettingsSchema`)
`PUT`	`/api/settings/qdrant`	Qdrant ਸੈਟਿੰਗਾਂ ਅੱਪਡੇਟ ਕਰੋ। ਬਾਡੀ: `QdrantSettingsUpdateSchema`। `apiKey` = ਖਾਲੀ ਸਤਰ ਕੁੰਜੀ ਨੂੰ ਹਟਾਉਂਦੀ ਹੈ।
`GET`	`/api/settings/qdrant/health`	ਕੌਂਫਿਗਰ ਕੀਤੇ Qdrant ਇੰਸਟੈਂਸ ਦੇ ਵਿਰੁੱਧ ਜੀਵੰਤਤਾ ਜਾਂਚ। `QdrantHealthResultSchema` ਵਾਪਸ ਕਰਦਾ ਹੈ।
`POST`	`/api/settings/qdrant/search`	Qdrant ਦੇ ਵਿਰੁੱਧ semantic search ਟੈਸਟ। ਬਾਡੀ: `QdrantSearchSchema` (`query`, `topK`)।
`POST`	`/api/settings/qdrant/cleanup`	ਮਿਆਦ ਪੁੱਗੀਆਂ / ਪੁਰਾਣੀਆਂ ਮੈਮੋਰੀਆਂ ਲਈ Qdrant ਪੁਆਇੰਟ ਹਟਾਓ।
`GET`	`/api/settings/qdrant/embedding-models`	Qdrant ਲਈ ਉਪਲਬਧ embedding ਮਾਡਲਾਂ ਦੀ ਸੂਚੀ ਦਿਓ।

/api/memory ਸੂਚੀ ਕਵੈਰੀ ਜਾਂ ਤਾਂ page-ਅਧਾਰਿਤ ਪੰਨਾ-ਵੰਡ (parsePaginationParams) ਜਾਂ ਕੱਚੇ offset ਦਾ ਸਮਰਥਨ ਕਰਦੀ ਹੈ — ਜਦੋਂ offset ਮੌਜੂਦ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਤਰਜੀਹ ਮਿਲਦੀ ਹੈ ਅਤੇ ਜਵਾਬ ਦੇ ਆਕਾਰ ਲਈ ਇੱਕ ਵਿਉਤਪੰਨ page ਦੀ ਗਣਨਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

MCP ਟੂਲ (`open-sse/mcp-server/tools/memoryTools.ts`)

ਜਦੋਂ MCP ਸਰਵਰ ਸਮਰੱਥ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਤਿੰਨ ਮੈਮੋਰੀ ਟੂਲ ਰਜਿਸਟਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ:

omniroute_memory_search — {apiKeyId, query?, type?, maxTokens?, limit?} → retrieveMemories() ਨੂੰ ਰੈਪ ਕਰਦਾ ਹੈ। v3.8.6 (D16) ਤੋਂ, strategy ਨੂੰ "exact" ਵਜੋਂ ਹਾਰਡਕੋਡ ਕਰਨ ਦੀ ਬਜਾਏ getMemorySettings() ਤੋਂ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ। ਜੇ query ਦਿੱਤੀ ਗਈ ਹੈ ਅਤੇ strategy, semantic ਜਾਂ hybrid ਹੈ, ਤਾਂ ਉਪਲਬਧ ਹੋਣ 'ਤੇ ਵੈਕਟਰ ਸਟੋਰ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ।
omniroute_memory_add — {apiKeyId, sessionId?, type, key, content, metadata?} → createMemory() ਨੂੰ ਰੈਪ ਕਰਦਾ ਹੈ। ਸਿਰਫ਼ 4 ਮਿਆਰੀ ਕਿਸਮਾਂ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ: factual, episodic, procedural, semantic (D17)।
omniroute_memory_clear — {apiKeyId, type?, olderThan?} → ਮੇਲ ਖਾਂਦੀਆਂ ਐਂਟਰੀਆਂ ਨੂੰ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ, ਵਿਕਲਪਿਕ ਤੌਰ 'ਤੇ ਬਣਾਉਣ-ਤੋਂ-ਪਹਿਲਾਂ ਵਾਲੇ ਟਾਈਮਸਟੈਂਪ ਅਨੁਸਾਰ ਫਿਲਟਰ ਕਰਦਾ ਹੈ, ਫਿਰ ਹਰੇਕ ਨੂੰ deleteMemory() ਰਾਹੀਂ ਮਿਟਾਉਂਦਾ ਹੈ (ਜੋ sqlite-vec + Qdrant ਤੋਂ ਵੈਕਟਰ ਵੀ ਹਟਾਉਂਦਾ ਹੈ)।

ਟ੍ਰਾਂਸਪੋਰਟ ਅਤੇ ਸਕੋਪ ਦੇ ਵੇਰਵਿਆਂ ਲਈ MCP-SERVER.md ਵੇਖੋ।

ਡੈਸ਼ਬੋਰਡ (ਮੈਮੋਰੀ ਸਟੂਡੀਓ)

src/app/(dashboard)/dashboard/memory/page.tsx ਹੁਣ ਇੱਕ 3-ਟੈਬ ਸਟੂਡੀਓ ਹੈ:

ਟੈਬ: ਮੈਮੋਰੀਆਂ

ਸੰਕਲਪ ਕਾਰਡ (ਸਮੇਟਣਯੋਗ "ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ" ਵਿਆਖਿਆਕਾਰ)।
ਰੀਅਲ-ਟਾਈਮ ਸੂਚੀ, ਖੋਜ ਅਤੇ ਪੰਨਾ-ਵੰਡ (300 ms ਡੀਬਾਊਂਸ ਨਾਲ)।
ਕਿਸਮ ਫਿਲਟਰ (factual / episodic / procedural / semantic / ਸਾਰੀਆਂ)।
ਮੈਮੋਰੀ ਜੋੜਨ ਲਈ ਮੋਡਲ (ਕੁੰਜੀ, ਸਮੱਗਰੀ, ਕਿਸਮ)।
ਇਨਲਾਈਨ ਸੰਪਾਦਨ (ਪੈਂਸਿਲ ਬਟਨ → PUT /api/memory/[id])।
ਹਰ ਕਤਾਰ ਲਈ ਮਿਟਾਉਣ ਦੀ ਸਹੂਲਤ (ਪੁਸ਼ਟੀਕਰਨ ਡਾਇਲਾਗ ਨਾਲ)।
ਮੌਜੂਦਾ ਪੰਨੇ ਦਾ JSON ਨਿਰਯਾਤ; ਫ਼ਾਈਲ ਪਿਕਰ ਰਾਹੀਂ JSON ਆਯਾਤ।
ਅੰਕੜਾ ਕਾਰਡ: totalEntries, tokensUsed, hitRate।
"ਪੁਰਾਣੀਆਂ ਨੂੰ ਸੰਖੇਪ ਕਰੋ" ਬਟਨ → POST /api/memory/summarize (ਪਹਿਲਾਂ ਡ੍ਰਾਈ-ਰਨ ਉਮੀਦਵਾਰਾਂ ਦੀ ਗਿਣਤੀ ਦਿਖਾਉਂਦਾ ਹੈ, ਫਿਰ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ)।
GET /api/memory/health ਦੁਆਰਾ ਸੰਚਾਲਿਤ ਹਰਾ/ਲਾਲ ਸਿਹਤ ਬਿੰਦੂ।

ਟੈਬ: ਪਲੇਗ੍ਰਾਊਂਡ

ਕਵੇਰੀ ਇਨਪੁੱਟ + ਰਣਨੀਤੀ ਚੋਣਕਾਰ (ਸਟੀਕ / ਅਰਥ-ਆਧਾਰਿਤ / ਹਾਈਬ੍ਰਿਡ) + ਟੋਕਨ ਬਜਟ।
"ਸਿਮੂਲੇਟ ਕਰੋ" → POST /api/memory/retrieve-preview — ਦਰਜਾਬੱਧ ਨਤੀਜਿਆਂ ਨੂੰ score, tier, tokens, vecScore, ftsScore ਸਮੇਤ ਦਿਖਾਉਂਦਾ ਹੈ।
ਰੈਜ਼ੋਲਿਊਸ਼ਨ ਪੈਨਲ, ਜੋ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਐਮਬੈਡਿੰਗ ਸਰੋਤ / ਵੈਕਟਰ ਸਟੋਰ ਵਰਤਿਆ ਗਿਆ ਸੀ ਅਤੇ ਕੀ ਕੋਈ ਫਾਲਬੈਕ ਹੋਇਆ ਸੀ।

ਟੈਬ: ਇੰਜਣ

ਇੰਜਣ ਸਥਿਤੀ ਪੈਨਲ (ਕੀਵਰਡ FTS5 ਚਿਪ, ਐਮਬੈਡਿੰਗ ਚਿਪ, ਵੈਕਟਰ ਸਟੋਰ ਚਿਪ, Qdrant ਸਿਹਤ ਚਿਪ, ਰੀਰੈਂਕ ਚਿਪ)।
"ਹੁਣੇ ਮੁੜ ਇੰਡੈਕਸ ਕਰੋ" ਬਟਨ → POST /api/memory/reindex।
ਐਮਬੈਡਿੰਗ ਸਰੋਤ ਚੋਣਕਾਰ (ਆਟੋ / ਰਿਮੋਟ / ਸਟੈਟਿਕ / ਟ੍ਰਾਂਸਫਾਰਮਰ + ਟੌਗਲ)।
Qdrant ਸੰਰਚਨਾ ਕਾਰਡ (ਸਮਰੱਥ ਟੌਗਲ, ਹੋਸਟ/ਪੋਰਟ/ਕਲੈਕਸ਼ਨ/ਕੁੰਜੀ, ਕਨੈਕਸ਼ਨ ਟੈਸਟ, ਅਰਥ-ਆਧਾਰਿਤ ਖੋਜ ਟੈਸਟ, ਸਫ਼ਾਈ)।
ਰੀਰੈਂਕ ਸੰਰਚਨਾ ਕਾਰਡ (ਸਮਰੱਥ ਟੌਗਲ, ਪ੍ਰਦਾਤਾ/ਮਾਡਲ ਚੋਣਕਾਰ)।

ਮੈਮੋਰੀ ਅਤੇ Qdrant ਸੈਟਿੰਗਾਂ ਪੁਰਾਣੀ/ਗਲੋਬਲ ਸੈਟਿੰਗਾਂ ਦੀ ਸਤ੍ਹਾ ਲਈ /dashboard/settings → ਮੈਮੋਰੀ ਅਤੇ ਹੁਨਰ (MemorySkillsTab.tsx) ਦੇ ਅਧੀਨ ਵੀ ਮੌਜੂਦ ਹਨ।

ਕੈਸ਼ਿੰਗ

src/lib/memory/store.ts, getMemory(id) ਰੀਡਾਂ ਲਈ ਇੱਕ ਇਨ-ਪ੍ਰੋਸੈੱਸ LRU-ਸਮਾਨ ਕੈਸ਼ (MEMORY_CACHE_TTL = 1 ਮਿੰਟ, MEMORY_MAX_CACHE_SIZE = 500, 20 % ਸਭ ਤੋਂ ਪੁਰਾਣੀਆਂ ਐਂਟਰੀਆਂ ਦੀ ਬੇਦਖ਼ਲੀ ਨਾਲ) ਰੱਖਦਾ ਹੈ, ਨਾਲ ਹੀ ਇੱਕ ਆਮ ਕੁੰਜੀ/ਮੁੱਲ memoryCache ਪਰਤ (src/lib/memory/cache.ts) ਵੀ ਹੈ, ਜਿਸ ਵਿੱਚ get/set/invalidate ਵਿਧੀਆਂ ਹਨ ਅਤੇ ਇਸਨੂੰ ਆਪਣੇ ਸਕੋਪ ਵਾਲਾ ਕੈਸ਼ ਚਾਹੁਣ ਵਾਲੇ ਕਾਲਰ ਵਰਤਦੇ ਹਨ (1 000-ਐਂਟਰੀ LRU, ਡਿਫਾਲਟ TTL 5 ਮਿੰਟ)।

ਪਰਦੇਦਾਰੀ ਅਤੇ ਜੀਵਨ-ਚੱਕਰ

ਮੈਮੋਰੀ ਦੀ ਮਲਕੀਅਤ API key id ਕੋਲ ਹੁੰਦੀ ਹੈ (chatCore.ts ਵਿੱਚ resolveMemoryOwnerId)। apiKeyInfo.id ਤੋਂ ਬਿਨਾਂ ਨਾ ਪ੍ਰਾਪਤੀ, ਨਾ ਇੰਜੈਕਸ਼ਨ ਅਤੇ ਨਾ ਹੀ ਐਕਸਟ੍ਰੈਕਸ਼ਨ ਚੱਲਦਾ ਹੈ।
ਭਵਿੱਖ ਦੇ expires_at ਵਾਲੀਆਂ ਐਂਟਰੀਆਂ ਨੂੰ ਪ੍ਰਾਪਤੀ ਵਿੱਚੋਂ ਫਿਲਟਰ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ; retentionDays ਤੋਂ ਪੁਰਾਣੀਆਂ ਐਂਟਰੀਆਂ ਨੂੰ retrieveMemories ਵਿੱਚ created_at >= cutoff ਕਲੌਜ਼ ਰਾਹੀਂ ਬਾਹਰ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ।
ਸਥਾਈ ਮਿਟਾਉਣ ਲਈ, DELETE /api/memory/[id] ਜਾਂ omniroute_memory_clear ਵਰਤੋ।
ਐਕਸਟ੍ਰੈਕਸ਼ਨ setImmediate ਰਾਹੀਂ ਬਿਨਾਂ ਉਡੀਕ ਕੀਤੇ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ; ਅਸਫਲਤਾਵਾਂ memory.extraction.background.failed ਹੇਠ ਲੌਗ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ ਕਾਲਰ ਤੱਕ ਕਦੇ ਨਹੀਂ ਪਹੁੰਚਦੀਆਂ।
ਪੁਸ਼ਟੀਕਰਨ ਰਾਊਂਡ-ਟ੍ਰਿਪ (verifyExtractionPipeline) ਇੱਕ finally ਬਲਾਕ ਵਿੱਚ ਆਪਣੀਆਂ ਟੈਸਟ ਐਂਟਰੀਆਂ ਖੁਦ ਸਾਫ਼ ਕਰਦੇ ਹਨ।

ਇਹ ਵੀ ਵੇਖੋ

SKILLS.md — skillsEnabled ਸੈਟਿੰਗ ਮੈਮੋਰੀ ਦੇ ਨਾਲ ਟੂਲ ਪਰਿਭਾਸ਼ਾਵਾਂ ਇੰਜੈਕਟ ਕਰਦੀ ਹੈ।
MCP-SERVER.md — MCP ਟ੍ਰਾਂਸਪੋਰਟ / ਸਕੋਪ।
API_REFERENCE.md — ਵਧੇਰੇ ਵਿਸਤ੍ਰਿਤ API ਸਤਹ।
ਸਰੋਤ ਮੋਡੀਊਲ:
- src/lib/memory/types.ts, schemas.ts
- src/lib/memory/store.ts, retrieval.ts, injection.ts, reindex.ts
- src/lib/memory/extraction.ts, summarization.ts, verify.ts
- src/lib/memory/settings.ts, qdrant.ts, cache.ts
- src/lib/memory/vectorStore.ts — sqlite-vec + ਹਾਈਬ੍ਰਿਡ RRF
- src/lib/memory/embedding/index.ts — ਬਹੁ-ਸਰੋਤ ਐਮਬੈਡਿੰਗ ਪਰਤ
- src/lib/memory/embedding/types.ts, remote.ts, staticPotion.ts, transformersLocal.ts, cache.ts
- src/shared/schemas/memory.ts — ਸਾਰੀਆਂ ਮੈਮੋਰੀ API ਬਾਡੀਆਂ ਲਈ Zod ਸਕੀਮਾ
- src/shared/schemas/qdrant.ts — Qdrant ਸੈਟਿੰਗਾਂ/ਓਪਰੇਸ਼ਨਾਂ ਲਈ Zod ਸਕੀਮਾ
- src/lib/db/memoryVec.ts — memory_vec_meta ਲਈ CRUD
- src/lib/db/migrations/015_create_memories.sql, 022_add_memory_fts5.sql, 023_fix_memory_fts_uuid.sql, 083_memory_vec.sql
- src/app/api/memory/route.ts, [id]/route.ts, health/route.ts
- src/app/api/memory/retrieve-preview/route.ts
- src/app/api/memory/engine-status/route.ts
- src/app/api/memory/embedding-providers/route.ts
- src/app/api/memory/summarize/route.ts
- src/app/api/memory/reindex/route.ts
- src/app/api/settings/memory/route.ts
- src/app/api/settings/qdrant/route.ts + ਸਬ-ਰੂਟ
- src/app/(dashboard)/dashboard/memory/ — Studio UI (ਪੰਨਾ + ਕੰਪੋਨੈਂਟ + ਟੈਬ + ਹੁੱਕ)
- open-sse/handlers/chatCore.ts (ਇੰਜੈਕਸ਼ਨ / ਐਕਸਟ੍ਰੈਕਸ਼ਨ ਵਾਇਰਿੰਗ)
- open-sse/mcp-server/tools/memoryTools.ts

ਐਮਬੈਡਿੰਗ ਪ੍ਰਦਾਤਾ ਚੁਣਨਾ (v3.8.16+)

OmniRoute ਦਾ ਮੈਮੋਰੀ ਇੰਜਣ ਚਾਰ ਐਮਬੈਡਿੰਗ ਸਰੋਤਾਂ (src/lib/memory/embedding/) ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਹਰੇਕ ਵਿੱਚ ਲੇਟੈਂਸੀ, ਲਾਗਤ, ਮਾਡਲ ਗੁਣਵੱਤਾ ਅਤੇ ਸੈੱਟਅੱਪ ਦੀ ਜਟਿਲਤਾ ਸੰਬੰਧੀ ਵੱਖ-ਵੱਖ ਸਮਝੌਤੇ ਹਨ।

ਐਮਬੈਡਿੰਗ ਸਰੋਤ

ਪ੍ਰਦਾਤਾ	ਸਰੋਤ	ਲੇਟੈਂਸੀ	ਲਾਗਤ	ਗੁਣਵੱਤਾ	ਸੈੱਟਅੱਪ
`transformers`	ਲੋਕਲ ONNX ਮਾਡਲ (Xenova/all-MiniLM-L6-v2)	~50-150ms (CPU)	ਮੁਫ਼ਤ	ਚੰਗੀ	ਸਿਰਫ਼ `npm install`
`static`	ਪਹਿਲਾਂ ਤੋਂ ਗਣਨਾ ਕੀਤੇ ਵੈਕਟਰ (ਕੈਸ਼ ਕੀਤੇ)	<1ms	ਮੁਫ਼ਤ	ਲਾਗੂ ਨਹੀਂ (ਕੈਸ਼ ਹਿੱਟ 'ਤੇ ਨਿਰਭਰ)	ਕੋਈ ਨਹੀਂ
`remote`	OpenAI / Cohere / Voyage API	~100-300ms	$0.02-0.10/1M ਟੋਕਨ	ਸ਼ਾਨਦਾਰ	API key
`auto`	ਰਨਟਾਈਮ 'ਤੇ ਸਭ ਤੋਂ ਵਧੀਆ ਉਪਲਬਧ ਸਰੋਤ ਚੁਣਦਾ ਹੈ	ਚੁਣੇ ਸਰੋਤ ਦੇ ਸਮਾਨ	ਮੁਫ਼ਤ	ਚੁਣੇ ਸਰੋਤ ਦੇ ਸਮਾਨ	ਕੋਈ ਨਹੀਂ
(cache)	ਕਿਸੇ ਵੀ ਸਰੋਤ ਉੱਤੇ ਇਨ-ਮੈਮੋਰੀ LRU ਪਰਤ	<1ms (ਹਿੱਟ), ਪੂਰੀ ਲੇਟੈਂਸੀ (ਮਿਸ)	ਮੁਫ਼ਤ	ਅਧਾਰਭੂਤ ਸਰੋਤ ਦੇ ਸਮਾਨ	ਹਮੇਸ਼ਾ ਚਾਲੂ (ਚੁਣਨਯੋਗ ਸਰੋਤ ਨਹੀਂ)

ਫ਼ੈਸਲਾ-ਵ੍ਰਿੱਖ

                  ਤੁਹਾਡਾ ਡਿਪਲੌਇਮੈਂਟ ਸੰਦਰਭ ਕੀ ਹੈ?
                  │
      ┌───────────┼───────────┬──────────────┐
      │           │           │              │
  ਵਿਕਾਸ/ਟੈਸਟ    ਛੋਟਾ ਉਤਪਾਦਨ   ਵੱਡਾ ਉਤਪਾਦਨ    ਐਜ / ਆਫ਼ਲਾਈਨ
      │           │           │              │
      ▼           ▼           ▼              ▼
  transformers transformers remote (Qdrant) transformers
  (ਮੁਫ਼ਤ, ਕੋਈ API ਨਹੀਂ)       (ਸਭ ਤੋਂ ਵਧੀਆ ਗੁਣਵੱਤਾ)   (ਇੰਟਰਨੈੱਟ ਨਹੀਂ)
      │           │           │              │
      └────────┬──┴───────────┴──────────────┘
               │
               ▼
            ਉੱਪਰ ਹਮੇਸ਼ਾ `cache` ਪਰਤ ਜੋੜੋ
            (LruCache ਕਿਸੇ ਵੀ ਪ੍ਰਦਾਤਾ ਨੂੰ ਰੈਪ ਕਰਦਾ ਹੈ)

ਡਾਟਾਬੇਸ ਅਤੇ API ਸੰਰਚਨਾ

ਮੈਮੋਰੀ ਐਮਬੈਡਿੰਗ ਵਿਕਲਪ environment variables ਦੀ ਬਜਾਏ Settings API/UI ਰਾਹੀਂ ਸੰਰਚਿਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। Settings ਹੇਠ ਸੰਬੰਧਿਤ ਸੈਟਿੰਗ ਡਾਟਾਬੇਸ ਕੁੰਜੀਆਂ (src/lib/memory/settings.ts ਵਿੱਚ normalizeMemorySettings) ਇਹ ਹਨ:

memoryEmbeddingSource: "transformers" (ਲੋਕਲ), "remote" (API-ਅਧਾਰਿਤ, ਜਿਵੇਂ OpenAI), "static" (ਬਾਹਰੀ ਸਟੋਰ), ਜਾਂ "auto"
memoryEmbeddingProviderModel: ਰਿਮੋਟ/ਸਟੈਟਿਕ ਸਰੋਤਾਂ ਲਈ ਮਾਡਲ ਪਛਾਣਕਰਤਾ (ਜਿਵੇਂ, "text-embedding-3-small")
memoryTransformersEnabled: true | false
memoryStaticEnabled: true | false
memoryVectorStore: "sqlite-vec", "qdrant", ਜਾਂ "auto"

ਲੋਕਲ ਮਾਡਲ (`transformers`)

ਲੋਕਲ ਮਾਡਲ ਚਲਾਉਣ ਲਈ ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ transformers.js ਵਰਤਦਾ ਹੈ:

# ਕੋਡ ਵਿੱਚ ਪੜ੍ਹੇ ਜਾਂਦੇ environment variables (src/lib/memory/embedding/index.ts):
MEMORY_TRANSFORMERS_MODEL=Xenova/all-MiniLM-L6-v2  # HF ਮਾਡਲ ਰਿਪੋ
MEMORY_STATIC_MODEL=minishlab/potion-base-8M       # HF ਸਟੈਟਿਕ ਪੋਸ਼ਨ ਮਾਡਲ
MEMORY_STATIC_CACHE_DIR=<DATA_DIR>/embeddings      # ਕੈਸ਼ ਡਾਇਰੈਕਟਰੀ

LRU ਐਮਬੈਡਿੰਗ ਕੈਸ਼

ਕੈਸ਼ ਮੂਲ ਰੂਪ ਵਿੱਚ ਹਮੇਸ਼ਾ ਚਾਲੂ ਹੁੰਦਾ ਹੈ ਅਤੇ env vars ਰਾਹੀਂ ਸੰਰਚਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ:

MEMORY_EMBEDDING_CACHE_MAX=1000                    # ਵੱਧ ਤੋਂ ਵੱਧ ਕੈਸ਼ ਕੀਤੀਆਂ ਆਈਟਮਾਂ
MEMORY_EMBEDDING_CACHE_TTL_MS=300000               # TTL (5 ਮਿੰਟ)

ਪ੍ਰਦਰਸ਼ਨ ਅੰਕੜੇ

ਇੱਕ ਆਮ 4-ਕੋਰ x86 ਸਰਵਰ ਉੱਤੇ ਬੈਂਚਮਾਰਕ (ਹਰੇਕ ਟੈਕਸਟ ~100 ਟੋਕਨ):

ਪ੍ਰਦਾਤਾ	p50	p95	p99	ਲਾਗਤ / 1M ਐਮਬੈਡਿੰਗਜ਼
`transformers` (CPU)	80ms	180ms	350ms	ਮੁਫ਼ਤ
`remote` (OpenAI)	120ms	220ms	400ms	~$0.02 (ada-002) / $0.13 (3-large)
`static` (Qdrant)	15ms	30ms	60ms	Qdrant ਹੋਸਟਿੰਗ ਉੱਤੇ ਨਿਰਭਰ
`cache` (ਹਿੱਟ)	<1ms	<1ms	2ms	ਮੁਫ਼ਤ

ਤੱਥ ਕੱਢਣ ਦੇ ਪੈਟਰਨ (v3.8.16+)

extraction.ts ਮੋਡੀਊਲ (src/lib/memory/extraction.ts) ਗੱਲਬਾਤੀ ਸੁਨੇਹਿਆਂ ਵਿੱਚੋਂ ਸੰਰਚਿਤ ਤੱਥ ਕੱਢਣ ਲਈ ਰੈਗੂਲਰ ਐਕਸਪ੍ਰੈਸ਼ਨ ਪੈਟਰਨ ਮਿਲਾਨ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਇਨ੍ਹਾਂ ਪੈਟਰਨਾਂ ਨੂੰ ਸਮਝਣ ਨਾਲ ਤੁਹਾਨੂੰ ਆਪਣੇ ਵਰਤੋਂ-ਮਾਮਲੇ ਲਈ ਤੱਥ ਕੱਢਣ ਦੀ ਗੁਣਵੱਤਾ ਅਨੁਕੂਲ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਮਿਲਦੀ ਹੈ।

ਡਿਫਾਲਟ ਪੈਟਰਨ ਸ਼੍ਰੇਣੀਆਂ

ਸ਼੍ਰੇਣੀ	ਉਦਾਹਰਨ ਪੈਟਰਨ	ਕੀ ਕੈਪਚਰ ਕਰਦਾ ਹੈ
PREFERENCE_PATTERNS	`"ਮੈਂ <X> ਨੂੰ ਤਰਜੀਹ ਦਿੰਦਾ ਹਾਂ"`, `"ਮੈਨੂੰ <X> ਪਸੰਦ ਹੈ"`, `"ਮੈਨੂੰ <X> ਨਾਲ ਨਫ਼ਰਤ ਹੈ"`	ਵਰਤੋਂਕਾਰ ਦੀਆਂ ਤਰਜੀਹਾਂ
DECISION_PATTERNS	`"ਮੈਂ <X> ਵਰਤਾਂਗਾ"`, `"ਮੈਂ <X> ਕਰਨ ਦਾ ਫ਼ੈਸਲਾ ਕੀਤਾ"`, `"ਮੈਂ <X> ਨੂੰ ਚੁਣਿਆ"`	ਵਰਤੋਂਕਾਰ ਦੇ ਫ਼ੈਸਲੇ (ਘਟਨਾਤਮਕ)
PATTERN_PATTERNS	`"ਮੈਂ ਆਮ ਤੌਰ 'ਤੇ <X> ਕਰਦਾ ਹਾਂ"`, `"ਮੈਂ ਹਮੇਸ਼ਾ <X> ਕਰਦਾ ਹਾਂ"`, `"ਮੈਂ ਕਦੇ ਵੀ <X> ਨਹੀਂ ਕਰਦਾ"`	ਸਥਾਈ ਵਿਹਾਰਕ ਪੈਟਰਨ

ਉਦਾਹਰਨ ਪੈਟਰਨ (ਸਰਲ ਬਣਾਏ ਹੋਏ)

// src/lib/memory/extraction.ts ਤੋਂ
const PREFERENCE_PATTERNS = [
  /\bI\s+(?:really\s+)?prefer\s+([^.,\n]+)/gi,
  /\bI\s+(?:really\s+)?like\s+([^.,\n]+)/gi,
  /\bI\s+(?:hate|dislike|avoid)\s+([^.,\n]+)/gi,
];
const DECISION_PATTERNS = [
  /\bI'?(?:ll|will)\s+use\s+([^.,\n]+)/gi,
  /\bI\s+(?:have\s+)?decided\s+(?:to\s+)?([^.,\n]+)/gi,
];
const PATTERN_PATTERNS = [/\bI\s+usually\s+([^.,\n]+)/gi, /\bI\s+always\s+([^.,\n]+)/gi];

ਕੀ ਕੱਢਿਆ ਜਾਂਦਾ ਹੈ

ਜਦੋਂ ਕੋਈ ਵਰਤੋਂਕਾਰ ਕਹਿੰਦਾ ਹੈ:

"ਮੈਂ TypeScript ਨੂੰ ਤਰਜੀਹ ਦਿੰਦਾ ਹਾਂ। ਮੈਂ ਇਸ ਪ੍ਰੋਜੈਕਟ ਲਈ Postgres ਵਰਤਾਂਗਾ। ਮੈਂ ਹਮੇਸ਼ਾ ਪੁਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕਮਿਟ ਕਰਦਾ ਹਾਂ। ਮੈਨੂੰ Python ਪਸੰਦ ਨਹੀਂ ਹੈ।" ਤੱਥ ਕੱਢਣ ਦੀ ਪ੍ਰਕਿਰਿਆ 4 ਯਾਦਾਂ ਬਣਾਉਂਦੀ ਹੈ:

ਕੁੰਜੀ ਸ਼੍ਰੇਣੀ ਕਿਸਮ ਸਮੱਗਰੀ

preference:typescript ਤਰਜੀਹ ਤੱਥਾਤਮਕ "TypeScript"

decision:postgres_for_this_project ਫ਼ੈਸਲਾ ਘਟਨਾਤਮਕ "ਇਸ ਪ੍ਰੋਜੈਕਟ ਲਈ Postgres"

pattern:commit_before_pushing ਪੈਟਰਨ ਤੱਥਾਤਮਕ "ਪੁਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕਮਿਟ ਕਰਨਾ"

preference:python ਤਰਜੀਹ ਤੱਥਾਤਮਕ "Python"

ਕੁੰਜੀ	ਸ਼੍ਰੇਣੀ	ਕਿਸਮ	ਸਮੱਗਰੀ
`preference:typescript`	ਤਰਜੀਹ	ਤੱਥਾਤਮਕ	"TypeScript"
`decision:postgres_for_this_project`	ਫ਼ੈਸਲਾ	ਘਟਨਾਤਮਕ	"ਇਸ ਪ੍ਰੋਜੈਕਟ ਲਈ Postgres"
`pattern:commit_before_pushing`	ਪੈਟਰਨ	ਤੱਥਾਤਮਕ	"ਪੁਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕਮਿਟ ਕਰਨਾ"
`preference:python`	ਤਰਜੀਹ	ਤੱਥਾਤਮਕ	"Python"

ਤੱਥ ਕੱਢਣ ਦੀਆਂ ਸੀਮਾਵਾਂ

ਬੇਕਾਬੂ ਤੱਥ ਕੱਢਣ ਨੂੰ ਰੋਕਣ ਲਈ, ਹੇਠ ਲਿਖੀਆਂ ਸੀਮਾਵਾਂ ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ:

ਤੱਥ ਕੱਢਣ ਨੂੰ ਕਦੋਂ ਅਸਮਰੱਥ ਕਰਨਾ ਹੈ

ਜਦੋਂ ਵੀ ਮੈਮੋਰੀ ਸਮਰੱਥ ਹੁੰਦੀ ਹੈ, ਤੱਥ ਕੱਢਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਆਪਣੇ ਆਪ ਚੱਲਦੀ ਹੈ; ਸਿਰਫ਼ ਤੱਥ ਕੱਢਣ ਲਈ ਕੋਈ ਵੱਖਰਾ ਟੌਗਲ ਨਹੀਂ ਹੈ। ਇਸਨੂੰ ਬੰਦ ਕਰਨ ਲਈ, ਮੈਮੋਰੀ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਸਮਰੱਥ ਕਰੋ (enabled: false ਨੂੰ PUT /api/settings/memory ਰਾਹੀਂ ਸੈੱਟ ਕਰੋ)। ਹੇਠ ਲਿਖੀਆਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਅਜਿਹਾ ਕਰਨ ਬਾਰੇ ਵਿਚਾਰ ਕਰੋ:

ਤੁਹਾਡੇ ਕੋਲ ਸੁਨੇਹਿਆਂ ਦੀ ਮਾਤਰਾ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੈ ਅਤੇ ਤੱਥ ਕੱਢਣ ਦੀ ਲਾਗਤ ਗੌਣ ਨਹੀਂ ਹੈ
ਤੁਹਾਡੀਆਂ ਗੱਲਬਾਤਾਂ ਜ਼ਿਆਦਾਤਰ ਅਸਥਾਈ ਹਨ (ਚੈਟ, ਡੀਬੱਗਿੰਗ) ਅਤੇ ਉਨ੍ਹਾਂ ਦਾ ਕੋਈ ਲੰਬੇ ਸਮੇਂ ਦਾ ਮੁੱਲ ਨਹੀਂ ਹੈ
ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਕਸਟਮ ਪਲੱਗਇਨਾਂ ਰਾਹੀਂ ਸੰਦਰਭ ਕੈਪਚਰ ਕਰ ਰਹੇ ਹੋ

ਹਾਈਬ੍ਰਿਡ RRF ਟਿਊਨਿੰਗ (v3.8.16+)

Reciprocal Rank Fusion (RRF) ਐਲਗੋਰਿਦਮ FTS5 (ਕੀਵਰਡ) ਅਤੇ ਵੈਕਟਰ (ਅਰਥ-ਅਧਾਰਿਤ) ਨਤੀਜਿਆਂ ਨੂੰ ਜੋੜਦਾ ਹੈ। k ਪੈਰਾਮੀਟਰ ਇਹ ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ ਕਿ ਹੇਠਲੇ ਰੈਂਕ ਵਾਲੇ ਨਤੀਜਿਆਂ ਨੂੰ ਕਿੰਨਾ ਭਾਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।

ਫ਼ਾਰਮੂਲਾ

ਹਰੇਕ ਉਮੀਦਵਾਰ ਮੈਮੋਰੀ ਲਈ, RRF ਸਕੋਰ ਇਹ ਹੈ:

RRF(d) = Σ  1 / (k + rank_i(d))

ਜਿੱਥੇ:

k ਸਥਿਰ ਅੰਕ ਹੈ (ਡਿਫਾਲਟ 60)
rank_i(d) iਵੇਂ ਪ੍ਰਾਪਤੀ ਸਿਸਟਮ (FTS, ਵੈਕਟਰ) ਵਿੱਚ ਦਸਤਾਵੇਜ਼ d ਦਾ ਰੈਂਕ ਹੈ
ਜੋੜ ਸਾਰੇ ਪ੍ਰਾਪਤੀ ਸਿਸਟਮਾਂ ਉੱਤੇ ਕੀਤਾ ਜਾਂਦਾ ਹੈ

`k` ਨਤੀਜਿਆਂ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ

`k` ਮੁੱਲ	ਪ੍ਰਭਾਵ	ਕਿਸ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ
`k=0`	ਸ਼ੁੱਧ ਰੈਂਕ ਫਿਊਜ਼ਨ (ਕੋਈ ਸਮੂਦਿੰਗ ਨਹੀਂ)	ਸਿਧਾਂਤਕ ਬੇਸਲਾਈਨ
`k=10-30`	ਚੋਟੀ ਦੇ ਨਤੀਜਿਆਂ ਨੂੰ ਬਹੁਤ ਵੱਧ ਭਾਰ ਦਿੰਦਾ ਹੈ, ਹੇਠਲਾ ਰੈਂਕ ਬਹੁਤ ਘੱਟ ਯੋਗਦਾਨ ਪਾਉਂਦਾ ਹੈ	ਜਦੋਂ ਚੋਟੀ ਦੇ 3 ਨਤੀਜੇ ਆਮ ਤੌਰ 'ਤੇ ਸਹੀ ਹੁੰਦੇ ਹਨ
`k=60` (ਡਿਫਾਲਟ)	ਸੰਤੁਲਿਤ — ਚੋਟੀ ਦੇ 10 ਨਤੀਜੇ ਸਾਰੇ ਅਰਥਪੂਰਨ ਯੋਗਦਾਨ ਪਾਉਂਦੇ ਹਨ	ਆਮ-ਉਦੇਸ਼ੀ ਪ੍ਰਾਪਤੀ
`k=100+`	ਵਧੇਰੇ ਸਮਤਲ — ਕਈ ਸਿਸਟਮਾਂ ਵਿੱਚ ਆਉਣ 'ਤੇ ਹੇਠਲੇ ਰੈਂਕ ਵਾਲੇ ਨਤੀਜੇ ਵੀ ਹਾਵੀ ਹੋ ਸਕਦੇ ਹਨ	ਜਦੋਂ ਰੀਕਾਲ > ਪ੍ਰਿਸੀਜ਼ਨ ਮਹੱਤਵਪੂਰਨ ਹੋਵੇ

ਅਮਲ ਵਿੱਚ `k` ਨੂੰ ਟਿਊਨ ਕਰਨਾ

# ਡਿਫਾਲਟ
MEMORY_RRF_K=60

# ਆਕਰਮਕ ਪ੍ਰਿਸੀਜ਼ਨ (ਛੋਟੀ ਮੈਮੋਰੀ, ਕੁਝ ਦਸਤਾਵੇਜ਼)
MEMORY_RRF_K=20

# ਵੱਧ ਤੋਂ ਵੱਧ ਰੀਕਾਲ (ਵੱਡੀ ਮੈਮੋਰੀ, ਵੱਖ-ਵੱਖ ਕਵੈਰੀਆਂ)
MEMORY_RRF_K=120

k=20 ਨਾਲ ਉਦਾਹਰਨ:

FTS ਰੈਂਕ 1 → ਯੋਗਦਾਨ 1/21 = 0.048
FTS ਰੈਂਕ 10 → ਯੋਗਦਾਨ 1/30 = 0.033
ਵੈਕਟਰ ਰੈਂਕ 1 → ਯੋਗਦਾਨ 0.048
ਸੰਯੁਕਤ ਅਧਿਕਤਮ: 0.096

k=60 ਨਾਲ ਉਦਾਹਰਨ:

FTS ਰੈਂਕ 1 → ਯੋਗਦਾਨ 1/61 = 0.016
FTS ਰੈਂਕ 10 → ਯੋਗਦਾਨ 1/70 = 0.014
ਵੈਕਟਰ ਰੈਂਕ 1 → ਯੋਗਦਾਨ 0.016
ਸੰਯੁਕਤ ਅਧਿਕਤਮ: 0.033

ਵੱਧ k ਨਾਲ, ਚੋਟੀ ਦੇ ਰੈਂਕ 1 ਅਤੇ ਰੈਂਕ 10 ਵਿਚਕਾਰ ਸਾਪੇਖ ਅੰਤਰ ਘੱਟ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਐਲਗੋਰਿਦਮ ਚੋਟੀ ਦੇ ਰੈਂਕ ਦੇ ਭਰੋਸੇ ਨਾਲੋਂ ਪ੍ਰਾਪਤੀ ਸਿਸਟਮਾਂ ਵਿਚਕਾਰ ਸਹਿਮਤੀ ਉੱਤੇ ਵੱਧ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।

`k` ਨੂੰ ਕਦੋਂ ਬਦਲਣਾ ਹੈ

ਲੱਛਣ	ਇਹ ਅਜ਼ਮਾਓ
ਚੋਟੀ ਦਾ ਨਤੀਜਾ ਹਮੇਸ਼ਾ ਜਿੱਤਦਾ ਹੈ, ਪਰ ਉਹ ਗਲਤ ਹੈ	ਘੱਟ k (ਜਿਵੇਂ, 20) — ਚੋਟੀ ਦੇ ਰੈਂਕ ਦਾ ਭਰੋਸਾ ਵੱਧ ਮਹੱਤਵ ਰੱਖਦਾ ਹੈ
ਸਹੀ ਜਵਾਬ ਚੋਟੀ ਦੇ 5 ਵਿੱਚ ਹੈ ਪਰ ਚੋਟੀ ਦੇ 1 ਵਿੱਚ ਨਹੀਂ	ਵੱਧ k (ਜਿਵੇਂ, 100) — ਸਮਤਲ ਸਕੋਰਿੰਗ ਸਹਿਮਤੀ ਨੂੰ ਇਨਾਮ ਦਿੰਦੀ ਹੈ
ਰੀਕਾਲ ਉੱਚਾ ਹੈ ਪਰ ਪ੍ਰਿਸੀਜ਼ਨ ਘੱਟ ਹੈ	ਘੱਟ k — ਰੈਂਕਿੰਗ ਨੂੰ ਹੋਰ ਤਿੱਖਾ ਕਰੋ
ਰੀਕਾਲ ਘੱਟ ਹੈ (ਸੰਬੰਧਿਤ ਦਸਤਾਵੇਜ਼ ਗੁੰਮ ਹਨ)	ਵੱਧ k — ਹੇਠਲੇ ਰੈਂਕ ਵਾਲੇ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਮੌਕਾ ਦਿਓ

RRF ਭਾਰ-ਨਿਰਧਾਰਣ

ਰੈਸੀਪਰੋਕਲ ਰੈਂਕ ਫਿਊਜ਼ਨ ਅਰਥ-ਅਧਾਰਿਤ ਵੈਕਟਰ ਰੈਂਕ ਅਤੇ ਪੂਰੇ-ਟੈਕਸਟ ਖੋਜ ਰੈਂਕ ਲਈ ਬਰਾਬਰ ਭਾਰ ਵਰਤਦਾ ਹੈ:

RRF(d) = 1/(k + rank_vector) + 1/(k + rank_fts)

ਵੱਖ-ਵੱਖ ਭਾਰਾਂ ਨੂੰ ਅਨੁਕੂਲ ਕਰਨ ਲਈ ਕੋਈ ਇਨਵਾਇਰਨਮੈਂਟ ਵੇਰੀਏਬਲ ਮੌਜੂਦ ਨਹੀਂ ਹਨ (MEMORY_RRF_VECTOR_WEIGHT/MEMORY_RRF_FTS_WEIGHT ਮੌਜੂਦ ਨਹੀਂ ਹਨ)।

ਸਾਰਾਂਸ਼ ਰਣਨੀਤੀ (v3.8.16+)

summarization.ts ਮੋਡੀਊਲ (src/lib/memory/summarization.ts) ਯਾਦ ਰੱਖਣ ਦੀ ਸਮਰੱਥਾ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਦੇ ਹੋਏ ਸਰਗਰਮ ਸੈੱਟ ਨੂੰ ਛੋਟਾ ਰੱਖਣ ਲਈ ਪੁਰਾਣੀਆਂ ਮੈਮਰੀਆਂ ਨੂੰ ਸੰਕੁਚਿਤ ਕਰਦਾ ਹੈ।

ਸਾਰਾਂਸ਼ ਕਦੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ

ਟ੍ਰਿਗਰ	ਥ੍ਰੈਸ਼ਹੋਲਡ (ਡਿਫਾਲਟ)
API ਰਾਹੀਂ ਮੈਨੂਅਲ ਟ੍ਰਿਗਰ	ਲਾਗੂ ਨਹੀਂ

ਕਿਸ ਦਾ ਸਾਰਾਂਸ਼ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ

summarization.ts ਤੋਂ ਦੋ ਐਂਟਰੀ ਪੁਆਇੰਟ ਐਕਸਪੋਰਟ ਕੀਤੇ ਜਾਂਦੇ ਹਨ:

summarizeMemories(apiKeyId, sessionId?, maxTokens = 4000) — ਕਿਸੇ ਸੈਸ਼ਨ ਦੀਆਂ ਮੈਮਰੀਆਂ ਨੂੰ ਟੋਕਨ ਬਜਟ ਦੀ ਸੀਮਾ ਅੰਦਰ ਇੱਕੋ ਸਾਰਾਂਸ਼ ਟੈਕਸਟ ਵਿੱਚ ਸੰਕੁਚਿਤ ਕਰਦਾ ਹੈ।
summarizeMemoriesOlderThan(apiKeyId, days, dryRun) — API ਵੱਲੋਂ ਵਰਤਿਆ ਜਾਣ ਵਾਲਾ ਉਮਰ-ਆਧਾਰਿਤ ਸੰਕੁਚਨ: ਇਹ days ਤੋਂ ਪੁਰਾਣੀ ਹਰ ਮੈਮਰੀ ਚੁਣਦਾ ਹੈ, ਉਨ੍ਹਾਂ ਤੋਂ ਇੱਕ ਸੰਕੁਚਿਤ ਸਾਰਾਂਸ਼ ਮੈਮਰੀ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ (dryRun ਦੇ false ਹੋਣ 'ਤੇ) ਮੂਲ ਮੈਮਰੀਆਂ ਮਿਟਾ ਦਿੰਦਾ ਹੈ। ਬਿਨਾਂ ਕੁਝ ਸੋਧੇ ਉਮੀਦਵਾਰ ਸੈੱਟ ਅਤੇ ਕੁੱਲ ਟੋਕਨ ਗਿਣਤੀ ਦੀ ਝਲਕ ਦੇਖਣ ਲਈ dryRun: true ਪਾਸ ਕਰੋ।

ਕੋਈ ਟੈਗ/ਕੀ ਕਲੱਸਟਰਿੰਗ ਪਾਸ ਜਾਂ ਪ੍ਰਤੀ-ਮੈਮਰੀ "ਮੁੱਖ ਬਨਾਮ ਸਾਰਾਂਸ਼ਯੋਗ" ਸਕੋਰਿੰਗ ਨਹੀਂ ਹੈ — ਚੋਣ ਪੂਰੀ ਤਰ੍ਹਾਂ ਉਮਰ ਦੀ ਕੱਟਆਫ਼ ਸੀਮਾ 'ਤੇ ਆਧਾਰਿਤ ਹੈ, ਅਤੇ ਸਾਰਾਂਸ਼ ਟੈਕਸਟ ਹਰ ਉਮੀਦਵਾਰ ਲਈ ਕਿਸਮ-ਪ੍ਰੀਫਿਕਸ ਵਾਲੀ ਇੱਕ ਸੰਕੁਚਿਤ ਲਾਈਨ ਹੁੰਦਾ ਹੈ।

ਸਾਰਾਂਸ਼ ਸ਼ੁਰੂ ਕਰਨਾ

ਸਾਰਾਂਸ਼ ਬਣਾਉਣਾ ਮੈਨੂਅਲ / ਆਪਟ-ਇਨ ਹੈ — autoSummarize ਸੈਟਿੰਗ ਡਿਫਾਲਟ ਤੌਰ 'ਤੇ false ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਕੁਝ ਵੀ ਆਪਣੇ-ਆਪ ਸੰਕੁਚਿਤ ਨਹੀਂ ਹੁੰਦਾ। ਇਸਨੂੰ API ਰਾਹੀਂ ਸ਼ੁਰੂ ਕਰੋ:

curl -X POST http://localhost:20128/api/memory/summarize \
  -H "Authorization: Bearer $OMNIROUTE_KEY"

ਇਸਨੂੰ ਬੰਦ ਰੱਖਣ ਲਈ, ਸਿਰਫ਼ autoSummarize ਨੂੰ ਇਸਦੇ ਡਿਫਾਲਟ (false) 'ਤੇ ਹੀ ਰੱਖੋ।

ਸਾਰਾਂਸ਼ ਦੀ ਗੁਣਵੱਤਾ ਲਈ ਸੁਝਾਅ

ਪਹਿਲਾਂ dryRun ਨਾਲ ਝਲਕ ਦੇਖੋ — summarizeMemoriesOlderThan(..., true) ਉਮੀਦਵਾਰ ਸੂਚੀ ਅਤੇ ਕੁੱਲ ਟੋਕਨ ਗਿਣਤੀ ਵਾਪਸ ਕਰਦਾ ਹੈ, ਤਾਂ ਜੋ ਮੂਲ ਮੈਮਰੀਆਂ ਨੂੰ ਮਿਟਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਤੁਸੀਂ ਪੁਸ਼ਟੀ ਕਰ ਸਕੋ ਕਿ ਕੀ ਮਿਲਾਇਆ ਜਾਵੇਗਾ।
ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਮੈਮਰੀਆਂ ਦਾ ਵੱਡਾ ਭੰਡਾਰ ਹੈ, ਤਾਂ ਘੱਟ ਟ੍ਰੈਫਿਕ ਵਾਲੇ ਸਮੇਂ ਦੌਰਾਨ ਸਾਰਾਂਸ਼ ਚਲਾਓ — LLM ਕਾਲ ਹੌਲੀ ਪ੍ਰਕਿਰਿਆ ਹੈ

# Cron-ਸ਼ੈਲੀ: ਹਰ ਰੋਜ਼ ਸਵੇਰੇ 3 ਵਜੇ ਸਾਰਾਂਸ਼ ਬਣਾਓ
0 3 * * * curl -X POST http://localhost:20128/api/memory/summarize \
  -H "Authorization: Bearer $OMNIROUTE_KEY"

MemoryBackend ਪ੍ਰੋਵਾਈਡਰ ਪੈਟਰਨ

ਪ੍ਰਮਾਣਿਕ ਸਰੋਤ: src/lib/memory/backend.ts, src/lib/memory/genericBackend.ts, src/lib/memory/manager.ts ਟੈਸਟ: src/lib/memory/__tests__/generic-backend.test.ts

MemoryBackend ਪ੍ਰੋਵਾਈਡਰ ਪੈਟਰਨ ਮੌਜੂਦਾ ਮੈਮਰੀ ਇੰਜਣ ਉੱਤੇ ਇੱਕ ਪਲੱਗ ਕਰਨ ਯੋਗ ਬੈਕਐਂਡ ਐਬਸਟ੍ਰੈਕਸ਼ਨ ਪਰਤ ਪੇਸ਼ ਕਰਦਾ ਹੈ। ਇੱਕੋ ਸਟੋਰੇਜ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਨਾਲ ਬੱਝੇ ਰਹਿਣ ਦੀ ਬਜਾਏ, ਮੈਮਰੀ ਸਿਸਟਮ ਹੁਣ ਸੰਰਚਨਾ ਯੋਗ ਪ੍ਰਾਇਮਰੀ/ਫਾਲਬੈਕ ਰੂਟਿੰਗ ਨਾਲ ਕਈ ਬੈਕਐਂਡਾਂ (SQLite, Obsidian, Notion, ਕਸਟਮ HTTP ਬੈਕਐਂਡ) ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ।

ਆਰਕੀਟੈਕਚਰ

┌──────────────────────────────────────────────────────────┐
│                    API ਰੂਟ                               │
│            (src/app/api/memory/route.ts)                  │
└──────────────────────┬───────────────────────────────────┘
                       │
┌──────────────────────▼───────────────────────────────────┐
│                   MemoryManager                           │
│           ਸਿੰਗਲਟਨ ਆਰਕੈਸਟਰੇਟਰ (manager.ts)                │
│                                                          │
│  ਪ੍ਰਾਇਮਰੀ ──► ਬੈਕਐਂਡ A  (ਉਦਾਹਰਨ: SQLite)                │
│  ਫਾਲਬੈਕ   ──► ਬੈਕਐਂਡ B  (ਉਦਾਹਰਨ: Obsidian)              │
│             ਬੈਕਐਂਡ C  (ਉਦਾਹਰਨ: GenericBackend ਰਾਹੀਂ Notion)│
└──────────────────────┬───────────────────────────────────┘
                       │
        ┌──────────────┼──────────────┐
        ▼              ▼              ▼
┌────────────┐ ┌────────────┐ ┌──────────────────┐
│ SQLite     │ │ Obsidian   │ │ GenericMemory    │
│ ਬੈਕਐਂਡ    │ │ ਬੈਕਐਂਡ    │ │ ਬੈਕਐਂਡ (HTTP)    │
└────────────┘ └────────────┘ └──────────────────┘

ਮੁੱਖ ਇੰਟਰਫੇਸ (`backend.ts`)

ਹਰੇਕ ਬੈਕਐਂਡ ਲਈ MemoryBackend ਇੰਟਰਫੇਸ ਨੂੰ ਇੰਪਲੀਮੈਂਟ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ:

interface MemoryBackend {
  readonly id: string;
  readonly displayName: string;

  // CRUD
  create(input: CreateMemoryInput): Promise<Memory>;
  get(id: string): Promise<Memory | null>;
  update(id: string, updates: Partial<...>): Promise<boolean>;
  delete(id: string): Promise<boolean>;
  list(filter: MemoryFilter): Promise<{ data: Memory[]; total: number; byType: Record<string, number> }>;

  // ਖੋਜ
  search(config: SearchConfig): Promise<Memory[]>;

  // ਸਿਹਤ
  health(): Promise<HealthCheckResult>;

  // ਜੀਵਨ-ਚੱਕਰ (ਵਿਕਲਪਿਕ)
  initialize?(): Promise<void>;
  shutdown?(): Promise<void>;
}

MemoryManager (`manager.ts`)

ਸਿੰਗਲਟਨ ਆਰਕੈਸਟਰੇਟਰ ਜੋ:

register(backend) ਰਾਹੀਂ ਬੈਕਐਂਡਾਂ ਨੂੰ ਰਜਿਸਟਰ ਕਰਦਾ ਹੈ — index.ts ਤੋਂ ਬੂਟ ਸਮੇਂ ਕਾਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ
configure(primary, fallbacks) ਰਾਹੀਂ ਪ੍ਰਾਇਮਰੀ + ਫਾਲਬੈਕ ਨੂੰ ਸੰਰਚਿਤ ਕਰਦਾ ਹੈ
ਅਸਫਲਤਾ ਹੋਣ 'ਤੇ ਫਾਲਬੈਕ ਚੇਨ ਨਾਲ CRUD/ਖੋਜ ਨੂੰ ਪ੍ਰਾਇਮਰੀ ਵੱਲ ਰੂਟ ਕਰਦਾ ਹੈ
ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਸਾਰੇ ਬੈਕਐਂਡਾਂ ਦੀ ਸਿਹਤ ਜਾਂਚ ਕਰਦਾ ਹੈ

ਫਾਲਬੈਕ ਵਿਹਾਰ:

ਕਾਰਵਾਈ	ਪ੍ਰਾਇਮਰੀ	ਫਾਲਬੈਕ
`create`	✅ ਸਿਰਫ਼ ਪ੍ਰਾਇਮਰੀ	❌
`get`	✅ ਪਹਿਲਾਂ ਪ੍ਰਾਇਮਰੀ ਅਜ਼ਮਾਓ	✅ ਨਤੀਜਾ null ਹੋਣ 'ਤੇ ਫਾਲਬੈਕ
`update`	✅ ਸਿਰਫ਼ ਪ੍ਰਾਇਮਰੀ	✅ ਫਾਇਰ-ਐਂਡ-ਫਰਗੈਟ ਸਿੰਕ
`delete`	✅ ਸਿਰਫ਼ ਪ੍ਰਾਇਮਰੀ	✅ ਫਾਇਰ-ਐਂਡ-ਫਰਗੈਟ ਸਿੰਕ
`list`	✅ ਸਿਰਫ਼ ਪ੍ਰਾਇਮਰੀ	❌
`search`	✅ ਪਹਿਲਾਂ ਪ੍ਰਾਇਮਰੀ	✅ ਗਲਤੀ ਹੋਣ 'ਤੇ ਫਾਲਬੈਕ

GenericMemoryBackend (`genericBackend.ts`)

ਇੱਕ ਆਮ HTTP ਕਨੈਕਟਰ ਜੋ ਕਿਸੇ ਵੀ REST API ਨੂੰ MemoryBackend ਵਿੱਚ ਅਨੁਕੂਲ ਬਣਾਉਂਦਾ ਹੈ। ਇਨ੍ਹਾਂ ਲਈ ਲਾਭਦਾਇਕ:

Notion — Notion API ਰਾਹੀਂ ਕਨੈਕਟ ਕਰੋ
Obsidian — Obsidian Local REST API ਰਾਹੀਂ ਕਨੈਕਟ ਕਰੋ
ਕਸਟਮ ਬੈਕਐਂਡ — ਕੋਈ ਵੀ ਸੇਵਾ ਜੋ RESTful ਮੈਮਰੀ API ਉਪਲਬਧ ਕਰਾਉਂਦੀ ਹੈ

ਸੰਰਚਨਾ:

interface GenericBackendConfig {
  baseUrl: string;           // ਬੈਕਐਂਡ API ਦਾ ਮੂਲ URL
  apiKey?: string;           // ਪ੍ਰਮਾਣੀਕਰਨ ਲਈ Bearer ਟੋਕਨ
  headers?: Record<string, string>;  // ਕਸਟਮ HTTP ਹੈਡਰ
  timeout?: number;          // ਬੇਨਤੀ ਦੀ ਸਮਾਂ-ਸੀਮਾ (ਡਿਫਾਲਟ: 30000ms)
  backendType?: string;      // ਲੌਗਿੰਗ ਲਈ

  // ਐਂਡਪੌਇੰਟ ਓਵਰਰਾਈਡ (ਡਿਫਾਲਟ REST ਰਵਾਇਤਾਂ ਵਰਤਦੇ ਹਨ)
  endpoints?: {
    search?: string;   // ਡਿਫਾਲਟ: "/memories/search"
    create?: string;   // ਡਿਫਾਲਟ: "/memories"
    list?: string;     // ਡਿਫਾਲਟ: "/memories"
    get?: string;      // ਡਿਫਾਲਟ: "/memories/{id}"
    update?: string;   // ਡਿਫਾਲਟ: "/memories/{id}"
    delete?: string;   // ਡਿਫਾਲਟ: "/memories/{id}"
    health?: string;   // ਡਿਫਾਲਟ: "/health"
  };

  // ਕੁਐਰੀ ਪੈਰਾਮੀਟਰ ਨਾਮ ਮੈਪਿੰਗ
  queryParams?: {
    query?/apiKeyId?/limit?/offset?/strategy?/maxTokens?/type?/sessionId?/orderBy?/orderDir?/options?
  };

  // ਪਾਥ ਪੈਰਾਮੀਟਰ ਨਾਮ ਮੈਪਿੰਗ
  pathParams?: {
    id?/memoryId?
  };
}

ਜਾਣੇ-ਪਛਾਣੇ ਬੈਕਐਂਡ KNOWN_BACKENDS ਵਿੱਚ ਪਹਿਲਾਂ ਤੋਂ ਸੰਰਚਿਤ ਹਨ:

createKnownBackend("obsidian"); // → localhost:27123 ਵੱਲ ਨਿਰਦੇਸ਼ਿਤ GenericMemoryBackend
createKnownBackend("notion"); // → api.notion.com/v1 ਵੱਲ ਨਿਰਦੇਸ਼ਿਤ GenericMemoryBackend

ਬਿਲਟ-ਇਨ ਬੈਕਐਂਡ

SQLiteBackend (`sqliteBackend.ts`)

ਡਿਫਾਲਟ ਪ੍ਰਾਇਮਰੀ ਬੈਕਐਂਡ। src/lib/memory/store.ts ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਮੌਜੂਦਾ SQLite-ਅਧਾਰਿਤ ਮੈਮੋਰੀ ਸਟੋਰ ਨੂੰ ਰੈਪ ਕਰਦਾ ਹੈ। ਬੂਟ ਵੇਲੇ ਆਪਣੇ ਆਪ ਰਜਿਸਟਰ ਹੋ ਜਾਂਦਾ ਹੈ।

import { sqliteBackend } from "./sqliteBackend";
memoryManager.register(sqliteBackend);

ObsidianBackend (`obsidianBackend.ts`)

ਮੌਜੂਦਾ Obsidian ਇੰਟੀਗ੍ਰੇਸ਼ਨ (src/lib/memory/obsidianBackend.ts) ਨੂੰ ਰੈਪ ਕਰਦਾ ਹੈ। Obsidian Local REST API ਰਾਹੀਂ ਇੱਕ Obsidian vault ਨਾਲ ਕਨੈਕਟ ਕਰਦਾ ਹੈ।

ਸੈਟਿੰਗਾਂ

ਮੈਮੋਰੀ ਬੈਕਐਂਡ ਸੈਟਿੰਗਾਂ ਐਪ ਸੈਟਿੰਗਾਂ ਵਾਲੀ ਟੇਬਲ ਵਿੱਚ ਸਟੋਰ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ src/lib/memory/settings.ts ਰਾਹੀਂ ਪ੍ਰਬੰਧਿਤ ਹੁੰਦੀਆਂ ਹਨ:

ਸੈਟਿੰਗ	Env/Config ਕੁੰਜੀ	ਡਿਫਾਲਟ	ਵੇਰਵਾ
ਪ੍ਰਾਇਮਰੀ ਬੈਕਐਂਡ	`memoryPrimaryBackend`	`"sqlite"`	ਪ੍ਰਾਇਮਰੀ ਬੈਕਐਂਡ ਦੀ ID
ਫਾਲਬੈਕ ਬੈਕਐਂਡ	`memoryFallbackBackends`	`[]`	ਕ੍ਰਮਬੱਧ ਫਾਲਬੈਕ ਬੈਕਐਂਡ ID
ਬੈਕਐਂਡ ਸੰਰਚਨਾਵਾਂ	`memoryBackendConfigs`	`{}`	ਹਰ ਬੈਕਐਂਡ ਲਈ ਸੰਰਚਨਾ ਓਵਰਰਾਈਡ

ਸੈਟਿੰਗਾਂ ਨੂੰ normalizeMemorySettings() ਰਾਹੀਂ ਨਾਰਮਲਾਈਜ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ getMemorySettings() ਵਿੱਚ ਕੈਸ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਸ਼ੁਰੂਆਤੀਕਰਨ ਦਾ ਪ੍ਰਵਾਹ

ਐਪ ਬੂਟਸਟਰੈਪ
  → index.ts ਇੰਪੋਰਟ (ਸਾਈਡ-ਇਫੈਕਟ): SQLiteBackend ਨੂੰ ਰਜਿਸਟਰ ਕਰਦਾ ਹੈ
  → ਐਪ ਲਾਈਫਸਾਈਕਲ ਤੋਂ initMemoryBackends() ਕਾਲ ਹੁੰਦਾ ਹੈ:
      1. ਸੈਟਿੰਗਾਂ ਲੋਡ ਕਰੋ (getMemorySettings)
      2. ਪ੍ਰਾਇਮਰੀ + ਫਾਲਬੈਕ ਸੰਰਚਿਤ ਕਰੋ
      3. ਸਾਰੇ ਬੈਕਐਂਡ ਸ਼ੁਰੂ ਕਰੋ (ਹੈਲਥ ਚੈੱਕ)
      4. ਬੇਨਤੀਆਂ ਲਈ ਤਿਆਰ

ਨਵਾਂ ਬੈਕਐਂਡ ਜੋੜਨਾ

src/lib/memory/<name>Backend.ts ਵਿੱਚ MemoryBackend ਇੰਟਰਫੇਸ ਨੂੰ ਇੰਪਲੀਮੈਂਟ ਕਰੋ
src/lib/memory/index.ts ਤੋਂ ਐਕਸਪੋਰਟ ਕਰੋ
ਬੂਟ ਵੇਲੇ memoryManager.register(yourBackend) ਨਾਲ ਰਜਿਸਟਰ ਕਰੋ
ਸੈਟਿੰਗਾਂ ਰਾਹੀਂ ਸੰਰਚਿਤ ਕਰੋ: memoryPrimaryBackend ਨੂੰ ਆਪਣੇ ਬੈਕਐਂਡ ਦੀ ID ਉੱਤੇ ਸੈੱਟ ਕਰੋ
ਹਵਾਲੇ ਵਜੋਂ src/lib/memory/__tests__/generic-backend.test.ts ਨਾਲ ਟੈਸਟ ਕਰੋ

ਉਦਾਹਰਨ: Brain ਬੈਕਐਂਡ

import { createGenericMemoryBackend } from "./genericBackend";

const brainBackend = createGenericMemoryBackend("brain", "BK-Brain", {
  baseUrl: process.env.BRAIN_API_URL || "http://localhost:9099",
  apiKey: process.env.BRAIN_API_KEY,
  endpoints: {
    search: "/api/memory/search",
    create: "/api/memory",
    health: "/api/health",
  },
});

memoryManager.register(brainBackend);

ਤਸਦੀਕ

ਯੂਨਿਟ ਟੈਸਟ

npx vitest run src/lib/memory/__tests__/generic-backend.test.ts --reporter=verbose

ਉਮੀਦ ਕੀਤੀ ਆਉਟਪੁੱਟ: 35 ਟੈਸਟ, ਸਾਰੇ ਪਾਸ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:

ਕੰਸਟਰਕਟਰ (2)
ਹੈਲਥ ਚੈੱਕ (4) — ਸਫਲਤਾ, ਅਸਫਲਤਾ 500, ਨੈੱਟਵਰਕ ਗਲਤੀ, ਲੇਟੈਂਸੀ
ਸ਼ੁਰੂਆਤੀਕਰਨ (2) — ਸਫਲਤਾ, ਅਸਫਲਤਾ
ਬਣਾਉਣਾ (2) — ਡਿਫਾਲਟ ਐਂਡਪੌਇੰਟ, ਕਸਟਮ ਐਂਡਪੌਇੰਟ
ਪ੍ਰਾਪਤ ਕਰਨਾ (4) — ਸਫਲਤਾ, 404 → null, ਗੈਰ-404 ਥ੍ਰੋ, ਕਸਟਮ ਪਾਥ ਪੈਰਾਮੀਟਰ
ਅੱਪਡੇਟ ਕਰਨਾ (2) — ਸਫਲਤਾ, 404 → false
ਮਿਟਾਉਣਾ (2) — ਸਫਲਤਾ, 404 → false
ਸੂਚੀ (2) — ਕੁਐਰੀ ਪੈਰਾਮੀਟਰ, ਕਸਟਮ ਪੈਰਾਮੀਟਰ ਨਾਮ
ਖੋਜ (3) — ਕੁਐਰੀ ਪੈਰਾਮੀਟਰ, ਕਸਟਮ ਐਂਡਪੌਇੰਟ, ਵਿਕਲਪਾਂ ਦੀ ਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ
ਪ੍ਰਮਾਣੀਕਰਨ ਹੈਡਰ (2) — Bearer ਟੋਕਨ, ਕਸਟਮ ਹੈਡਰ
ਫੈਕਟਰੀ (1)

ਟਾਈਪ ਚੈੱਕ

npm run typecheck:core

ਉਮੀਦ: 0 ਗਲਤੀਆਂ।

106 KiB Raw Blame History Unescape Escape

Memory System (ਪੰਜਾਬੀ)

ਆਰਕੀਟੈਕਚਰ

ਇੰਜਣ ਆਰਕੀਟੈਕਚਰ (3-ਪੱਧਰੀ ਰਿਜ਼ੋਲਿਊਸ਼ਨ)

ਐਮਬੈਡਿੰਗ ਸਰੋਤ

ਹਾਈਬ੍ਰਿਡ RRF (k=60)

ਬੈਕਫ਼ਿਲ (ਲੇਜ਼ੀ + ਰੀਇੰਡੈਕਸ)

ਸੈਟਿੰਗਾਂ ਦਾ ਵਿਸਤਾਰ

ਸਟੋਰੇਜ ਪਰਤਾਂ

ਮੁੱਖ: SQLite (memories ਟੇਬਲ)

ਪੂਰੇ-ਟੈਕਸਟ ਦੀ ਖੋਜ (memory_fts virtual table)

ਚੋਣਵਾਂ: Qdrant (vector store tier 2)

Vector quantization (int8 — opt-in, ਦੋਵੇਂ backends)

ਮੈਮੋਰੀ ਦੀਆਂ ਕਿਸਮਾਂ

ਤੱਥ ਕੱਢਣਾ (extraction.ts)

ਪ੍ਰਾਪਤੀ (retrieval.ts)

ਇੰਜੈਕਸ਼ਨ (injection.ts)

ਸੈਟਿੰਗਾਂ (settings.ts)

ਪੁਰਾਣੇ ਫੀਲਡ (ਸਾਰੇ ਵਰਜਨ)

ਨਵੇਂ ਫੀਲਡ (v3.8.6, ਯੋਜਨਾ 21 D9)

ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ (v3.8.6)

ਸੰਖੇਪੀਕਰਨ (summarization.ts)

REST API

ਮੁੱਖ ਮੈਮੋਰੀ ਐਂਡਪੌਇੰਟ (ਮੌਜੂਦਾ + ਅੱਪਡੇਟ ਕੀਤੇ)

ਨਵੇਂ ਮੈਮੋਰੀ ਇੰਜਣ ਐਂਡਪੌਇੰਟ (ਯੋਜਨਾ 21)

ਸੈਟਿੰਗਾਂ ਦੇ ਐਂਡਪੌਇੰਟ

MCP ਟੂਲ (open-sse/mcp-server/tools/memoryTools.ts)

ਡੈਸ਼ਬੋਰਡ (ਮੈਮੋਰੀ ਸਟੂਡੀਓ)

ਟੈਬ: ਮੈਮੋਰੀਆਂ

ਟੈਬ: ਪਲੇਗ੍ਰਾਊਂਡ

ਟੈਬ: ਇੰਜਣ

ਕੈਸ਼ਿੰਗ

ਪਰਦੇਦਾਰੀ ਅਤੇ ਜੀਵਨ-ਚੱਕਰ

ਇਹ ਵੀ ਵੇਖੋ

ਐਮਬੈਡਿੰਗ ਪ੍ਰਦਾਤਾ ਚੁਣਨਾ (v3.8.16+)

ਐਮਬੈਡਿੰਗ ਸਰੋਤ

ਫ਼ੈਸਲਾ-ਵ੍ਰਿੱਖ

ਡਾਟਾਬੇਸ ਅਤੇ API ਸੰਰਚਨਾ

ਲੋਕਲ ਮਾਡਲ (transformers)

LRU ਐਮਬੈਡਿੰਗ ਕੈਸ਼

ਪ੍ਰਦਰਸ਼ਨ ਅੰਕੜੇ

ਤੱਥ ਕੱਢਣ ਦੇ ਪੈਟਰਨ (v3.8.16+)

ਡਿਫਾਲਟ ਪੈਟਰਨ ਸ਼੍ਰੇਣੀਆਂ

ਉਦਾਹਰਨ ਪੈਟਰਨ (ਸਰਲ ਬਣਾਏ ਹੋਏ)

ਕੀ ਕੱਢਿਆ ਜਾਂਦਾ ਹੈ

ਤੱਥ ਕੱਢਣ ਦੀਆਂ ਸੀਮਾਵਾਂ

ਤੱਥ ਕੱਢਣ ਨੂੰ ਕਦੋਂ ਅਸਮਰੱਥ ਕਰਨਾ ਹੈ

ਹਾਈਬ੍ਰਿਡ RRF ਟਿਊਨਿੰਗ (v3.8.16+)

ਫ਼ਾਰਮੂਲਾ

k ਨਤੀਜਿਆਂ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ

ਅਮਲ ਵਿੱਚ k ਨੂੰ ਟਿਊਨ ਕਰਨਾ

k ਨੂੰ ਕਦੋਂ ਬਦਲਣਾ ਹੈ

RRF ਭਾਰ-ਨਿਰਧਾਰਣ

ਸਾਰਾਂਸ਼ ਰਣਨੀਤੀ (v3.8.16+)

ਸਾਰਾਂਸ਼ ਕਦੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ

ਕਿਸ ਦਾ ਸਾਰਾਂਸ਼ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ

ਸਾਰਾਂਸ਼ ਸ਼ੁਰੂ ਕਰਨਾ

ਸਾਰਾਂਸ਼ ਦੀ ਗੁਣਵੱਤਾ ਲਈ ਸੁਝਾਅ

MemoryBackend ਪ੍ਰੋਵਾਈਡਰ ਪੈਟਰਨ

ਆਰਕੀਟੈਕਚਰ

ਮੁੱਖ ਇੰਟਰਫੇਸ (backend.ts)

MemoryManager (manager.ts)

GenericMemoryBackend (genericBackend.ts)

ਬਿਲਟ-ਇਨ ਬੈਕਐਂਡ

SQLiteBackend (sqliteBackend.ts)

ObsidianBackend (obsidianBackend.ts)

ਸੈਟਿੰਗਾਂ

ਸ਼ੁਰੂਆਤੀਕਰਨ ਦਾ ਪ੍ਰਵਾਹ

ਨਵਾਂ ਬੈਕਐਂਡ ਜੋੜਨਾ

ਉਦਾਹਰਨ: Brain ਬੈਕਐਂਡ

ਤਸਦੀਕ

ਯੂਨਿਟ ਟੈਸਟ

ਟਾਈਪ ਚੈੱਕ

106 KiB

Raw Blame History

ਮੁੱਖ: SQLite (`memories` ਟੇਬਲ)

ਪੂਰੇ-ਟੈਕਸਟ ਦੀ ਖੋਜ (`memory_fts` virtual table)

ਤੱਥ ਕੱਢਣਾ (`extraction.ts`)

ਪ੍ਰਾਪਤੀ (`retrieval.ts`)

ਇੰਜੈਕਸ਼ਨ (`injection.ts`)

ਸੈਟਿੰਗਾਂ (`settings.ts`)

ਸੰਖੇਪੀਕਰਨ (`summarization.ts`)

MCP ਟੂਲ (`open-sse/mcp-server/tools/memoryTools.ts`)

ਲੋਕਲ ਮਾਡਲ (`transformers`)

`k` ਨਤੀਜਿਆਂ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ

ਅਮਲ ਵਿੱਚ `k` ਨੂੰ ਟਿਊਨ ਕਰਨਾ

`k` ਨੂੰ ਕਦੋਂ ਬਦਲਣਾ ਹੈ

ਮੁੱਖ ਇੰਟਰਫੇਸ (`backend.ts`)

MemoryManager (`manager.ts`)

GenericMemoryBackend (`genericBackend.ts`)

SQLiteBackend (`sqliteBackend.ts`)

ObsidianBackend (`obsidianBackend.ts`)