Memory search ranks unrelated entities above exact-identifier matches; narrow lookups return oversized aggregate overviews

Open
  • Is something wrong?
#7,413 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
42/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
ai, search

Research direction

Start by tracing openviking_search and openviking_find from the opencode plugin into the server-side ranking and response-building paths. Reproduce the exact-identifier and narrow limit=5, read_content=false cases, then inspect the returned ranking and payload sizes. Done means exact matches are not displaced by unrelated high-confidence results and narrow lookups avoid oversized aggregate overviews.

Written by the indexing model from the issue text.

Description

Summary

Semantic memory search (openviking_search / openviking_find via the opencode plugin) repeatedly returns unrelated entities at high confidence (82–88%) ahead of exact-identifier matches, and narrow lookups can return oversized aggregate overview documents that blow the caller's context budget.

Observed across many real agent sessions on self-hosted desktops (consolidated from open-bot reports shpaw415/open-bot#20, #21, #32, #71, #83 — same defect family, filed independently by different agent sessions over several days).

Repro patterns

  1. Exact identifiers lose to unrelated entities. A query containing precise current-task identifiers (round/contract/counter names, e.g. R42 R43 Capstone distribution module version preflight STATIC PE, or filons_pme_quebec filons-pme-quebec-quotidien reports coverage discord-bridge prompt-shield) returns an unrelated entity ("Tripo API V2") first at 82–88%, with the exact-matching task reports/skills absent or far below. Expected: exact technical-token overlap (or a lexical fallback boost) should keep unrelated entities from presenting as high-confidence guidance.
  2. Oversized aggregate overviews. A narrow lookup with limit=5, read_content=false returns aggregate events-overview documents containing many unrelated historical entries — 50 KB to 122 KB responses that truncate. Expected: token-bounded abstracts and per-hit excerpt limits; read_content=false should not inject full aggregate overviews, and leaf memories should be preferred over aggregate ones for narrow queries.

Impact

Agents either follow unrelated "high-confidence" guidance or burn their context budget on one search call. The client-side workaround (find with small limits, exact-identifier filtering, direct URI reads) helps but cannot fix ranking or server-side response sizing.

Happy to provide anonymized query/result pairs if useful — please tell us what shape helps (no user content or credentials are involved in the reports above).

Dominant language
Python
Stars
41.8k
Forks
3.4k
Avg merge
19h 29m
Merged PRs (30d)
500

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from volcengine/OpenViking

All issues in volcengine/OpenViking

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.