Skip to main content

goodmem-wandb

GoodMem retrieval for Weights & Biases Weave.

Every retrieval is a traced Weave op, so a RAG call shows up in the Weave UI with its query, its latency, each hit's score and what kind of score that is, and any degradation the server reported. The same retriever can be wrapped as a weave.Model and measured with weave.Evaluation.

pip install goodmem-wandb

Trace a retrieval

import weave
from goodmem_wandb import GoodMemRetriever

weave.init("my-project")

retriever = GoodMemRetriever(space_name="docs")   # credentials from the environment
result = retriever.search("how do I rotate an API key?")

for hit in result["hits"]:
    print(hit["score"], hit["score_kind"], hit["chunk_text"][:80])

search() returns:

Key What it is
hits chunk_id, chunk_text, memory_id, space_id, source, score, score_kind, metadata — in the server's order
score_kind "vector" or "reranker". They are different scales; see below
statuses Server statuses that indicate a real problem, [] when clean
partial True when the server reported a real problem during this retrieval — with or without hits. An empty hits with partial=True is a failed search, not a miss
abstract_reply The server-generated summary, only when llm_id is set
space_ids Which spaces were actually searched

Credentials come from GOODMEM_BASE_URL and GOODMEM_API_KEY, or as constructor keywords:

GoodMemRetriever(space_name="docs", base_url="https://goodmem.example.com",
                 api_key="gm_…")

verify_ssl defaults to on and exists for a local server with a self-signed certificate only; no example here turns it off.

They are deliberately not Weave fields. Weave publishes an object's pydantic fields verbatim to the trace server and its redaction helper does not run on that path, so a field named api_key on a weave.Model would be uploaded to W&B in plaintext. This package keeps the connection on a private attribute; tests/test_regressions.py asserts it.

Evaluate a retrieval configuration

import weave
from goodmem_wandb import GoodMemRetrievalModel, RecallAtK, MRR, FactRecall, RetrievalHealth

weave.init("my-project")

dataset = [
    {"question": "how do I rotate an API key?",
     "expected_memory_ids": ["01a0…"],
     "expected_text": "rotate the key from the console"},
]

baseline = GoodMemRetrievalModel(space_name="docs", limit=5)
reranked = GoodMemRetrievalModel(space_name="docs", limit=5, reranker_id="…")

evaluation = weave.Evaluation(
    dataset=dataset,
    scorers=[RecallAtK(k=5), MRR(), FactRecall(), RetrievalHealth()],
)
evaluation.evaluate(baseline)
evaluation.evaluate(reranked)   # compare the two in the Weave UI

Changing any field on the model versions it, so the two runs are directly comparable. The credentials are not fields, so they are not part of the version either.

Scorer Measures
RecallAtK(k=5) Fraction of expected_memory_ids in the top k distinct memories (several chunks of one memory are one document)
MRR() Reciprocal rank of the first expected memory; 0.0 if none was retrieved
FactRecall() Whether a known fact actually appears in the retrieved text — survives re-chunking and re-embedding, unlike an id metric
RetrievalHealth() Whether the retrieval was complete, so a silently-degraded run is visible as its own metric rather than only as a recall drop

None of them score on the raw relevance number, because that number does not mean the same thing between two configurations.

Scores

GoodMem returns two different things in the same field, and this matters:

Range observed on a live server Best match is
Vector score negative, e.g. -0.6154 … -0.3873 the lowest number
Reranker score 0.2105 … -0.1081 — also goes negative the highest number

Those are real numbers from one capture over the same three memories. So:

  • results keep the server's order and are never re-sorted here;
  • score_kind on every hit says which scale you are looking at;
  • min_score is only applied when reranker_id is set, and is applied client-side where you can see it, never sent as the server's relevance_threshold.

Even with a reranker the scale is model-dependent: on the same documents Voyage rerank-2.5 scored 0.27..0.93 and Jina jina-reranker-v3 scored -0.14..0.43. A min_score tuned for one empties the other, so when a threshold removes every hit the retriever warns and names the observed range. Calibrate min_score for the reranker you use; there is no default.

Filtering

retriever = GoodMemRetriever(space_name="docs", metadata_filter={"category": "billing"})
retriever.search("refunds", metadata_filter={"lang": "en"})   # AND-ed per call

Values are quoted for the GoodMem filter grammar (backslash escaping, verified against a live server; control characters are refused rather than mangled). For anything more complex, pass an expression directly:

GoodMemRetriever(space_name="docs",
                 filter="CAST(val('$.year') AS TEXT) = '2026'")

Attaching to a space by name

GoodMemRetriever(space_name="docs", embedder_id="…")                    # reuse or fail
GoodMemRetriever(space_name="docs", embedder_id="…", create_space=True) # or create it

Attach-by-name is idempotent reuse: an existing space whose embedder matches is reused; one built on a different embedder is an error, because retrieving across mismatched embedders returns plausible-looking nonsense. A name that matches more than one space is also an error — GoodMem does not require space names to be unique. This matches the ActivePieces connector.

Sensitive corpora

trace_chunk_text=False keeps chunk ids, scores and statuses in the trace but leaves the retrieved text out of it.

Development

pip install -e ".[dev]"
ruff check src tests examples && mypy && pytest -m "not integration"

The offline suite replays NDJSON captured from a live GoodMem server (v1.0.320) through the real SDK decoders, so the wire format is never invented. The live suite needs a server and is skipped without one:

GOODMEM_BASE_URL=… GOODMEM_API_KEY=… GOODMEM_EMBEDDER_ID=… \
  GOODMEM_RERANKER_ID=… GOODMEM_VERIFY_SSL=0 \
  pytest -m integration

GOODMEM_RERANKER_ID is optional — the reranker tests skip without it. GOODMEM_VERIFY_SSL=0 is for a local server with a self-signed certificate.

There is no default credential anywhere in this repository.

License

MIT

Release files for goodmem-wandb 0.2.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for goodmem-wandb 0.2.0
File Size Uploaded
goodmem_wandb-0.2.0.tar.gz 28.5 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for goodmem-wandb 0.2.0
File Interpreter ABI Platform
goodmem_wandb-0.2.0-py3-none-any.whl Python 3 none any Details

Total release size: 48.6 kB

Release files / goodmem_wandb-0.2.0.tar.gz

Download URL goodmem_wandb-0.2.0.tar.gz
Size 28.5 kB
Tags Source
SHA-256 checksum
How to use checksums
563c9d89eda2dcdd14cdf64a0dc7ef0926102165b8b604031a1b5dfc439a1f85
BLAKE2b-256 checksum
How to use checksums
1e9c46f14f03f3e49957cd418b0b7a22296c28901c528da6b934db78d5ce01aa
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 24, 2026.

Transparency log

Release files / goodmem_wandb-0.2.0-py3-none-any.whl

Download URL goodmem_wandb-0.2.0-py3-none-any.whl
Size 20.2 kB
Tags Python 3
SHA-256 checksum
How to use checksums
e1457cd58f7381e80a2b993ed6f51410cafd81c03a783d8b02d9e3170686a3ba
BLAKE2b-256 checksum
How to use checksums
07cd8c20b88bad41c0e0a6e21bfe3aa9a42c4fb14799972ea8a6473cc0ad8eb8
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Sep 24, 2026.

Transparency log

Release history Release notifications | RSS feed

This release

0.2.0 This release

2 release files

0.1.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page