Open zachschillaci27 opened 3 days ago
I had similar questions when reading this paper. My guess is that there's a couple of things that are supposed to make TAG different:
"While Text2SQL omits the final generation step and stops short after query execution, ..." (p.3)
The approach I have heard of without something like LOTUS is to construct embeddings of semantic columns such as a description or brand name and do a similarity search to get the most appropriate column value to filter on. Semantic operators seem more generalizable, if costly, but I do wonder if we take out LOTUS itself how much of differentiation is lost as compared to Text2SQL + LM generation on the results.
Would love to hear what the authors have to say about this!
Thanks for sharing the paper and code!
I have a question regarding the technical implementation and the differences between
Text2SQL
andTAG
. From the schematic in your paper below, you outlineTAG
with this three-step process:From what I can see here, this looks to me like a standard
Text2SQL
function calling pattern that one would implement for an OpenAI-like assistant with function (tool) calling. That is, you provide aText2SQL
function (tool) to the LLM that takes in the user's query and uses a separate LLM call (with information on the database schema provided in the system prompt) to generate an SQL query. The query is then run and the response is returned as atool
message and passed back to the orchestrator LLM. Running the orchestrator in an iterative function calling loop allows the assistant to apply additional semantic reasoning and execute multipleText2SQL
calls if needed. Once the complete response has been obtained, the LLM can provide a text-based response to the user.Whenever I have implemented such a pattern for an LLM assistant I have referred to this process as simply
Text2SQL
- would this, however, fit your definition ofTAG
? Perhaps the distinction is more important for academic benchmarking cases, but I would appreciate your input here. Thanks!