{"slug": "for-structured-data-retrieval-accuracy-isn-t-a-model-problem", "title": "For Structured Data, Retrieval Accuracy Isn't a Model Problem", "summary": "MongoDB shipped three retrieval features this week: context-aware embeddings, hybrid search, and a native reranker. The developer behind csvql argues that while these features address unstructured data, structured data like CSV files and SQL exports already have exact retrieval via SQL, making vector search unnecessary for such data.", "body_md": "MongoDB shipped three retrieval features this week: context-aware embeddings, hybrid search, and a native reranker.\n\nThe pitch is the same one every vector database is making right now: **retrieval accuracy is the thing that determines whether an agent's next step is right or wrong, and getting it wrong is expensive twice over, once for the bad action and again for the retry.**\n\nThat framing is correct. It's also a framing built entirely around unstructured data, and it quietly assumes retrieval has to be approximate.\n\nVector search returns the *k* passages whose embeddings are closest to the query's embedding.\n\n\"Closest\" is a distance in a learned space, not a guarantee of relevance.\n\nTwo chunks can sit near each other in that space and still not answer the question, which is exactly why reranking exists as a second pass: a bigger model re-scores the same candidates because the first pass wasn't reliable enough on its own.\n\nHybrid search exists because vector similarity alone misses exact terms like a product SKU or an error code.\n\nContext-aware chunking exists because splitting a document into pieces throws away the surrounding meaning each piece depended on.\n\nAll three of those are real, useful fixes. They're also all patches on the same underlying fact** : when your data is unstructured text, there is no query that deterministically identifies \"the right answer.\" You can only get closer to it.**\n\n`SELECT dept, AVG(salary) FROM employees WHERE region = 'West' GROUP BY dept`\n\ndoesn't return the four passages that are probably relevant.\n\nIt returns the rows that satisfy the predicate, with 100% recall and 100% precision, every time, because the question and the data share the same structure.\n\nThere's no embedding to be almost-right in the middle of. There's no reranking step, because there's nothing to rerank, the WHERE clause already decided.\n\nThis is why [csvql](https://github.com/melihbirim/csvql)'s benchmarking has always focused on two things: does the query return the exact same result set DuckDB does, and how many tokens does an agent spend getting that result.\n\nAccuracy was never the axis we had to optimize, because for tabular data, exact retrieval isn't a hard problem someone solved with a bigger model.\n\nIt's what a WHERE clause has always done.\n\nNone of this means vector search is wrong for what it's for.\n\nA support ticket, a contract, a Slack thread, those are unstructured, and \"closest passage\" is a genuinely reasonable strategy when there's no schema to query against.\n\n**The mistake is applying that strategy to data that already has one.**\n\nA CSV of orders, a Parquet file of transactions, a SQL export of user events, these don't need semantic retrieval at all.\n\nThey need a query engine an agent can call directly, cheaply, and get back an exact answer.\n\nThe token cost of a wrong retrieval compounds the same way in both worlds, an extra round trip, a retry, a chain of tokens that never needed to be spent.\n\nThe difference is what fixes it.\n\nFor unstructured data, the fix is a better model.\n\nFor structured data, the fix already existed.\n\n**It's SQL.**", "url": "https://wpnews.pro/news/for-structured-data-retrieval-accuracy-isn-t-a-model-problem", "canonical_source": "https://dev.to/melih_birim_8363f43966da2/for-structured-data-retrieval-accuracy-isnt-a-model-problem-54h3", "published_at": "2026-08-13 13:30:03+00:00", "updated_at": "2026-08-13 13:50:59.624901+00:00", "lang": "en", "topics": ["artificial-intelligence", "machine-learning", "large-language-models", "ai-agents", "developer-tools"], "entities": ["MongoDB", "csvql", "DuckDB"], "alternates": {"html": "https://wpnews.pro/news/for-structured-data-retrieval-accuracy-isn-t-a-model-problem", "markdown": "https://wpnews.pro/news/for-structured-data-retrieval-accuracy-isn-t-a-model-problem.md", "text": "https://wpnews.pro/news/for-structured-data-retrieval-accuracy-isn-t-a-model-problem.txt", "jsonld": "https://wpnews.pro/news/for-structured-data-retrieval-accuracy-isn-t-a-model-problem.jsonld"}}