Database selection and deployment tradeoffs
Choosing Qdrant, Pinecone, pgvector, MongoDB, LanceDB, Chroma, SQLite, or managed versus embedded/local deployments by workload.
40%
Best tweets about Vector Databases
50 Best Tweets About Vector Databases (2026)
Browse the best tweets about vector databases, covering embeddings, indexing, retrieval, Pinecone, Weaviate, Qdrant, Milvus, benchmarks, and architecture.
Vector database architecture, indexing, filtering, retrieval quality, benchmarks, scaling, operations, and concrete implementation tradeoffs.
- Creators
- 44
- Updated
Original Xholic analysis
What 50 top Vector Databases posts reveal
The conversation treats retrieval as a system-design problem: vector databases are one option, while indexing, filtering, document structure, hybrid methods, write patterns, and operational simplicity shape workload fit.
- Dominant tone
- Positive
- Median score
- 22.9
- Leading format
- Announcement
- Recent posts
- 46%
80% of posts
All-time engagement
62% of posts
Published in 90 days
Conversation map
The themes creators return to
Retrieval quality and RAG design
Chunking, contextualized representations, source authority and freshness, distractor resistance, grounding, and retrieval evaluation.
40%
Indexing, quantization, and compression
HNSW, IVF, FAISS-related indexing, GPU acceleration, vector quantization, and TurboVec-style memory-efficient indexes.
34%
Operations, scaling, and updates
Dynamic ingest, read/write workload behavior, sharding, reindexing, embedding-model migrations, reliability, and zero-downtime maintenance.
24%
Vector database fundamentals
Embedding storage, ANN similarity search, distance metrics, metadata, and the write/read path of vector databases.
24%
Filtering, hybrid, and multimodal retrieval
Metadata filtering, BM25-plus-vector hybrid retrieval, reranking, reciprocal-rank fusion, and image/page-based embedding retrieval.
22%
Alternatives to vector search
BM25, grep, hierarchical document indexes, structural reasoning, and graph traversal as alternatives or complements to semantic similarity.
16%
GraphRAG and structural retrieval
Multi-hop graph traversal for agent memory, document relationships, and database-schema join-path discovery.
8%
Tone and stance
Sentiment Positive leads
Author posture Supportive leads
Performance benchmark
- Median likes
- 61
- Median reposts
- 11
- Median replies
- 6
- Median views
- 4.9K
Posts with media make up 74% of this collection. Their median all-time score is 27.0, compared with 2.85 for text-only posts.
Format mix
- Announcement 62% · score 19.1
- List 38% · score 30.9
Consensus and debate
Where creators agree, and where they do not
Shared view
Retrieval design extends beyond similarity
Posts frame chunking, metadata, reranking, hybrid retrieval, and context assembly as parts of RAG quality rather than treating vector search as a standalone component.
Shared view
Workload should drive database choice
Selection guidance distinguishes local or embedded deployments, managed services, Postgres-based stacks, and read/write patterns rather than proposing one universal vector store.
Shared view
Metadata and structure matter for relevance
Posts highlight metadata such as version, clearance, and source authority, as well as document hierarchy and graph relationships, as signals beyond plain semantic similarity.
Open debate
Vector search versus lexical and structural retrieval
Some posts advocate ANN-based semantic retrieval, while others argue that BM25, grep, hierarchical document indexes, or graph traversal can be better suited to particular tasks or corpora.
Open debate
Specialist database versus simpler stack
Qdrant is presented with filtering, quantization, sharding, hybrid search, and managed or self-hosted options; another post presents pgvector as a way to avoid an additional service when Postgres fits the workload.
Open debate
Vector retrieval’s fit varies by data shape
Posts describe hierarchy-based retrieval for complex professional documents and graph paths for schemas, while other examples use vectors for icon correction, local notes, and historical-memory retrieval.
What performs
Patterns behind standout posts
Compression is a prominent systems theme
TurboVec posts report fitting 10 million vectors into 4GB rather than 31GB, with no training or rebuild requirement. Supplied analytics also identify indexing and compression as a 34% theme.
Dynamic indexing is framed as an operational need
Flash-KMeans is presented as enabling dynamic re-indexing as data changes, while other posts describe online ingest, incremental updates, and a zero-downtime embedding-model migration pattern.
Media posts had a higher median score than text-only posts
Deterministic analytics report 37 media posts (74%), with a median all-time score of 26.988 for media posts versus 2.849 for text-only posts.
Engagement outliers covered both RAG and retrieval alternatives
The largest supplied outlier was an AI-engineer roadmap. Other top outliers covered BM25, hierarchy-based retrieval, a critique of vector search, and vector-database fundamentals.
Statistical standouts
- View standout post 1 Score 3477.9 · 152.07× median
- View standout post 2 Score 733.1 · 32.06× median
- View standout post 3 Score 594.2 · 25.98× median
- View standout post 4 Score 533.9 · 23.34× median
- View standout post 5 Score 353.6 · 15.46× median
Creator landscape
Who shapes this conversation
The five most represented creators account for 20% of the selected posts.
-
1. Avi Chawla
@_avichawla
2 posts
-
2. Akshay 🚀
@akshay_pachaar
2 posts
-
3. GitHub Projects Community
@GithubProjects
2 posts
-
4. Tech with Mak
@techNmak
2 posts
-
5. DEV Community
@ThePracticalDev
2 posts
-
6. Tomasz Tunguz
@ttunguz
2 posts
Top voices paired technical topics with implementation detail
Akshay Pachaar’s two posts cover BM25 and GPU k-means; Avi Chawla’s cover graph-based schema retrieval and contextualized RAG units. These examples combine technical claims with implementation framing.
Practical deployment narratives recur
Posts provide deployment-specific perspectives: Qdrant’s managed or self-hosted positioning, unified MongoDB memory, and in-process retrieval for a 250K-item corpus.
Conversation is broadly supportive but not uniform
Deterministic analytics label 70% of posts supportive and 14% critical. Examples of critical posts challenge default vector-search assumptions through BM25, hierarchy-based retrieval, and grep-based evaluation.
Since the previous snapshot
What changed since Aug 12, 2026
- 66% of the selected posts remained.
- The creator count changed by +5.
- The leading sentiment remained stable.
How this analysis was made
Themes, sentiment, stance, and post format are classified per tweet. All counts, shares, medians, creator concentration, freshness, and performance comparisons are then calculated directly from the published snapshot.
Xholic's all-time score compares engagement while accounting for reach, post age, and creator consistency. It is used for relative comparisons within this collection.
This report analyzes the exact 50-post snapshot shown below. AI identifies editorial categories and drafts explanations; all statistics are calculated from the snapshot, and every narrative claim is checked against cited posts before publication.
Best Vector Databases tweets
Top Vector Databases tweets from 44 creators
Ranked 01–50
- 01
@DeRonin_ ·
How to become AI engineer in next 6 months: By the end, you want to be able to: - build LLM apps end-to-end - use APIs from OpenAI / Anthropic / open-source stacks - design prompts and context properly - add tool calling and structured outputs - deploy real projects So, let’s discuss your roadmap month by month Month 1: Get solid enough in coding and fundamentals What to learn: - Python really well - Git + GitHub - CLI / terminal basics - JSON, APIs, HTTP, async basics - basic SQL - basic data handling with pandas - virtual environments, package management, error handling - FastAPI or Flask Month 2: Master LLM app development What to learn: - prompting fundamentals - system vs user instructions - structured outputs / JSON schemas - function/tool calling - streaming responses - conversation state - cost / latency / token basics - failure handling - prompt injection awareness Month 3: Learn RAG properly What to learn: - embeddings - chunking - vector databases - metadata filtering - reranking - retrieval quality issues - hallucination reduction - citations and grounding Month 4: Agents, tools, workflows, evals - agent loops - tool selection - state management - retries - when NOT to use agents - multi-step workflows - evaluation harnesses - task success metrics Month 5: Deployment, product thinking, and reliability What to learn: - FastAPI production patterns - Docker - background jobs - queues - auth + API key security - logging - observability - prompt/version management - eval dashboards - cost monitoring - rate limits - caching Month 6: Specialize and become hireable these knowledge and skills you gained can be applied in three directions you need to choose one of them and focus on practice although everything mentioned above is also best learned purely through practice Direction 1: AI product engineer Best if you want startup jobs fast Focus on: - LLM apps - RAG - agents - deployment - product UX Direction 2: Applied ML / LLM engineer Focus on: - fine-tuning - when to fine-tune vs prompt - evaluation - inference optimization - open-source models - training pipelines Direction 3: AI automation engineer Focus on: - workflow orchestration - business process automation - multi-tool systems - CRM, docs, email, support, ops use cases This roadmap will help you go through a practical path, and the key is to study each of these points and then test them in real work By month six, you will already have several built products or examples of completed tasks And it will be much easier to get a job as an AI engineer Save it so you don't lose it and can return to study later
- 02
@akshay_pachaar ·
Stop using vector search everywhere! A 30-year-old algorithm with zero training, zero embeddings, and zero fine-tuning still powers Elasticsearch, OpenSearch, and most production search systems today. It's called BM25. Let me explain what makes it so powerful: Imagine you're searching for "transformer attention mechanism" in a library of ML papers. BM25 asks three simple questions: "How rare is this word?" Every paper contains "the" and "is", which makes it useless. But "transformer" is specific and informative. BM25 boosts rare words and ignores the noise. → This is IDF(qᵢ) in the formula "How many times does it appear?" If "attention" appears 10 times in a paper, that's a good sign. But 10 vs 100 occurrences won't make much difference. BM25 applies diminishing returns. → This is f(qᵢ, D) combined with k₁ that controls saturation "Is this document unusually long?" A 50-page paper will naturally contain more keywords than a 5-page paper. BM25 levels the playing field so longer documents don't cheat their way to the top. → This is |D|/avgdl controlled by parameter b Three questions. No neural networks. No training data. Just elegant math (refer to the image below) The best part: BM25 excels at exact keyword matching - something embeddings often struggle with. If your user searches for "error code 5012," embeddings might return semantically similar results. BM25 will find the exact match. This is why hybrid search exists. Top RAG systems today combine BM25 with vector search. You get the best of both worlds: semantic understanding AND precise keyword matching. So before you throw GPUs at every search problem, consider BM25. It might already solve your problem, or make your semantic search even better when combined.
- 03
@techNmak ·
Someone removed the vector database from RAG and got better results. Much better. Here's what traditional RAG actually does under the hood: it chunks your document into pieces, embeds those pieces into vectors, and retrieves based on semantic similarity. The assumption is that similar text = relevant text. That assumption breaks completely for professional documents. When you ask "what were the debt trends in Q3?", vector search returns chunks that look similar to that question. But the actual answer might be buried in an appendix, referenced across three sections, in a part of the document that shares zero semantic overlap with your query. Traditional RAG never finds it. Similarity ≠ relevance. PageIndex was built around that insight. Inspired by AlphaGo, it builds a hierarchical tree index from your document - an intelligent table of contents optimized for LLM reasoning. Then it navigates that tree the way a human expert would. Not pattern matching. Reasoning. "Debt trends are usually in the financial summary or Appendix G, let's look there." What disappears: → No vector DB to build or maintain → No arbitrary chunking that breaks cross-section context → No opaque retrieval you can't explain or trace What you get: → Retrieval traceable to exact page and section references → Multi-step reasoning across document structure → Works on financial reports, legal filings, regulatory documents The benchmark: → PageIndex: 98.7% on FinanceBench → Perplexity: 45% → GPT-4o: 31% Open source.
- 04
@micLivs ·
i call BS on vector search for most use cases. everyone is building memory infrastructure. embeddings, vector stores, PageRank, spreading activation. co-occurrence learning. dampening pipelines. i gave @badlogicgames pi napkin, a CLI for obsidian vaults. BM25 search. TF-IDF based context overview. HotpotQA (250 questions, multi-hop): - 99.8% recall (vs 90% Ori, 29% Mem0) - 79.6% answer F1 (vs 41% Ori, 19% Mem0) haiku 4.5, markdown files on disk, no embeddings, no vector DB, no cloud. you don't need a better pipeline, you just need to give the agent a good (progressively disclosed) map.
- 05
@Aurimas_Gr ·
Fundamentals of a 𝗩𝗲𝗰𝘁𝗼𝗿 𝗗𝗮𝘁𝗮𝗯𝗮𝘀𝗲. With the rise of GenAI, Vector Databases skyrocketed in popularity. The truth - Vector Databases are also useful outside of a Large Language Model context. When it comes to Machine Learning, we often deal with Vector Embeddings. Vector Databases were created to perform specifically well when working with them: ➡️ Storing. ➡️ Updating. ➡️ Retrieving. When we talk about retrieval, we refer to retrieving set of vectors that are most similar to a query in a form of a vector that is embedded in the same Latent space. This retrieval procedure is called Approximate Nearest Neighbour (ANN) search. A query here could be in a form of an object like an image for which we would like to find similar images. Or it could be a question for which we want to retrieve relevant context that could later be transformed into an answer via a LLM. Let’s look into how one would interact with a Vector Database: 𝗪𝗿𝗶𝘁𝗶𝗻𝗴/𝗨𝗽𝗱𝗮𝘁𝗶𝗻𝗴 𝗗𝗮𝘁𝗮. 1. Choose a ML model to be used to generate Vector Embeddings. 2. Embed any type of information: text, images, audio, tabular. Choice of ML model used for embedding will depend on the type of data. 3. Get a Vector representation of your data by running it through the Embedding Model. 4. Store additional metadata together with the Vector Embedding. This data would later be used to pre-filter or post-filter ANN search results. 5. Vector DB indexes Vector Embedding and metadata separately. There are multiple methods that can be used for creating vector indexes, some of them: Random Projection, Product Quantization, Locality-sensitive Hashing. 6. Vector data is stored together with indexes for Vector Embeddings and metadata connected to the Embedded objects. 𝗥𝗲𝗮𝗱𝗶𝗻𝗴 𝗗𝗮𝘁𝗮. 7. A query to be executed against a Vector Database will usually consist of two parts: ➡️ Data that will be used for ANN search. e.g. an image for which you want to find similar ones. ➡️ Metadata query to exclude Vectors that hold specific qualities known beforehand. E.g. given that you are looking for similar images of apartments - exclude apartments in a specific location. 8. You execute Metadata Query against the metadata index. It could be done before or after the ANN search procedure. 9. You embed the data into the Latent space with the same model that was used for writing the data to the Vector DB. 10. ANN search procedure is applied and a set of Vector embeddings are retrieved. Popular similarity measures for ANN search include: Cosine Similarity, Euclidean Distance, Dot Product. How are you using Vector DBs? Let me know in the comment section!
- 06
@nikesharora ·
Summary: I spent time trying to figure out this orchestration layer problem, can we design a multi model architecture in the long term. The more I dug in the more I understand that trying to build an abstracted layer is hard. As agentic activities increase and agent chaining and complex tasks get assigned to AI it will become harder to move between models. There is a reasonable probability that 75% of the enterprises will build their implementation of the solution to their core problem around one model "stack". Token price reduction by 90% is the solve and mobility between models from the same frontier lab! Evals, harnesses, cache memory are the moats and I don't see models providing simple abstraction to those. I know there are efforts to do this out there, the long term solve for orchestration if it works will need to be "Claude code" level of design genius. Here's a chat with Fable @HamzaFodderwala had. **Why abstraction looks easy.** Models are stateless — every API call is weights + a prompt assembled at runtime. Everything the model "knows" about you — memory, documents, history, tools — is injected into the context window by software outside the model. So in principle, all your state already lives outside the weights. The catch is what "state" includes. **Layer 1 — Data (fully portable).** Enterprise documents, tickets, logs. Retrieved via RAG: text is chunked, embedded, stored in a vector database (Pinecone, pgvector), and relevant pieces are fetched into the prompt per query. The embedding model is separate from the LLM, so this layer is genuinely model-agnostic. Already solved. **Layer 2 — Memory (portable in principle).** Systems like Mem0 and Zep sit between the app and the model: after each interaction they extract salient facts ("user prefers X"), store them as plain text, and inject the relevant ones into future prompts. Because the artifact is natural language, it reads into any model. Facts port. **Layer 3 — Orchestration/routing (works, but only for shallow tasks).** Gateways like OpenRouter and LiteLLM normalize API differences and route each request to the cheapest capable model. This is the fungibility layer being furiously built. It genuinely works for one-shot, verifiable tasks — classification, extraction, summarization — which conveniently are the tasks where cheap models suffice anyway. **Where it breaks — the non-portable state.** Four things stay behind when you switch: - **The harness.** Prompts, tool schemas, and guardrails are tuned to one model's quirks. An agent must get every step right, so reliability compounds: a model that's 98% reliable per step completes a 50-step task about a third of the time; at 90% per step, it almost never finishes. Swapping models costs you a few points per step — the difference between an agent that works and one that doesn't. - **The evals.** Swapping means re-testing everything and re-fixing every regression. The real switching cost isn't data migration — it's re-verification. Nobody has abstracted that. - **Procedural memory.** Facts port; skills don't. Cached successful workflows and learned workarounds are conditional on the model that produced them. - **Cache pricing.** Provider-specific, worth 75–90% of input costs on agentic workloads. Quiet lock-in. **The labs' angle.** They offer hosted memory, hosted file stores, caching, fine-tuning — every one pulls state from your side onto theirs. The labs will crack memory first, but as lock-in, not portability. Nobody standardizes their own exit door. MCP is the partial exception: it standardizes tool and data access across models, but doesn't touch harness tuning or evals. **Where 3P vendors fit.** Routers are thin-margin commodity plumbing; vector DBs and memory infra are real but small. The two structurally interesting positions: **eval platforms** (LangSmith, Braintrust) — since switching cost equals re-verification cost, whoever industrializes cross-model testing actually enables fungibility.
- 07
@pauliusztin_ ·
Building memory for AI agents is less about storage and more about retrieval. Let me explain... I'm building a personal assistant from scratch for my next book with Manning. And one challenge I faced was deciding how the agent retrieves (from unified memory) the appropriate information quickly, reliably, and with as little complexity as possible. This led me to store the entire knowledge graph in a single database (e.g., MongoDB). One system handles: Full-text search Semantic search Graph traversal But you'll lose a graph-native query language. In exchange for simplicity, this is a trade I'd make every time for a personal assistant. When doing GraphRAG, the agent has three ways to search its unified memory: 1/ Graph search This is the default path. Run text search and vector search in parallel. Fuse both rankings using Reciprocal Rank Fusion (RRF). Traverse 2-3 hops through the graph to retrieve connected knowledge. Rerank the candidates. To keep context tight, pick the top 10. 2/ Deep search Sometimes keeping the top 10 isn't enough. You want to use everything that was retrieved as context. But after 2-3 hops, you can easily retrieve 50+ documents that won't fit in the context window. Instead, save everything to disk and build a lightweight LLM wiki on demand. This temporary wiki serves as the agent's localized memory, allowing it to explore large amounts of data through progressive disclosure without overwhelming the context window. 3/ Agentic search Some questions don't fit predefined retrieval algorithms so the LLM writes the database query itself. The ontology tells it which entities and relationships exist. You add a validation loop to ensure the query is syntactically correct. And a permission layer to ensure the query stays within safe boundaries. Here's the insight: GraphRAG isn't just vector search plus a graph; It's multi-hop traversal during retrieval. Similarity finds the entry point and the graph finds everything connected to it. We serve this unified memory as an MCP server via @fastmcp (by @PrefectIO). The agent never talks directly to the database. Instead, a harness such as Claude Code calls search-and-write tools, while the MCP layer decides how memory should be queried. Every fact the agent retrieves must first be processed. This is where @PrefectIO comes in. Every ingestion pipeline runs asynchronously as durable workflows across parallel workers with retries, caching, checkpointing, and centralized rate limiting. Even if one extraction step fails, indexing can continue, so the graph remains searchable. The read path never waits for orchestration. This has become one of my most important design principles. Orchestrate the writes. Never the reads. P.S. What retrieval strategy do you rely on most when building the memory for your AI agents?
- 08
@akshay_pachaar ·
K-Means is simple. Making it fast on GPU isn't. Flash-KMeans is an IO-aware implementation of exact k-means that rethinks the algorithm around modern GPU bottlenecks. By attacking the memory bottlenecks directly, Flash-KMeans achieves: - 30x speedup over cuML - 200x speedup over FAISS Using the same exact algorithm, just engineered for today’s hardware. At the million-scale, Flash-KMeans can complete a k-means iteration in milliseconds. Here's why this matters today: K-means has always been an offline primitive. Something you run once to preprocess data and move on. These speedups change that. ↳ Vector databases like FAISS use k-means to build search indices. Faster k-means means you can re-index dynamically as data changes, not batch it overnight. ↳ LLM quantization methods need k-means to find optimal weight codebooks, per layer, repeatedly. What takes hours could now take minutes. ↳ MoE models need fast token routing at inference time. Millisecond k-means makes it viable to run this inside the inference loop, not just in preprocessing. The 200x over FAISS is the number to internalize. FAISS is the industry standard. Most production vector search systems sit on top of it. Link to the paper and code in next tweet!
Watch video
- 09
@_avichawla ·
Finally! A Text-to-SQL solution that actually works (open-source). When text-to-SQL fails, the real issue isn't the LLM or the prompt but schema retrieval. Consider a query like "Which publishers received royalty payments above $5,000?" To handle this, vector search can pull "publisher" and "royalty_ledger" based on semantic similarity But it can completely miss "vendor_agreement", the bridge table that connects them. The LLM writes valid SQL, but the engine still returns zero rows. This is a fundamental issue with vector-based schema retrieval on enterprise databases. A smarter approach is to treat the schema as a graph instead of a document to embed. Tables become nodes, foreign keys become edges, and join paths are discovered by walking the graph rather than matching semantics. If you want to see this in practice, QueryWeaver implements this approach. It converts the schema into a graph, and when a query comes in, it walks the structure and pulls in every bridge table the join path requires, including multi-hop chains. For instance, on the BIRD Benchmark with a superhero database expanded to 60 tables, it resolved a 5-hop query by chaining through: superpower → capability_matrix → stakeholder_registry → resource_requisition → budget_allocation Vector search found the two endpoints but missed everything in between because "stakeholder" has zero semantic link to "superpowers." Graph traversal found "stakeholder_registry" simply because it was the only road connecting the entities. It's fully open-source, and you can easily self-host it. I've shared the GitHub repo in the replies.
Watch video
- 10
@GithubProjects ·
Qdrant is a production-ready vector search engine and database built in Rust, designed for high-performance similarity search with extended filtering support. - Written in Rust for speed and reliability under high load. - RESTful API with convenient client libraries for Go, Python, and more. - Supports advanced filtering, quantization, sharding, and hybrid search. - Available as a self-hosted Docker image or fully managed cloud service with a free tier.
- 11
- 12
@_avichawla ·
There's a new RAG approach that: - cuts corpus size by 40x. - reduces tokens per query by 3x. - improves vector search relevance by 2.3x. And it delivered 260% accuracy improvement on medical RAG benchmark over standard RAG. Here's the core problem this new approach solves: Chunks in a standard RAG pipeline typically carry no info about version, clearance level, or source authority. The embedding model encodes it the same way regardless of whether the chunk is an outdated draft or the latest approved version. During retrieval, if an outdated chunk and a latest chunk get retrieved as context, the LLM has no signal to prefer one over the other. So it combines both and hallucinates. The issue is not retrieval but rather the representation. The unit itself is wrong, and the fix has to happen before retrieval, at the data layer. Blockify is an open-source data preprocessing engine that solves this at the data layer. The engine sits between the document parser and the vector store. Here's how it works: - First, a context-aware splitter finds natural breaks (paragraph boundaries, section breaks, topic shifts). - Instead of embedding raw segments directly, a purpose-built LLM processes each one and extracts structured knowledge units called IdeaBlocks (typically 2-3 sentences). Each unit isolates a different fact or concept. - Each unit is paired with a contextualized question and answer. This mirrors how users query the system and ensures the query embedding sits closer to real queries in the vector space (HyDE does something similar). - Each block also carries metadata info like entity name, entity type, version, and clearance level. This helps rank retrieval by recency and authority, not just similarity. The pipeline runs in two stages. - The Ingest model converts raw text into IdeaBlocks as described above. - The Distill model then clusters semantically similar blocks across the full set and merges duplicates into one canonical unit before indexing. The retrieved units now answer a specific question instead of returning a paragraph that might contain the answer somewhere in the middle. On the published benchmarks: - The pipeline reduces a corpus to roughly 2.5% of its original size while preserving 99% factual integrity. - Token consumption per query drops by 3x, from 1.5k tokens (naive top-5 chunks) to 500 tokens (top-5 IdeaBlocks). - Vector search relevance improves 2.3x, measured by cosine distance. In medical evaluation, the same pipeline delivered up to 650% accuracy improvement on clinical-grade RAG with a quantized Llama 3.2 3B model running on-device. The Blockify engine composes with LangChain and LlamaIndex. You can swap out the chunking stage (NodeParser/TextSplitter) and produce IdeaBlock nodes that the rest of the pipeline consumes normally. For storage, you can integrate it directly with most vector DBs like Milvus, Elastic, etc. There is also a Claude Code skill in the repo that runs the full Ingest and Distill pipeline while referencing the project documentation. For production workloads on Intel Xeon, an optimized build is available through OpenVINO. I've shared the GitHub repo in the replies.
Watch video
- 13
@svpino ·
95% of enterprise AI pilots failed last year. Weaviate + StackAI just released a free technical guide on building RAG agents for production. • It covers chunking strategies, hybrid search, and re-ranking • Security-first design considerations (SSO, RBAC, multi-tenancy) • Real use cases with workflow and architecture diagrams Worth reading if you're still trying to build an AI agent that actually works.
- 14
@maxleiter ·
I wrote a bit about how we made v0 an effective coding agent - Dynamic system prompt - Our "LLM Suspense" framework for modifying streamed content on the fly - Our AutoFixer system for fixing various issues we've seen. A good example of how powerful the pipeline is is our icon fixer. We deterministically fix when the LLM hallucinates non-existent icons by: 1. Embedding every icon name in a vector database. 2. Analyze the exports from lucide-react at runtime. 3. Pass through the correct icon when its valid. 4. If the icon does not exist, run an embedding search to find the closest match. 5. Rewrite the import during streaming. https://t.co/vbQZUOLbgb
- 15
@RaulJuncoV ·
Behind every stack with too many databases is a team that didn’t check what Postgres can already do. I've seen this a dozen times. MongoDB for JSON. Redis for sessions. Elasticsearch for search. Pinecone for vectors. InfluxDB for metrics. Each one added to solve a real problem. Each one that Postgres already had an answer for. 1. Running MongoDB for JSON storage? Postgres has JSONB with GIN indexes on nested fields. Full query planner support. Joins included. ACID transactions included. Engineers who migrate from MongoDB usually say the same thing: They missed joins more than they expected. 2. Running Pinecone or Chroma for vector search? pgvector supports HNSW and IVFFlat indexing on float vectors. Cosine similarity. L2 distance. Inner product search. If your RAG pipeline already hits Postgres, this is one fewer network hop and one fewer service to operate. 3. Running Elasticsearch for full-text search? pg_trgm + tsvector + GIN indexes handle autocomplete, ranked document search, and fuzzy matching without leaving Postgres. Fuzzy matching. Ranked results. Language dictionaries. Elasticsearch is absolutely worth it for the hard 20%. But know you are actually in that 20% before you add it. 4. Running InfluxDB for time series? TimescaleDB is a Postgres extension. Automatic partitioning. Native compression. Continuous aggregates. SQL interface. Most teams don't know TimescaleDB exists until after they've already set up InfluxDB. That's the only reason InfluxDB is in this list. 5. Running Redis for pub/sub or lightweight queuing? Postgres has LISTEN/NOTIFY for event broadcasting. For durable queues, there's pg_boss, a full job queue built on Postgres, used in production at real scale. This is not a Redis replacement for sub-millisecond caching at scale. But most teams reach for Redis before they even benchmark Postgres. Check first. Every database you add is: - A new connection pool. - A new backup strategy. - A new monitoring dashboard. - A new failure mode. - A new thing to wake you up at 3 AM. Postgres in 2026 covers 80–90% of your data needs with extensions. Before you spin up a specialty store, ask: can Postgres do this? The bill for polyglot persistence isn't paid in infrastructure costs. It's paid in operational complexity, compounded over time.
- 16
@kmeanskaran ·
Working on GraphRag (multi-hops) vs VectorRag benchmarks: - Defining Marathi data on agriculture and govt schemes - Running basic vectorrag - Designing LLM based SVO generation + evaluation and ingesting in neo4j - Experimenting with one-hop and two hops - Running eval on gold QnA with metrics (Hallucination rate, relevancy score, etc.) This is something I am testing on a weekend. With complete open source tools.
- 17
- 18
@GithubProjects ·
turbovec uses Google's TurboQuant algorithm to compress vector indexes to roughly ⅛ the memory of float32 while searching faster than FAISS. - Online ingest with no train step, no parameter tuning, and no rebuilds - Hand-written NEON and AVX-512BW kernels beat FAISS IndexPQFastScan by 12–20% on ARM - Filter at search time with id allowlists or slot bitmasks, no over-fetching - Pure local with no managed service, suitable for air-gapped RAG stacks Explore it here: https://t.co/dlwWIEIRgx
- 19
@TheTuringPost ·
Almost everyone is talking about @GoogleResearch's TurboQuant (and for good reason) ➡️ It lets you run a 3-bit system with the accuracy of a full-precision model. Technically, TurboQuant is a compression algorithm that shrinks high‑dimensional vectors to low precision without losing accuracy. ▪️ It combines 2 techniques: - Vector compression with PolarQuant that first randomly rotates vectors, and then converts them into polar coordinates (radius + angle) to keep the main signal and avoid normalization overhead. - 1-bit error correction (QJL) turns the remaining error into just +1/−1 bits and uses them to correct similarity scores so they stay accurate. This opens up many benefits: • Keeps near-zero or zero accuracy loss • Speeds up attention and vector search by up to ~8× • Cuts KV cache memory by ~6× • Works without retraining or fine-tuning It’s very close to the best compression we can theoretically achieve. And as we move toward very long-context LLMs and semantic search over billions of vectors (both bottlenecked by memory and speed) this is a must-have building block.
- 20
@smratitiwa86867 ·
What if you had access to a global intelligence platform... for free? This open-source project turns any AI agent into a real-time intelligence analyst. Phoenix Intelligence Dashboard is an MCP server with 113 tools across 30+ intelligence domains. It can monitor: • Financial markets & macro signals • Military flights & naval activity • Global conflicts & unrest • Cyber threats & CISA alerts • Earthquakes, wildfires & disasters • Shipping, aviation & infrastructure • SEC filings & company intelligence • AI papers & GitHub trends • Elections, sanctions & prediction markets • Space weather & disease outbreaks The best part? It continuously builds a searchable intelligence database using Qdrant. So instead of querying dozens of APIs, you can simply ask: → "Military activity near the Taiwan Strait" → "Cyber threats targeting healthcare" → "Economic indicators suggesting recession" It searches across accumulated historical intelligence and returns relevant results in seconds. Under the hood: • 113 MCP tools • 30+ intelligence domains • 43+ public data sources • Live operations dashboard • Interactive world map • Semantic vector search • PDF/HTML intelligence reports 100% open source. MIT licensed. Repo👇
- 21
@thetripathi58 ·
🚨 Cambridge researchers just tested what happens when you overload an AI's memory with irrelevant data. They found a complete collapse of modern RAG systems. Not a minor hallucination. A total failure of the exact retrieval architecture that every enterprise AI relies on to access private data. The models simply drowned in the noise. The researchers tested standard Retrieval-Augmented Generation (RAG) and filtering models like Self-RAG. They fed them information but slowly increased the ratio of distracting, low-quality documents. Here is what they found. Current read-time filtering failed completely. When the ratio of distractors hit 8:1, the accuracy of standard RAG systems plummeted to 0%. The AI lost the ability to find the truth. It exposed a massive architectural flaw. We currently store every single document an AI reads, regardless of quality, and force the model to sort through the garbage at query time. It is highly inefficient and fundamentally broken. The biological fix. The researchers built a new system called "Write-Time Gating" modeled after the human hippocampus. Instead of saving everything, it evaluates novelty, reliability, and source reputation before the data is even stored. And then there is the finding that changes how we build AI: hierarchical archiving. When beliefs update, the system does not delete the old data. It deprioritizes it, maintaining a version history just like the human brain. The result? The write-gated system maintained 100% accuracy even at massive distractor scales, all while costing one-ninth the compute of current systems. The researchers made it clear. When you dump raw, unfiltered data into a database and expect the LLM to figure it out later, you are building a system designed to fail at scale. No reliable retrieval. No cost control. No accuracy guarantees. Nothing. Right now, companies are building massive vector databases, throwing every piece of corporate documentation into them, and assuming the AI will magically find the signal in the noise. Stop treating AI memory like a hard drive. Start treating it like a biological filter. Build the gate at the entrance, not the exit.
- 22
@tylerangert ·
perhaps an even bigger market for "personal software" is not at the application layer but at the library and framework layer. so many open source packages / libraries etc are marketed to "work everywhere" and have dozens of first party language bindings, cover a billion benchmarks, etc. for example, right now im looking into a better vector storage + search solution. so i found sqlite-vec. and it's great! except i got The Models to use the original repo as a reference, set up an auto-research loop with a goal of making query time 10x faster, and brainstormed with it to try out different experiments and techniques. we're now sitting at 20x faster for vector search in sqlite vs. sqlite-vec and just as fast as usearch + FAISS for a single global index, and over 1000x faster than basically any HNSW library for doing derived / computed index queries since we can take advantage of sqlite itself ! in short: dont vendor everything just because it exists. sometimes reinventing the wheel really only takes 3 hours and a loop
- 23
- 24
@Suryanshti777 ·
RAG is broken and everyone's pretending it isn't. We chunk documents into pieces. Embed them into vectors. Pray similarity search finds the right ones. It doesn't. On complex documents, similarity ≠ relevance. Vectorless RAG just scored 98.7% on FinanceBench. GPT-4o with search? 31%. Here's how it works: Instead of shredding a 200-page document into random chunks, it reads the document the way a human does — structurally. 1. Document Indexing Parses the doc into a hierarchical tree: chapters → sections → pages. No chunking. No embeddings. No vector DB. 2. Tree-Based Reasoning The LLM traverses the tree from root to leaf, evaluating context at every level before going deeper. It THINKS its way to the answer instead of searching for it. 3. Context-Aware Retrieval Carries conversation history across turns and returns exact page + section references. Every answer is traceable. 4. Agentic Execution End-to-end agentic pipeline (VectifyAI demo runs on OpenAI Agents SDK). Zero vector layer in between. Why this matters: → Higher accuracy: document structure is preserved, not destroyed → Full traceability: every answer cites its exact page → Simpler stack: no embedding pipeline, no vector DB to maintain, lower cost The gap between similarity and relevance is where RAG accuracy dies. Vectorless RAG closes it by reasoning through structure instead of guessing with math. Chunking had a good run. It's over.
- 25
- 26
@NainsiDwiv50980 ·
Ask any LLM about something that happened last week and watch it either make something up or tell you it doesn't know That's not a model problem. That's a memory problem. The model only knows what it was trained on, frozen at a point in time RAG fixes this without retraining anything. Here's the actual flow, step by step: 1. Your documents (files, websites, internal docs) get chunked into smaller pieces 2. Each chunk gets converted into a numerical embedding, basically a vector that captures its meaning 3. Those embeddings get indexed and stored in a vector database 4. When you ask a question, your query gets embedded the same way 5. The system does a semantic search, finds the top-K chunks that are actually similar in meaning, not just keyword matches 6. Those results get reranked, irrelevant stuff gets stripped out 7. The strongest, most relevant chunks get appended to your original prompt 8. That combined prompt (your question + real retrieved context) goes to the LLM 9. The model generates an answer grounded in actual data, not just its training memory The part people miss: the LLM never learns anything new. It's not being retrained. You're just handing it the right paragraph at the right moment, the same way you'd hand a coworker the one document they need instead of expecting them to memorize your whole company wiki Why it actually matters: → Answers are grounded in real data, not model memory → Knowledge stays current without retraining → Sources are traceable, you can point to exactly what the answer came from → Cheaper than fine-tuning every time your data changes → Scales across any domain, swap the knowledge base, same architecture Every serious AI product doing "chat with your docs" or enterprise search is running some version of this pipeline underneath
- 27
@techNmak ·
turbovec just turned a 31 GB memory problem into a 4 GB one. 10 million vectors. 31 GB in float32. One server almost maxed out just holding your embeddings. turbovec fits the same corpus in 4 GB. Same dataset. 16× smaller. Actually faster than FAISS. The algorithm behind it (TurboQuant, from Google Research) operates without training, codebooks, dedicated training phases, or corpus rebuilds as your dataset expands. How it gets to 4 GB => Normalize each vector. Apply a random rotation. Every coordinate now follows a predictable distribution for any dataset. Precomputed math picks the optimal buckets. Bit-pack the result. 1536-dim OpenAI embedding: 6,144 bytes → 384 bytes. The search numbers: → ARM (M3 Max): 12–20% faster than FAISS → x86 (Sapphire Rapids): matches or beats FAISS at 4-bit → Recall on OpenAI d=1536: beats FAISS by up to 3.4 points at R@1 Filtered search is executed within the SIMD kernel itself, eliminating post-processing without affecting recall. Drop-in compatible with LangChain, LlamaIndex, Haystack, and Agno. Same imports. Same API. Everything runs locally, keeping data on your machine and enabling a fully air-gapped RAG stack without relying on a managed service. GitHub link in comments. 👇
- 28
@Shruti_0810 ·
SAM ALTMAN HAS A NEW PROBLEM. 🤯 Google just shrunk 31GB of AI memory down to 4GB. The tool is called TurboVec. It uses up to 16x less memory, searches faster than FAISS, runs fully offline, and works on a regular Mac. No expensive GPU cluster. No cloud dependency. No compromise on speed. → 16x lower memory usage → Faster vector search → Works with LangChain & LlamaIndex → 100% open source The race to build bigger AI models is loud. The race to make them dramatically cheaper just got a lot more interesting. Repo: https://t.co/K3a7It5DGy
- 29
@IntuitMachine ·
🧵 THREAD: Why your RAG pipeline is probably backwards (and grep is eating vector search's lunch) 1/ Everyone's building the same retrieval stack: → Embed everything → Store in Pinecone/Weaviate → Query with cosine similarity → Inject top-K into context But a new study just flipped this playbook upside down. 2/ The setup: 116 questions across 10 agent configurations They tested lexical (grep) vs semantic (vector) search inside actual agent loops — not static RAG pipelines. The twist? They varied both the orchestration harness AND how results get delivered to the model. 3/ The shocking result: Inline grep beat inline vector search in every single model-harness pair. Not by a little. Some margins hit 23 percentage points. Your $10K/month vector database might be getting crushed by a bash command. 4/ "But semantic search understands meaning!" True... until you put it inside an agent that needs to: Issue multiple queries Filter noise Integrate results across tool calls Turns out grep's precision >> vector's fuzzy recall when the agent has to actually do something with results. 5/ The hidden variable nobody talks about: How results reach the model matters as much as what you retrieve. 📋 Inline delivery: dump everything into context 📁 File-based delivery: write to disk, model reads programmatically Same retriever, different delivery = completely different rankings. 6/ File-based delivery actually inverted some comparisons With Haiku + Amazon Bedrock harness: Inline: grep wins Programmatic: vector wins This means "retrieval quality" is meaningless without specifying the orchestration layer. 7/ Why grep wins on literal-span tasks: ✅ Agent can craft precise regex patterns ✅ Zero false positives when pattern matches ✅ No embedding drift or semantic confusion ✅ Instant feedback: match or no match It's like giving the agent a scalpel instead of a net. 8/ The harness matters MORE than you think Same data + same retriever + different CLI harness = 15+ point accuracy swings. Provider-native harnesses (Claude, Gemini CLIs) have invisible inductive biases that change how agents search. You can't A/B test retrievers without A/B testing harnesses. 9/ When noise scales up: They added 10 → 50 → 100 distractor sessions. The "grep always wins" rule broke down. Crossover point depended on BOTH harness strength AND model capability. Translation: You can't predict production behavior from offline metrics. 10/ Three immediate leverage points: 1️⃣ Add grep as a tool (takes 1 day, costs $0) 2️⃣ Try file-based delivery on weak models to reduce context rot 3️⃣ Expose BOTH tools simultaneously → let the agent choose per query Hybrid beats pure strategies without extra infrastructure. 11/ The contrarian take: "Default to vector" is expensive pattern-matching theater. The best retrieval strategy is the one your harness can reliably use — not the one with the highest offline recall@10. 12/ What this means for you: 🚫 Stop evaluating retrievers in isolation ✅ Test retrieval × harness × delivery as ONE system 🚫 Stop assuming semantic > lexical ✅ Match strategy to task distribution (literal spans ≠ conceptual synthesis) 🚫 Stop ignoring orchestration ✅ Harness choice = model choice in impact 13/ The future isn't better embeddings. It's understanding how agents actually use the tools we give them. Grep just proved that simple, precise tools + smart orchestration > sophisticated search + naive integration. 14/ Key limitation: This assumes answers are often verbatim spans. If your workload is heavy paraphrase/synthesis, the lexical advantage shrinks. But for memory-intensive QA, event timelines, and factual lookup? Grep eats. 15/ Bottom line: Before you scale your vector infrastructure, ask: "Have I tested grep with programmatic delivery inside my actual production harness?" The answer might save you 6 months and $100K. Paper: "Is Grep All You Need?" (Sen et al.)
- 30
@thisdudelikesAI ·
This is the most honest AI course I've seen all year. Everyone selling a "RAG bootcamp" right now starts the same way. Spin up a vector database, embed some text, retrieve the top chunks, generate an answer. It demos beautifully. It also collapses the second your documents have tables, scanned pages, or anything resembling real-world mess. Then I found production-agentic-rag-course on GitHub, and it refuses to play that game. Instead of an AI-first shortcut, it teaches you to build a production RAG system the way actual engineering teams do. You start with infrastructure that survives contact with reality: Docker, FastAPI, PostgreSQL, OpenSearch, Airflow pipelines pulling fresh arXiv papers every single day. Then you build keyword search with BM25 and learn why that foundation matters before any embedding enters the picture. By the time you reach semantic search, you understand what you're actually fixing. Hybrid retrieval fuses keywords with vectors. A local LLM turns search into conversation while keeping your data private. Monitoring and caching make it fast enough to ship. And the final week hands you something most courses never reach: an agentic layer built on LangGraph that decides its own retrieval strategy, grades whether the documents it pulled are even relevant, rewrites the query when they aren't, and refuses to answer questions outside its domain. The end result is your own research assistant you can talk to from a Telegram bot, with the full reasoning trace exposed so you can see exactly why it answered the way it did. It's free. MIT licensed. 7.2k stars and climbing. No upsell, no locked modules, just seven weeks of code you can read, fork, and own. The gap between people who can demo RAG and people who can ship it is enormous. This is the bridge. https://t.co/hQj1LypkDd
- 31
@freshlimesofa ·
I was learning different Vector indexing techniques. Decided to create a fun little visualizer that animates the indexing techniques. > IVF + variants > HNSW + variants check it out : https://t.co/qkgLWLF8FO
Watch video
- 32
@heygurisingh ·
Your RAG stack is paying rent on RAM it doesn't need to use. Someone just open sourced a vector index that fits 10 million documents into 4GB. The same corpus takes 31GB as float32. This thing fits it in 4GB AND searches it faster than FAISS. It's called turbovec. Built in Rust with Python bindings, sitting on top of Google Research's TurboQuant algorithm a data-oblivious quantizer that hits the Shannon lower bound on distortion with zero training and zero data passes. Here's what's inside this thing: → 16x compression on a 1536-dim vector. 6,144 bytes drops to 384 bytes → Hand-written NEON kernels on ARM and AVX-512BW on x86 that beat FAISS IndexPQFastScan by 12-20% → No codebook training. Add vectors, they're indexed. No rebuilds as the corpus grows → Pair it with any open-source embedding model for a fully air-gapped RAG stack. Nothing leaves your machine Here's the wildest part: The math is so clean it doesn't need your data. A random rotation makes every coordinate follow a known Beta distribution. Then Lloyd-Max scalar quantization buckets each coordinate using boundaries computed once, from the math, not the data. The paper proves this lands within 2.7x of the information-theoretic lower bound. You literally cannot do much better for a given number of bits. Most teams are paying thousands a month for managed vector DBs that do less than this. 946 stars. MIT License. 100% Opensource.
- 33
@ttunguz ·
AI vendor revenue will double classic software in terms of new bookings this year. This trend is so large it’s starting to have second-order effects. MongoDB reported strong Q2 FY'26 results, delivering $591M in revenue with 24% year-over-year growth. AI is causing a second-order effect & a resurgence in growth in Atlas, the cloud-hosted version of MongoDB, which represents 74% of total revenue. We’ve seen a reacceleration within the hyperscalers already, but now the impacts are felt beyond. The Atlas product shows a pronounced deceleration pattern when examined quarterly, but with clear signs of recent revival : (first chart) Looking at the previous 22 quarters, Atlas grew incredibly quickly until Q3 of 2021. The post-COVID surge re-accelerated it to 85%, falling to 24% & today bouncing again up to 29%. Could AI be as impactful on growth rates as COVID? "MongoDB is emerging as a standard for AI applications. Over the last few quarters, we’ve seen a strength in our self-serve channel, driven in part by AI native startups choosing Atlas as the foundation for their applications." Atlas’s growth aligns with broader changes in software distribution channelsas AI-native companies adopt different procurement patterns. "After testing vector search against Postgres pgvector for their in-vehicle voice assistant, they selected MongoDB for superior performance at scale & stronger ROI. They now rely on Atlas to handle over 1 billion vectors & expect 10x growth in data usage by next year." Vector search has the potential to become a significant workload for customers. Vectors are used for information retrieval for AI applications. "Atlas performance was strong, accelerating to 29% year-over-year growth, up from 26% in Q1. Our customer additions were also robust. We have added over 5,000 customers over the last 2 quarters." MongoDB has added 10% of its customer base by count in the last two quarters. "In Q2, Atlas consumption growth was strong & relatively consistent with last year’s growth rates. This drove the acceleration in revenue as well as the growth in absolute revenue dollars year-to-date for the first half of fiscal ‘26." The enthusiasm from the team suggests the trend is durable. MongoDB’s overall revenue trajectory shows consistent growth from $65M in FY2016 to over $2.2B today, representing a 34x increase over nine years. "We ended the quarter with over 59,900 customers… Of our total customer count, over 7,300 are direct sales customers, a decline of 200 customers sequentially & flat year-over-year." MongoDB is moving up-market, focusing on larger enterprise customers rather than expanding total customer count. The data implies a $9.8k ACV. AI is providing a new tailwind not just to the major infrastructure players but to vendors who supply software that are components of AI. Hyperscalers’ growth rates suggest the effect on some of these adjacent businesses could be dramatic. https://t.co/agWFEWsseu
- 34
@sebbsssss ·
Spent the last 48 hours improving @AnsemClone Here is a deeper look at the tech behind it all. 1. In-Process Retrieval The clone can search its full historical memory without relying on an external database. Ansem’s historical tweets are embedded ahead of time and loaded directly into the application. When the clone prepares a response, it searches that corpus in memory instead of calling an external vector database. For a dataset of this size (250K) the simpler architecture works better. Retrieval is faster, there are fewer network calls, and there is less infrastructure to maintain. It also removes failure points caused by service outages, connection issues, and indexes falling out of sync. 2. Incremental Memory Updates New tweets become part of the clone’s memory automatically while the system is running. Every six hours, the system checks for new tweets from Ansem @blknoiz06 . It filters out anything already processed, generates embeddings for the new material, and adds them to the live corpus. There is no need to rebuild the full archive or redeploy the application. New tweets become searchable as soon as they are ingested. This allows the clone’s memory to evolve alongside Ansem’s views, language, and interests instead of slowly becoming a frozen snapshot. 3. Multi-Source Context Assembly Each response combines long-term memory with current events and information relevant to the conversation. The generation pipeline uses three inputs: / relevant historical tweets, // live market context from Grok Agent Tools, /// retrieval tied to the topic being discussed. Each source solves a different problem. Historical memory provides continuity. Live context keeps the clone aware of what is happening today. Topic retrieval narrows the available information to what matters for the current conversation. A good example of this working organically and staying up to date was when @AnsemClone naturally posted about, "everyone chasing the next chain, next narrative" Combining all three gives the model a stronger factual base and reduces the amount it has to infer or invent. 4. Layered Safety Several independent checks must approve a response before the account can post it. The system uses four safety layers to screen for shilling requests, contract addresses, financial advice, prompt injection, wallet drain attempts, and other unsafe inputs. These checks run at different stages of the pipeline. That matters because no single classifier, filter, or system prompt will catch every attack. A harmful request has to pass several independent controls before it can reach the posting stage. This reduces the chance that one missed signal becomes a public reply. 5. Reliable Autonomous Posting The system can recover from crashes and API failures without losing work or posting duplicate replies. Each reply is tracked from discovery through generation, safety review, and publication. That state is stored in a restart-safe way, which allows the application to recover after a crash without forgetting what it has already processed. The pipeline also uses exactly-once reply semantics. Each eligible tweet should receive one reply, even when an operation has to be retried. External APIs are treated as unreliable by default, so the system can handle timeouts, rate limits, incomplete responses, and uncertain delivery states without bringing down the full process. TLDR Outcome: Our Clone can now ingest new memory, gather live context, retrieve relevant history, generate a response, run several safety checks, publish it, and recover from common failures without constant supervision all at scale and in real time. The reply is just the visible output. The real challenge was making everything behind it simply work.
- 35
- 36
@NVIDIAAI ·
NVIDIA cuDF and cuVS libraries are being adopted by leading data platforms to fuel modern enterprise data processing. Across industries, cuDF and cuVS use is surging: ✅ @Nestle: Achieved 5x faster processing on @IBM https://t.co/PSFMiyZDzF. ✅ @Snap: Cut data processing costs by 76% on @GoogleCloud. ✅ @Dell AI Data Platform: 12x higher throughput for vector indexing. ✅ @Oracle: AI-ready data in minutes, not hours. Read the #NVIDIAGTC announcement: https://t.co/UnoQ9V1B9t Thank you to our partners: @ApacheSpark @PrestoDB, @duckdb, @DataPolars, FAISS, @OpenSearchProj, @milvusio, @EDBPostgres, @NetApp, @Snowflake, @starburstdata, @VAST_Data
- 37
@petesoder ·
@changhiskhan, CEO of @lancedb, thinks the data stack we've used for 20 years is done. Metadata in the DB, files on S3, connected by a pointer. Fine for humans. Breaks under agentic workloads. His argument: the files need to live inside the database. https://t.co/zQqode1Imp
Watch video
- 38
@PrajwalTomar_ ·
Your vector database is quietly killing your AI agent and you have no idea. Here is the trap. Everyone picks the database that looks fastest. But those speed tests run on data that never changes. Real agents are different. They save new information after every task. Add that constant writing, and the database that looked fastest lost 75% of its speed. Your top pick just became your bottleneck. So I went through a solid breakdown of 8 of them. Here's how to actually choose: → On Postgres, under 10M vectors: pgvector → Constant reads and writes (agent memory): Qdrant → Zero ops, cloud is fine: Pinecone → Prototyping on your laptop: Chroma → On-device or embedded: LanceDB → Regulated, edge, or air-gapped: VectorAI DB And the part nobody tells you: RAG mostly reads. Agent memory constantly writes. Different workload, different database. Pick by where it runs and what it does. Never by the leaderboard. Full breakdown below.
- 39
@ttunguz ·
Gmail’s AI email assistant writes like a committee of lawyers designed it. Pete Koomen’s recent post Horseless Carriages explains why: developers control the AI prompts instead of users. In his post he argues that software developers should expose the prompts and the user should be able to control it. He inspired me to build my own. I want a system that’s fast, accounts for historical context, & runs locally (because I don’t want my emails to be sent to other servers), & accepts guidance from a locally running voice model. Here’s how it works: 1. I press the keyboard shortcut, F2. 2. I dictate key points of the email. 3. The program finds relevant emails to/from the person I’m writing. 4. The AI generates an email text using my tone, checks the grammar, ensures that proper spacing & paragraphs exist, & formats lists for readability. 5. It pastes the result back. Here are two examples : emailing a colleague, Andy (https://t.co/Ghkek3slpY), & a hypothetical founder (https://t.co/GLxMvxNmfm). Instead of generics, the system learns from my actual email history. It knows how I write to investors vs colleagues vs founders because it’s seen thousands of examples. The point isn’t that everyone will build their own email system. It’s that these principles will reshape software design. - Voice dictation feels like briefing an assistant, not programming a machine. - The context layer - that database of previous emails - becomes the most valuable component because it enables true personalization. - Local processing, voice control, & personalized training data could transform any application, not just email, because the software learns from my past uses We’re still in the horseless carriage era of AI applications. The breakthrough will come when software adapts to us instead of forcing us to adapt to it. Centered around a command line email client called Neomutt (https://t.co/npc7rKft2M). The software hits LanceDB, a vector database with embedded emails & finds the ones that are the most relevant from the sender to match the tone. The code is here (https://t.co/oE6CNkRBEI). https://t.co/DcP6eCnRO5
- 40
@RoundtableSpace ·
Most RAG pipelines follow the same pattern chunk your docs, embed them, stuff into a vector DB, run similarity search. PageIndex throws all of that out. No vector database. No embeddings. No chunking. No similarity search. Instead it builds a tree index over your documents and lets the LLM reason through it the way a human reads a book navigating structure, following context, understanding relationships. The results are hard to argue with. 98.7% on FinanceBench. Beats every vector RAG system on the leaderboard. Every startup that raised money to build a better vector RAG pipeline is having a bad week. 100% open source.
- 41
@AlphaSignalAI ·
Google's new algorithm just shrunk 31GB of vectors into 4GB. Storing embeddings for RAG eats memory fast. Ten million documents in float32 takes 31 GB of RAM. A new open-source Rust vector index changes that math. TurboVec fits the same corpus into 4 GB. It runs on TurboQuant, a quantizer needing zero training. Each vector gets normalized, randomly rotated, then bucketed by precomputed math. The result is a fixed pipeline that works on any data: > 16x smaller memory footprint > Beats FAISS by 12-20% on ARM > Matches or wins on x86 > Filter by ID at search time > Drop-in for LangChain and LlamaIndex The library skips any data-dependent calibration. No managed service touches your vectors. Pair it with any open embedding model. You get a fully air-gapped retrieval stack with Python bindings. How much further can data-oblivious compression go?
- 42
- 43
@Meer_AIIT ·
🚨 A $2.5B startup just put Nvidia in a sandwich on the hardest document retrieval benchmark in AI. It's called webAI-ColVec1. And they open sourced it. Their 9B model sits at #1 on ViDoRe V3. Their 4B model sits at #3. Nvidia's best open-source embedding model is stuck at #2 between them. ViDoRe V3 is not a toy benchmark. 26,000+ document pages. 3,000+ human-verified queries. 10 enterprise domains. Financial filings, healthcare records, technical manuals, dense tables, messy layouts. The stuff that actually breaks production RAG systems. Here's what makes this different from everything else on the leaderboard: → Retrieves directly from rendered page images instead of extracted text → Skips OCR entirely. The model sees the page the same way you do → Tables, charts, scanned pages, dense layouts. All handled natively → Two model sizes: 4B for speed-sensitive edge deployments, 9B for max accuracy → Trained on ~2 million question-image pairs across scientific papers, financial filings, government reports, healthcare docs, and multilingual documents → Built on Qwen 3.5 vision-language backbones with LoRA adaptation → Trained on just 8 A100s with an effective batch size of 512 → Each query learns against 511 competing document pages per training step → Proprietary loss function that forces cleaner separation between correct and wrong pages → Multiple embedding sizes (128, 640, 2560) so you pick your own speed vs. quality tradeoff Here's the wildest part: Most enterprise teams are paying per-page and per-token fees just to get their documents into a format their RAG system can search. Reducto charges $0.015 per page for parsing. Cohere Embed v4 costs $0.12 per million tokens. Voyage AI's flagship model runs $0.18 per million tokens. And all of those still depend on OCR as the first step. One bad table extraction upstream and your entire retrieval pipeline breaks. webAI threw out that entire architecture. The model reads the page like a human. And it beats every paid and open-source alternative on the benchmark designed to test exactly that. This didn't come from a massive model or a giant infrastructure budget. 8 A100s. Deliberate training recipe. Retrieval-specific design. That's it. Cohere Embed v4: $0.12/million tokens. Voyage AI voyage-3-large: $0.18/million tokens. OpenAI text-embedding-3-large: $0.13/million tokens. This: Free. Open source. #1 on the leaderboard. @thewebAI 100% Open Source. (Link in the comments)
- 44
@jlongster ·
been trying vector databases, I haven't found them very helpful for codebases, but it's very cool for my local notes I'm indexing all my Bear notes (splitting each note into individual items) and my system can find relevant info quickly, logs of when I worked on something, duplicate todos, etc
- 45
@thetechstartups ·
🚀 AI has a memory problem. Google thinks it has a solution. @Google just unveiled TurboVec, a new open-source vector indexing library that shrinks AI memory requirements from 31GB to just 4GB 📉 ⚡ Fits 10 million vectors into 4GB of RAM ⚡ Up to 92% less memory usage ⚡ No training phase required ⚡ Beats FAISS on speed in some benchmarks At a time when AI companies are spending hundreds of billions on chips, data centers, and power, TurboVec takes a different path: Make AI infrastructure more efficient. #AI #ArtificialIntelligence #MachineLearning #GenAI #RAG #VectorSearch #LLM #GoogleAI #OpenSource #TechNews #Breakthrough #TurboVec
- 46
@MongoDB ·
MongoDB Atlas for unified document and vector storage. @VoyageAI for embedding models that outperform every competitor on code retrieval benchmarks. Together, they gave @FactoryAI: ✔️ A single platform replacing three disconnected systems ✔️ Billions of tokens processed daily without bottlenecks ✔️ Superior retrieval accuracy across massive codebases ✔️ The freedom to build products instead of managing infrastructure https://t.co/Wz3HRVMUsO
Watch video
- 47
@ThePracticalDev ·
Upgrading your embedding model in production? You can't just swap it out — existing vectors are incompatible. This dev shows a zero-downtime strategy using dual-column schemas, background backfilling with Cloud Run Jobs, and feature flags for safe cutover. { author: @RemikSamborski + @GoogleAI } https://t.co/QkQ8fElkIm
- 48
- 49
- 50
Best Tweets by Topic