Weaviate

A bigger context window won't fix a broken agentic RAG pipeline. Long contexts can introduce contradictory information, bury relevant tools, and cause later inputs to be ignored. Every retrieved chunk, tool output, instruction, and conversation turn competes for the model's attention. This is why production agentic RAG is really a 𝗰𝗼𝗻𝘁𝗲𝘅𝘁 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴 problem: controlling what information reaches the model, when, and in what form. In our newest Youtube video, Victoria Slocum breaks down the five systems that make up an agentic RAG pipeline: 1️⃣ 𝗤𝘂𝗲𝗿𝘆 𝗔𝘂𝗴𝗺𝗲𝗻𝘁𝗮𝘁𝗶𝗼𝗻 - translating vague, misspelled, or multipart human input into something retrieval and downstream tools can actually use 2️⃣ 𝗥𝗲𝘁𝗿𝗶𝗲𝘃𝗮𝗹 - choosing a chunking strategy that balances precision with enough surrounding context. Small chunks can lose meaning; large chunks consume context and produce noisier embeddings. 3️⃣ 𝗠𝗲𝗺𝗼𝗿𝘆 - separating active short-term context from externally stored long-term memory. Dumping the full conversation history into every request just lets stale details compete with current information. 4️⃣ 𝗧𝗼𝗼𝗹𝘀 - giving the model clear descriptions, schemas, and access to the right tools at the right stage. Many tool failures are actually context engineering failures in disguise. 5️⃣ 𝗔𝗴𝗲𝗻𝘁𝘀 - the decision and orchestration layer connecting everything above. Agents can reformulate queries, select tools, evaluate results, and change strategy, but they also compound every upstream context failure. A better prompt can't repair irrelevant retrieval, contradictory memory, or a tool the model can't find. The video: https://lnkd.in/eJVkySgt

𝗙𝗶𝗿𝗲-𝗮𝗻𝗱-𝗳𝗼𝗿𝗴𝗲𝘁 𝗺𝗲𝗺𝗼𝗿𝘆 𝗳𝗼𝗿 𝗺𝘂𝗹𝘁𝗶-𝗮𝗴𝗲𝗻𝘁 𝗽𝗶𝗽𝗲𝗹𝗶𝗻𝗲𝘀? No blocking. No duplicates. Just continuous learning that works. When you add data to Engram, pipelines run in the background to: 1️⃣ 𝗘𝘅𝘁𝗿𝗮𝗰𝘁 relevant memories matching your configured topics 2️⃣ 𝗧𝗿𝗮𝗻𝘀𝗳𝗼𝗿𝗺 by retrieving existing memories and reconciling them (deduplication, handling preference changes, updating facts) 3️⃣ 𝗖𝗼𝗺𝗺𝗶𝘁 clean, structured memories to Weaviate But how do you deal with a mutli-agent pipeline where 𝘢𝘭𝘭 𝘵𝘩𝘦 𝘢𝘨𝘦𝘯𝘵𝘴 are adding context to the memory system? Take a multi-agent RAG system where a main agent handles conversations and a search agent uses specialized tools. A user asks about comedy movies, but the search agent does a text search on "comedy" instead of filtering by genre. The agent then sends back feedback: "Comedy is a genre, you should filter on the 'genres' property." The information needed to learn is spread across multiple agents and context windows: • Task goal: "User asked for comedy movies" (main agent) • Actions taken: "Called search with near-text query 'comedy'" (search agent) • Feedback: "Should filter on genres property" (main agent) Engram's pipeline: 1. Extracts each piece individually using different 𝘁𝗼𝗽𝗶𝗰𝘀 (task_goal, actions_taken, feedback) 2. 𝗕𝘂𝗳𝗳𝗲𝗿𝘀 collect these memories until all pieces arrive 3. 𝗧𝗿𝗮𝗻𝘀𝗳𝗼𝗿𝗺 step combines them into a single actionable memory: "𝘞𝘩𝘦𝘯 𝘢𝘴𝘬𝘦𝘥 𝘵𝘰 𝘧𝘪𝘯𝘥 𝘮𝘰𝘷𝘪𝘦𝘴 𝘰𝘧 𝘢 𝘱𝘢𝘳𝘵𝘪𝘤𝘶𝘭𝘢𝘳 𝘨𝘦𝘯𝘳𝘦 (𝘦.𝘨., 𝘤𝘰𝘮𝘦𝘥𝘺), 𝘺𝘰𝘶 𝘴𝘩𝘰𝘶𝘭𝘥 𝘧𝘪𝘭𝘵𝘦𝘳 𝘰𝘯 𝘵𝘩𝘦 𝘨𝘦𝘯𝘳𝘦𝘴 𝘱𝘳𝘰𝘱𝘦𝘳𝘵𝘺, 𝘯𝘰𝘵 𝘥𝘰 𝘢 𝘯𝘦𝘢𝘳-𝘵𝘦𝘹𝘵 𝘲𝘶𝘦𝘳𝘺." This memory is now stored in Weaviate and retrieved when starting similar tasks. The agent has actually learned from experience 🔥 Because pipelines run asynchronously, agents can: • Learn from feedback over time without blocking • Combine information spread across multiple conversations • Build up experience that improves future performance • Maintain clean, reconciled memories instead of noisy duplicates With Engram, you can configure memories to be: • 𝗣𝗿𝗼𝗷𝗲𝗰𝘁-𝘄𝗶𝗱𝗲 𝘀𝗰𝗼𝗽𝗲: Agent learns from all users' feedback (trusted teams) • 𝗨𝘀𝗲𝗿-𝘀𝗰𝗼𝗽𝗲𝗱: Each user gets their own personalized agent that learns from their specific usage Agents can then 𝗹𝗲𝗮𝗿𝗻 𝗳𝗿𝗼𝗺 𝗲𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲 and 𝗶𝗺𝗽𝗿𝗼𝘃𝗲 𝗼𝘃𝗲𝗿 𝘁𝗶𝗺𝗲 both individually and across teams, all kept separate and secure through multi-tenancy. Find more in the docs: https://lnkd.in/eUVHj93n

A slow search query doesn't 𝘁𝗲𝗹𝗹 𝘆𝗼𝘂 𝘄𝗵𝗮𝘁 𝘁𝗼 𝗼𝗽𝘁𝗶𝗺𝗶𝘇𝗲. The latency could be coming from filter evaluation, HNSW traversal, compressed-vector rescoring, BM25 scoring, or reading final objects from disk. Each points to a completely different fix. Weaviate now has 𝗽𝗲𝗿-𝗾𝘂𝗲𝗿𝘆 𝗽𝗿𝗼𝗳𝗶𝗹𝗶𝗻𝗴 to make that breakdown concrete. Set one opt-in flag on a search and the timing profile comes back directly on 'response.query_profile'. The coordinating node collects profiles from every participating shard and node, so you get a cluster-wide view in one response. No restart, latency threshold, waiting for the query to be slow again, or manually stitching together logs across nodes. 𝗪𝗵𝗮𝘁 𝘁𝗵𝗲 𝗽𝗿𝗼𝗳𝗶𝗹𝗲 𝗰𝗮𝗻 𝘁𝗲𝗹𝗹 𝘆𝗼𝘂: - objects_took is high: object hydration is disk-bound. Check page-cache misses, result limits, or large payloads. - filters_build_allow_list_took is high: the where filter is expensive. filters_ids_matched helps separate a broad cardinality problem from disk reads. - vector_search_took is high: inspect HNSW layer timings. Layer 0 normally dominates, with ef, dimensionality, and filter strategy as the relevant tuning levers. - knn_search_rescore_took is high: compressed candidates are expensive to rescore, potentially because full-precision vectors are being read from disk. For example, one profile might show: • 48.2ms total • 36.8ms reading objects • 8.4ms in vector search • 2.1ms building the filter allow-list The vector index isn't the bottleneck. Tuning HNSW would be a guess. The profile points toward storage, page cache, result limit, or payload size instead. Slow query logging is still useful for passively catching regressions across a fleet. But when one specific query is slow, profiling gives you the actual stage to investigate. Read the full blog by Byron Voorbach: https://lnkd.in/ebQkqxDa Docs: https://lnkd.in/eHqiiZS6

𝗠𝗮𝗻𝗮𝗴𝗲𝗱 𝗪𝗲𝗮𝘃𝗶𝗮𝘁𝗲 𝗶𝘀 𝗻𝗼𝘄 𝗮𝘃𝗮𝗶𝗹𝗮𝗯𝗹𝗲 𝗼𝗻 𝗗𝗶𝗴𝗶𝘁𝗮𝗹𝗢𝗰𝗲𝗮𝗻 𝗶𝗻 𝗽𝘂𝗯𝗹𝗶𝗰 𝗽𝗿𝗲𝘃𝗶𝗲𝘄! DigitalOcean handles the infrastructure around Weaviate: • Provisioning and security • Automated daily backups • Patching and version upgrades • High availability and storage autoscaling • Point-in-time cluster forks • Performance insights and logs in the DigitalOcean Control Panel It runs the unmodified open-source Weaviate engine (v1.37.1 at launch), so existing Python, JS/TS, Java, and C# clients remain compatible. Easily spin up a Weaviate cluster without operating it yourself on Kubernetes or VMs, and get building! Docs: https://lnkd.in/eMGYUv2b

Most AI agents get 𝗱𝘂𝗺𝗯𝗲𝗿 as they learn more. (There's a better way) We just released a demo of 𝗘𝗻𝗴𝗿𝗮𝗺 that shows exactly how intelligent memory management should work. Try it here: https://lnkd.in/eG5_d3Yi Most agentic chatbots handle memory in one of two broken ways: • Dump the 𝗲𝗻𝘁𝗶𝗿𝗲 𝗰𝗼𝗻𝘃𝗲𝗿𝘀𝗮𝘁𝗶𝗼𝗻 𝗶𝗻𝘁𝗼 𝗰𝗼𝗻𝘁𝗲𝘅𝘁 every time (problems: cost, degraded performance, no consistency across conversations) • 𝗦𝘁𝗼𝗿𝗲 𝗲𝘃𝗲𝗿𝘆 𝗺𝗲𝘀𝘀𝗮𝗴𝗲 for retrieval (problems: noise, contradictions, and facts that changed over time) 𝗘𝗻𝗴𝗿𝗮𝗺 takes a completely different approach: 𝗮𝗰𝘁𝗶𝘃𝗲𝗹𝘆 𝗺𝗮𝗶𝗻𝘁𝗮𝗶𝗻𝗶𝗻𝗴 𝗺𝗲𝗺𝗼𝗿𝗶𝗲𝘀 instead of just piling them up. As conversations happen, Engram runs asynchronous pipelines in the background that: 1. Extract relevant information matching your configured topics 2. Reconcile new memories with existing ones (handling duplicates, preference changes, evolving facts) 3. Store structured, scoped memories in Weaviate for semantic retrieval This solves the core problem with naive approaches. Rather than cramming ever-growing context into your LLM (causing degradation, latency, and cost issues) or storing raw conversations (which are noisy and contradictory), Engram actively maintains clean, structured memories that can update or be deleted over time. The result is agentic chatbots that 𝘢𝘤𝘵𝘶𝘢𝘭𝘭𝘺 improve with each interaction, learning from experience without context pollution.

You've typed the perfect search query and gotten completely useless results. Here's what modern product discovery looks like when it actually works. The Weaviate Playground now has an ecommerce demo, and it's a great example of what you can build with vector search. 𝗪𝗲𝗖𝗼𝗺𝗺𝗲𝗿𝗰𝗲 lets you type a keyword, a mood, or even just a vibe - and it routes your query through BM25, semantic vector search, or a hybrid blend automatically. Results come back with real-time faceted filtering by category, brand, and price. Each product page also surfaces similar items via near-object vector search. That means the same collection is driving both discovery and recommendation - no extra infrastructure needed. Here's what's going on under the hood: 1. 𝗞𝗲𝘆𝘄𝗼𝗿𝗱 𝗾𝘂𝗲𝗿𝗶𝗲𝘀 → BM25 ranks results by term frequency and relevance 2. 𝗠𝗼𝗼𝗱/𝘃𝗶𝗯𝗲 𝗾𝘂𝗲𝗿𝗶𝗲𝘀 → vector search finds semantically similar products 3. 𝗛𝘆𝗯𝗿𝗶𝗱 → blends both for the best of both worlds 4. 𝗣𝗿𝗼𝗱𝘂𝗰𝘁 𝗽𝗮𝗴𝗲𝘀 → near-object search pulls similar items automatically Ready to build your own? Copy the prompt, spin it up on the 𝗳𝗿𝗲𝗲 𝘁𝗶𝗲𝗿 in Weaviate Cloud, and go from zero to working e-commerce search in minutes. See the demo here: https://lnkd.in/eFdRdHJ5

Most developers pick the wrong search method. We built a demo so you can see exactly why. Our keyword vs vector search demo in the Weaviate Playground lets you explore and compare all three search types side-by-side on real datasets. Here's what each search type does: 𝗕𝗠𝟮𝟱 (𝗞𝗲𝘆𝘄𝗼𝗿𝗱 𝗦𝗲𝗮𝗿𝗰𝗵) • Matches exact words and phrases using TF-IDF-style scoring • Rarer terms that appear frequently score higher • Perfect for names, specific phrases, and precise queries • But... it misses synonyms and related concepts 𝗩𝗲𝗰𝘁𝗼𝗿 𝗦𝗲𝗮𝗿𝗰𝗵 (𝗦𝗲𝗺𝗮𝗻𝘁𝗶𝗰 𝗦𝗲𝗮𝗿𝗰𝗵) • Uses dense embeddings to capture meaning • "Car" and "automobile" match even without shared words • Understands context and semantic relationships • But... can sometimes underweight exact lexical matches 𝗛𝘆𝗯𝗿𝗶𝗱 𝗦𝗲𝗮𝗿𝗰𝗵 • Runs both searches in parallel and merges results • Uses reciprocal rank fusion to combine the best of both • Gets you strong keyword hits PLUS semantic neighbors • The best of both worlds for most use cases! The demo includes multiple datasets - landmarks, movies, science, games, and Pokemon - so you can test queries like "where gladiators used to fight" or "ancient city buried under volcanic ash" and see how each search type performs. Or, simply copy the prompt and try it on your own data! See the demo here: https://lnkd.in/eVg49YbX