Agent Know-How

TIGRAG constructs its knowledge graph from token co-occurrence statistics (a sliding-window count over the corpus) rather than an LLM extraction pipeline, then pairs the graph with neural reranking for multi-hop retrieval.

It reports matching or beating dense and LLM-extracted GraphRAG on multi-hop QA while cutting indexing time, inference latency, and prompt size. That weakens the standard objection that graph construction is too slow and costly for production.

Cassie Shum's InfoQ talk on GraphRAG names three gaps where traditional vector retrieval structurally fails: global context, multi-hop reasoning, and provenance. The proposed fix is a semantically structured knowledge graph that pushes orchestration logic down into the data layer.

The graph-vs-vector choice is about what similarity search cannot answer, not taste. If your questions span documents or need a traceable source, plan for structure in the data, not more prompt logic on top.

An InfoQ practitioner article describes the limits of RAG pipelines built on vector search alone, and an internal omni-search application that combines BM25 lexical results and vector results with Reciprocal Rank Fusion (RRF).

Hybrid dense-plus-lexical retrieval, usually followed by a rerank pass, is the production floor. Pure top-k similarity misses exact terms, IDs, and names that keyword search catches.

Amazon DynamoDB now stores embeddings next to application data and runs approximate nearest-neighbor queries through a SearchVectors API, with filtered similarity search and configurable indexes. Reported specifics: up to 4,096 dimensions, Euclidean/cosine/dot-product distance, and single-digit-millisecond latency at a claimed trillions-of-vectors scale.

It removes the sync-two-systems overhead for teams already on DynamoDB. The trade is a new billing surface: cost is metered per byte for data written, data processed per search, and data stored, on top of standard DynamoDB charges.

Google's AlloyDB packages vector and hybrid search, natural-language-to-SQL, and AI functions that call foundation models such as Gemini directly on database rows, with new performance and cost improvements to those functions.

A general-purpose operational database now doubles as the retrieval layer, so structured filters and similarity search run in one query against the system of record.

AWS's AgentCore Memory now carries metadata across configuration, ingestion, and retrieval, so recall can be narrowed by fields such as tenant, document type, or time range before similarity ranking. AWS frames it for multi-agent and multi-tenant architectures.

Metadata filters are the practical complement to hybrid retrieval: they enforce tenant boundaries and cut the candidate set deterministically instead of trusting embedding distance to keep tenants apart.

NVIDIA's Nemotron 3 Embed line ranks #1 overall on RTEB, a multilingual, multi-domain retrieval benchmark, at 78.5% for the flagship 8B model. The smaller 1B variant cuts its predecessor's error rate by 27%.

Swapping the embedder raises the ceiling of every retrieval architecture built on it without touching the index, chunking, or rerank. Better retrieval also means an agent finds evidence in fewer search calls, so it is a cost and latency lever as well as an accuracy one.

Target retrieves similar historical marketing campaigns for forecasting with embeddings plus vector search plus LLM ranking, replacing a rule-based workflow. It reports 75% top-1 and 100% top-3 coverage, and feeds campaign outcomes back to refine retrieval.

A production example where the gain comes from how records are embedded and reranked, and from a feedback loop, not from the choice of vector store.

Embedding a structured metadata record means serializing its fields into a string, which forces a field order. A standard fine-tuned encoder loses 7.4 nDCG@10 points when the index is rebuilt under a different field order, because it learns absolute position instead of field labels. The paper proposes permutation-invariant fine-tuning to remove that dependence.

If you embed catalog or schema records, serialization is part of the retrieval model. Fix it before tuning the index.

FERNme grows an agent memory graph using fuzzy edges and a Hebbian co-occurrence rule to create memory tags. The structure comes from what appears together, not from embeddings, and updates take roughly zero LLM calls.

Keeping the LLM out of the write path as well as the read path removes the per-turn token cost most memory layers pay to extract facts. It is a hobby-scale project, so treat it as a design idea, not a benchmark.

raidho, a Show HN coding agent, replaces RAG-style nearest-neighbour lookup with vector-symbolic architecture (VSA) memory: facts are combined with algebraic binding and bundling operations rather than retrieved by embedding distance.

It is an early, single-project signal. It belongs to a wider argument that exact, structured recall can beat fuzzy similarity for some agent workloads.

Memharness stores agent memory bi-temporally in a single SQLite file: each fact records when it was true and when it was recorded, so recall leans on time and structure instead of embeddings.

For questions like "what did we believe last Tuesday", a relational store with time columns gives an exact answer that similarity search cannot, and it runs with no separate service to operate.