Video yükleniyor...

Video Yüklenemedi

Ana Sayfaya Dön

We've raised $6.5M to kill vector databases. Every system today retrieves context the same way: vector search that stores everything as flat embeddings and returns whatever "feels" closest. Similar, sure. Relevant? Almost never. Embeddings can’t tell a Q3 renewal clause from a Q1 termination notice if the language is...

3,884,456 görüntüleme • 7 ay önce •via X (Twitter)

66 Yorum

Nishkarsh profil fotoğrafı
Nishkarsh7 ay önce

If your AI agents keep retrieving the wrong context, explore HydraDB: Grateful to our investors who backed this vision: @Sky9Capital, @JeffDean, @gokulr, @shyamalanadkat, @klyap_, @0xJsum, @laura_yao, @caldbeckj, @anshulbhide, and @SeanZCai. @ashishkakran, @missionstcap, @prateeks, @MartinGTobias, @PickensAllison, @wadefoster, aekyi, @PuriSid, @mattsechrest, @CryogenicPlanet

Jeff Dean profil fotoğrafı
Jeff Dean7 ay önce

Congrats!

Rohit Ghumare profil fotoğrafı
Rohit Ghumare7 ay önce

Open source version:

Nishkarsh profil fotoğrafı
Nishkarsh7 ay önce

We’re expanding our team - let’s chat?

Rohit Ghumare profil fotoğrafı
Rohit Ghumare7 ay önce

DM'ed.

Nathan profil fotoğrafı
Nathan7 ay önce

> The project "strawberry" and the fruit "strawberry" are the same word, but completely different contexts. VectorDBs cannot tell the difference. Except they can? The vector db simply abstracts fast storage and similarity computation via HNSW with a convenient API. Sure if you use static word embeddings they will map and be identical, but any decent text embedding model worth its salt today will be able to differentiate between these two concepts. And that has EVERYTHING to do with the embedding model and NOTHING to do with the vector db

Nishkarsh profil fotoğrafı
Nishkarsh7 ay önce

tbh its not a vectorDB fault - its a function of how embeddings are computed and stored. different things. different problems. unfortunately no one wanted to hear about embeddings in our video.

Kevin Qi profil fotoğrafı
Kevin Qi7 ay önce

Relational databases have existed since the advent of computers. Why do we need to reinvent the wheel every year?

Nishkarsh profil fotoğrafı
Nishkarsh7 ay önce

RDBMS directly can't be used as context engineering infra for your AI to work with complex enterprise knowledge bases

Kevin Qi profil fotoğrafı
Kevin Qi7 ay önce

You are saying that a competent tech team cannot reproduce what you offer simply by using sql and a good pre processing system to build the same relationships you tout?

Kevin Qi profil fotoğrafı
Kevin Qi7 ay önce

And then on LLM requests, just show the returned relevant request into the context window ?

Tiffany Fong profil fotoğrafı
Tiffany Fong7 ay önce

No error message. Just looks right. You'd never know.

Nishkarsh profil fotoğrafı
Nishkarsh7 ay önce

No @hydra_db = ngmi

Jason Kneen profil fotoğrafı
Jason Kneen7 ay önce

Not open-source? Nah.

Nishkarsh profil fotoğrafı
Nishkarsh7 ay önce

if we open source will you become a customer?

Jason Kneen profil fotoğrafı
Jason Kneen7 ay önce

if there is value in what the SAAS offers yes. If I can develop it myself with AI because it's overpriced then no. And if you don't open-source it the community will just build an OSS one anyway. So this is your chance to do that, own the repo, guide the development AND you have a ready made recruitment pool and advocate pool of developers who will be contributing, forking and adding to your product! A simple license that insists derivatives have to be open source and you can include their features in the core and you've got it all covered

GuestHiveAI profil fotoğrafı
GuestHiveAI7 ay önce

This is exactly the problem I hit building an AI concierge for short-term rentals. Guest asks "where's the vacuum?" — pure vector search returns the cleaning fee policy. High similarity score. Completely wrong. So I stopped trusting embeddings alone. Built a hybrid system: → Semantic search (0.65) + full-text match (0.25) + recency bias (0.10) → Live context injection (who's checked in, which property, what time) → 3-level gatekeeper that only surfaces emergency info when the situation actually calls for it All in PostgreSQL. No separate vector DB. No $6.5M. The real unlock isn't better embeddings — it's knowing WHEN and WHY someone is asking.

Nishkarsh profil fotoğrafı
Nishkarsh7 ay önce

we're expanding our team. let's give it a shot?

GuestHiveAI profil fotoğrafı
GuestHiveAI7 ay önce

5 weeks. Solo. 128K lines of Python. Running in production right now handling real guest conversations 24/7. If that's the energy you're hiring for — DMs open

Simspron profil fotoğrafı
Simspron7 ay önce

@contextkingceo Pretty sad when you can’t even write your own tweets

GuestHiveAI profil fotoğrafı
GuestHiveAI7 ay önce

@contextkingceo 🤖

vixhaℓ profil fotoğrafı
vixhaℓ7 ay önce

Finally someone brave enough to say it out loud: vector DBs are gaslighting our agents.

Nishkarsh profil fotoğrafı
Nishkarsh7 ay önce

LETS SHOUT THIS OUT

JT profil fotoğrafı
JT7 ay önce

this is why AI search across internal tools always feels slightly off

Nishkarsh profil fotoğrafı
Nishkarsh7 ay önce

100%

Subah Wadhwani profil fotoğrafı
Subah Wadhwani7 ay önce

LFG! Congrats guys. Was so much fun working with you on this.

Rohan Paul profil fotoğrafı
Rohan Paul7 ay önce

I dont want my agents to reset their brains every session. Moving away from flat vector retrieval toward a structured memory tree is truly a great practical approach for solving agent continuity.

Soham Ratnaparkhi profil fotoğrafı
Soham Ratnaparkhi7 ay önce

Flat embeddings + 10M docs = confident hallucinations at scale. The fix isn't a better embedding model. It's a fundamentally different retrieval layer - one that tracks relationships, ownership, and temporal state. Super proud to be building this since Day 0 Big year ahead 🚀 and ofc, congrats boss - lesss goo

Nishkarsh profil fotoğrafı
Nishkarsh7 ay önce

yessir, can we please make @hydra_db 100x better?

Soham Ratnaparkhi profil fotoğrafı
Soham Ratnaparkhi7 ay önce

@hydra_db Yessir

Carl Vellotti 🥞 profil fotoğrafı
Carl Vellotti 🥞7 ay önce

LLM search works great on 500 docs, dies at 10M. And you never realize until it's too late.

Nishkarsh profil fotoğrafı
Nishkarsh7 ay önce

LLM search at demo day: genius LLM search in prod: confidently returns your CEO's lunch order as a "relevant policy document"

CG profil fotoğrafı
CG7 ay önce

Finally someone did something about this, cool launch video too.

Charly Wargnier ♨️ profil fotoğrafı
Charly Wargnier ♨️7 ay önce

Congrats @contextkingceo! "Similar ≠ relevant" is the exact bottleneck of naive RAG rn. great to see you've built this 🤗

Nishkarsh profil fotoğrafı
Nishkarsh7 ay önce

thank you @DataChaz! that bottleneck is exactly what pushed us to build this

Hannaan Kirmani profil fotoğrafı
Hannaan Kirmani7 ay önce

so you're saying it won't go looking for my ex when i ask it to find X?

dinos profil fotoğrafı
dinos7 ay önce

nice marketing video. where's the benchmark?

Vaibhav Domkundwar profil fotoğrafı
Vaibhav Domkundwar7 ay önce

A lot of Better portcos are going to love this Nish — sending your way! Congrats on the launch. 🚀

Nishkarsh profil fotoğrafı
Nishkarsh7 ay önce

Thank you sooo much @vaibhavbetter! So excited to have you onboard

Raul Junco profil fotoğrafı
Raul Junco7 ay önce

Interesting idea. Vector search is great, but it struggles with context as datasets get larger. Adding a graph or ontology layer to capture relationships could help avoid a lot of those weird retrieval mistakes. Congrats!

Nishkarsh profil fotoğrafı
Nishkarsh7 ay önce

exactly, and that's what we're solving for at @hydra_db!

Arlan profil fotoğrafı
Arlan7 ay önce

lowk @turbopuffer is still very good but will try out ur product soon

Nishkarsh profil fotoğrafı
Nishkarsh7 ay önce

@turbopuffer we think turbopuffer is great - we solve different problems :) if you want relations, timeline of how context has evolved, deal with messy unstructured knowledge then you need to try @hydra_db

Brian Chew profil fotoğrafı
Brian Chew7 ay önce

Congrats on the launch! - x icon in footer still redirects to old handle: - site title still says cortex - the site's opengraph thing still shows cortex just wanted to share in case it helps!

Nishkarsh profil fotoğrafı
Nishkarsh7 ay önce

thank you for pointing it out

Sean Cai profil fotoğrafı
Sean Cai7 ay önce

Excited to back since day one :) Excellent anti-agi hedge, but I haven't been so excited about a vector db adjacent product since turbopuffer. There are personally some inane use cases around migrating enterprises to this context graph to better collect their reasoning traces for rl envs!

Nishkarsh profil fotoğrafı
Nishkarsh7 ay önce

Ha anti agi hedge I love that. Grateful for your support and counsel as always!

Mikael profil fotoğrafı
Mikael7 ay önce

Damn dude you got a lot of investors

Nishkarsh profil fotoğrafı
Nishkarsh7 ay önce

grateful for their support

Average Database CEO profil fotoğrafı
Average Database CEO7 ay önce

Did you mean $60.5m?

polihedge profil fotoğrafı
polihedge7 ay önce

1. Don't want to book a demo 2. Pricing page loops to homepage 3. Several links in footer do not exist 4. Privacy Policy and Terms of Use are crossed links Lots of errors on the vibe code template site for HydraDB.

Antaripa Saha profil fotoğrafı
Antaripa Saha7 ay önce

the problem statement is very real and have faced such issues during multiple client projects, would love to test out hydradb. congratulations, Nishkarsh!

Nishkarsh profil fotoğrafı
Nishkarsh7 ay önce

this is sooo real...i feel it

Nishkarsh profil fotoğrafı
Nishkarsh7 ay önce

Amazing - this goes in our next launch video

Siddhartha Saxena profil fotoğrafı
Siddhartha Saxena7 ay önce

VectorDB are really broken and they just don't work. Excited to try out Hydra!

Nishkarsh profil fotoğrafı
Nishkarsh7 ay önce

will wait to hear about your experience, my DMs are always open:)

Siddhartha Saxena profil fotoğrafı
Siddhartha Saxena7 ay önce

Yes, going to this a try this weekend!

cole murray profil fotoğrafı
cole murray7 ay önce

man with db tech to sell says other DB tech is bad ignoring the larger search problem

AshutoshShrivastava profil fotoğrafı
AshutoshShrivastava7 ay önce

No 1 failure point is retrieval and most of us on X is arguing mostly about benchmarks. Lol

Nishkarsh profil fotoğrafı
Nishkarsh7 ay önce

benchmarks won't save you when retrieval grabs the wrong client's contract

Shruti profil fotoğrafı
Shruti7 ay önce

99% of AI companies are building on fundamentally broken retrieval. The 1% who figure this out first will own their vertical.

Tulsi Soni profil fotoğrafı
Tulsi Soni7 ay önce

Actually useful vs the usual "10 AI tools" threads.

Lisa profil fotoğrafı
Lisa7 ay önce

Every company building AI agents needs this. Some of my most gratifying moments as an investor have been hearing how much your customers love the product.

Nishkarsh profil fotoğrafı
Nishkarsh7 ay önce

hearing things like that from customers is the best part of this whole journey 🙏

Prateek Sharma // Ahead VC profil fotoğrafı
Prateek Sharma // Ahead VC7 ay önce

Love the idea of the librarian to capture the power of hydradb. Humans remember through a web of connections and our memory evolves as context changes. Great to see that finally AI can do the same! Congrats on the launch @contextkingceo and @hydra_db team!

Nishkarsh profil fotoğrafı
Nishkarsh7 ay önce

@hydra_db grateful for your support always @prateeks!

Benzer Videolar

Researchers built a new RAG approach that: - does not need a vector DB. - does not embed data. - involves no chunking. - performs no similarity search. And it hit 98.7% accuracy on a financial benchmark (SOTA). Here's the core problem with RAG that this new approach solves: Traditional RAG chunks documents, embeds them into vectors, and retrieves based on semantic similarity. But similarity ≠ relevance. When you ask "What were the debt trends in 2023?", a vector search returns chunks that look similar. But the actual answer might be buried in some Appendix, referenced on some page, in a section that shares zero semantic overlap with your query. Traditional RAG would likely never find it. PageIndex (open-source) solves this. Instead of chunking and embedding, PageIndex builds a hierarchical tree structure from your documents, like an intelligent table of contents. Then it uses reasoning to traverse that tree. For instance, the model doesn't ask: "What text looks similar to this query?" Instead, it asks: "Based on this document's structure, where would a human expert look for this answer?" That's a fundamentally different approach with: - No arbitrary chunking that breaks context. - No vector DB infrastructure to maintain. - Traceable retrieval to see exactly why it chose a specific section. - The ability to see in-document references ("see Table 5.3") the way a human would. But here's the deeper issue that it solves. Vector search treats every query as independent. But documents have structure and logic, like sections that reference other sections and context that builds across pages. PageIndex respects that structure instead of flattening it into embeddings. Do note that this approach may not make sense in every use case since traditional vector search is still fast, simple, and works well for many applications. But for professional documents that require domain expertise and multi-step reasoning, this tree-based, reasoning-first approach shines. For instance, PageIndex achieved 98.7% accuracy on FinanceBench, significantly outperforming traditional vector-based RAG systems on complex financial document analysis. Everything is fully open-source, so you can see the full implementation in GitHub and try it yourself. I have shared the GitHub repo in the replies!

Avi Chawla

974,238 görüntüleme • 9 ay önce

Traditional data pipelines don't work for RAG applications. There are 3 issues with them: ​ 1. Traditional data engineering solutions are optimized to handle structured data. RAG applications rely primarily on unstructured data. ​ 2. The connector ecosystem to load data from unstructured data sources is very immature. ​ 3. Traditional solutions do not offer any way to transform unstructured data into an optimized vector search index. ​ The goal of a RAG Pipeline is to solve these problems. ​ The number one objective is to create a reliable vector search index using factual knowledge and relevant context. This sounds easy, but it's one of the biggest challenges we face when building RAG applications. ​ At a high level, there are four different stages in the architecture of a RAG pipeline: ​ 1. Ingestion: Here is where the pipeline loads the information from the data source. ​ 2. Extraction: Where the pipeline processes the input data and decides how to retrieve the text contained inside them. ​ 3. Transform: Where the pipeline chunks the data and generates document embeddings. ​ 4. Load: Where the pipeline creates a search index in a vector database and loads the document embeddings. ​ There are different rabbit holes at each one of these stages. Here are three of them: ​ 1. Ingesting data once is simple. The hard part is refreshing the vector database whenever the original data source changes. ​ 2. Extracting the content of a plain text document is simple. The hard part is to extract content from complex documents containing tables, images, or cross-references. ​ 3. A simple continual chunking strategy with an overlap is simple. The hard part is to find the optimal strategy for your specific knowledge base and the way you are planning to query it. ​ In the attached video, I'll show you how you can build an enterprise-grade RAG Pipeline that solves every one of the above problems. ​ I'll use Vectorize. They partnered with me on this post. You can use them to build RAG pipelines optimized for accurate context retrieval. ​ ​ If you have a few documents lying around, set up a free account and give it a try.

Santiago

40,646 görüntüleme • 2 yıl önce

Engineer runs a Kimi K3 memory layer that costs $11 a month and remembers what a $500,000 vector database keeps losing. No embeddings. Four nodes and one rule about what's allowed to be forgotten. He published the whole schema. His version starts from the opposite idea. Memory is not a pile you search. It's a set of claims that expire unless something keeps paying to keep them. Four nodes. Every memory carries a clock someone has to reset: > WRITER - stores a fact with the reason it mattered, never raw text > DECAY - ages every memory down. Silence is deletion > RENEWER - only re-lifts a memory the model actually used again > GRAVE - holds what died, and why nobody reached for it Three nodes keep memory alive. One keeps the dead ones. Recall isn't storage here. It's rent a fact has to keep earning. That's the entire design. When everything is remembered forever, the useful and the stale retrieve identically. He replayed two months of agent context. 90,000 stored facts. 71,000 never retrieved once. The vector store returned all of them on similarity. Similarity graded closeness. Nobody graded whether the memory was ever right. Everyone else stuffs more into the context window and calls it memory. He built a layer that lets a fact die unless it keeps proving itself. The cost isn't storage. It's finding out how much of what your agent "knows" it has never once used. The article below is the full build - node prompts, the decay curve, the renewal rule. Save it. You'll want it open in the other tab.

wast3

67,778 görüntüleme • 2 ay önce

Announcing a new Coursera course: Retrieval Augmented Generation (RAG) You'll learn to build high performance, production-ready RAG systems in this hands-on, in-depth course created by and taught by , experienced AI and ML engineer, researcher, and educator. RAG is a critical component today of many LLM-based applications in customer support, internal company Q&A systems, even many of the leading chatbots that use web search to answer your questions. This course teaches you in-depth how to make RAG work well. LLMs can produce generic or outdated responses, especially when asked specialized questions not covered in its training data. RAG is the most widely used technique for addressing this. It brings in data from new data sources, such as internal documents or recent news, to give the LLM the relevant context to private, recent, or specialized information. This lets it generate more grounded and accurate responses. In this course, you’ll learn to design and implement every part of a RAG system, from retrievers to vector databases to generation to evals. You’ll learn about the fundamental principles behind RAG and how to optimize it at both the component and whole-system levels. As AI evolves, RAG is evolving too. New models can handle longer context windows, reason more effectively, and can be parts of complex agentic workflows. One exciting growth area is Agentic RAG, in which an AI agent at runtime (rather than it being hardcoded at development time) autonomously decides what data to retrieve, and when/how to go deeper. Even with this evolution, access to high-quality data at runtime is essential, which is why RAG is a key part of so many applications. You'll learn via hands-on experiences to: - Build a RAG system with retrieval and prompt augmentation - Compare retrieval methods like BM25, semantic search, and Reciprocal Rank Fusion - Chunk, index, and retrieve documents using a Weaviate vector database and a news dataset - Develop a chatbot, using open-source LLMs hosted by Together AI, for a fictional store that answers product and FAQ questions - Use evals to drive improving reliability, and incorporate multi-modal data RAG is an important foundational technique. Become good at it through this course! Please sign up here:

Andrew Ng

124,981 görüntüleme • 1 yıl önce