Agentic search blog #106
Agentic search blog #106
Conversation
| That opacity was once a design goal. Search for humans is meant to feel a little magical, an interface that hides its mechanics behind the screen delivering relevance as a service. But agents have no use for magic. They need transparency, determinism, and control. | ||
|
|
||
| <Note> | ||
| We aren’t selling agentic search, and we don’t have an agentic search product. We do firmly believe that however agentic search falls out the cornerstone will still be BM25, and that’s one of the reasons why we have built a better full-text search experience (including BM25) in PostgreSQL. |
There was a problem hiding this comment.
Can we add a callout that most communication around agentic search focuses on vector search. In our opinion vector search without a classic search index (like bm25) is inadequate.
There was a problem hiding this comment.
Yeah I don't love this callout. I think a callout like what Ankit is suggesting would feel a bit more integrated in the intro
|
|
||
| Crucially, they already speak the language for it. Large language models have absorbed SQL from the same public sources that taught humans for years: Stack Overflow, database documentation, open-source repositories, and Reddit discussions explaining joins and indexes. They have not only learned to *write* SQL but to *reason* about how it works; to understand schemas, constraints, and data relationships. | ||
|
|
||
| That makes SQL a natural interface for search. It is not a new abstraction that agents must learn; it’s one they already understand, grounded in explicit semantics and predictable structure. Exposing search through SQL doesn’t feel new, it feels like meeting agents where they already are. |
There was a problem hiding this comment.
should this paragraph be rephrased and come before the one prior to it. here we are laying a ground truth and above justifying why SQL is ideal.. @jamessewell wdyt?
| JOIN authors a ON d.author_id = a.id | ||
| WHERE a.h_index > 10 -- Only authoritative authors | ||
| ORDER BY final_score DESC; | ||
| ``` |
There was a problem hiding this comment.
I think we can add one more example here. a very naive brand boosting can be added.
ie if LLM thinks user is asking about specific brand, LLM extracts brand from query and passes it to sql as query_brand.
in the sql query ..
a case block gives brand score as 0 by default and substring match gives it a 1..
| ``` | ||
|
|
||
| The agent can reason about document types, author authority, and publication recency as integral parts of its ranking logic, not as post-processing filters. | ||
|
|
There was a problem hiding this comment.
We can optionally include integration with rerankers too..
eg. Apart from results, postgres can return raw scores also
- embedding score
- BM25 score
- other dynamic scores (recency, brand as shown above.. )
THe LLM can then feed these retrieved results and scores to reranker.
Although it is unrelated to interface being SQL or not, it will be good to show that at least this interface isnt hampering in involving a reranker.
| We aren’t selling agentic search, and we don’t have an agentic search product. We do firmly believe that however agentic search falls out the cornerstone will still be BM25, and that’s one of the reasons why we have built a better full-text search experience (including BM25) in PostgreSQL. | ||
| </Note> | ||
|
|
||
| ## SQL: The Missing Interface Layer |
| @@ -0,0 +1,7 @@ | |||
| { | |||
| "title": "Why Agents Can't Search, And How SQL Solves That", | |||
There was a problem hiding this comment.
I'm not fully convinced by the title and description here
philippemnoel
left a comment
philippemnoel
left a comment
There was a problem hiding this comment.
I'll review this once Ankit's comments and my comments on the agentic search SEO are handled
Do not review