21 ms·
Show HN: Dataherald AI – Natural Language to SQL Engine
Hi HN community. We are excited to open source Dataherald’s natural-language-to-SQL engine today (https://github.com/Dataherald/dataherald https://github.com/Dataherald/dataherald). This engine allows you to set up an API from your structured database that can answer questions in plain English.
GPT-4 class LLMs have gotten remarkably good at writing SQL. However, out-of-the-box LLMs and existing frameworks would not work with our own structured data at a necessary quality level. For example, given the question “what was the average rent in Los Angeles in May 2023?” a reasonable human would either assume the question is about Los Angeles, CA or would confirm the state with the question asker in a follow up. However, an LLM translates this to:
select price from rent_prices where city=”Los Angeles” AND month=”05” AND year=”2023”
This pulls data for Los Angeles, CA and Los Angeles, TX without getting columns to differentiate between the two. You can read more about the challenges of enterprise-level text-to-SQL in this blog post I wrote on the topic: https://medium.com/dataherald/why-enterprise-natural-language-to-sql-is-hard-8849414f41c https://medium.com/dataherald/why-enterprise-natural-languag...
Dataherald comes with “batteries-included.” It has best-in-class implementations of core components, including, but not limited to: a state of the art NL-to-SQL agent, an LLM-based SQL-accuracy evaluator. The architecture is modular, allowing these components to be easily replaced. It’s easy to set up and use with major data warehouses.
There is a “Context Store” where information (NL2SQL examples, schemas and table descriptions) is used for the LLM prompts to make the engine get better with usage. And we even made it fast!
This version allows you to easily connect to PG, Databricks, BigQuery or Snowflake and set up an API for semantic interactions with your structured data. You can then add business and data context that are used for few-shot prompting by the engine.
The NL-to-SQL agent in this open source release was developed by our own Mohammadreza Pourreza, whose DIN-SQL algorithm is currently top of the Spider (https://yale-lily.github.io/spider https://yale-lily.github.io/spider) and Bird (https://bird-bench.github.io/ https://bird-bench.github.io/) NL 2 SQL benchmarks. This agent has outperformed the Langchain SQLAgent anywhere from 12%-250%.5x (depending on the provided context) in our own internal benchmarking while being only ~15s slower on average.
Needless to say, this is an early release and the codebase is under swift development. We would love for you to try it out and give us your feedback! And if you are interested in contributing, we’d love to hear from you!
- xfalcox 3y agoWe are experimenting in this area, as a way to provide a way for community managers to query their Discourse PG database using natural language. Your product is very interesting. Maybe we can collaborate here, as Discourse is a standard Rails database schema on PostgreSQL and could be a good way to show your tool working in a real database.
- aazo11 3y agoHi -- would love to connect and discuss more. Shoot me an email amir at dataherald.com.
- klft 3y agoCould you provide more details about your approach? Is the context store based in vector-embeddings?
- MrezaPourreza 3y agoI'd be delighted to assist you with your inquiries. Indeed, the context store interacts with vector databases to retrieve samples based on vector embeddings and cosine similarity.
- stormfather 3y agoIn your experience, in general when comparing vector embeddings, what layer of the net works best? Are the embeddings from the first hidden layer, the second, the last, etc?
- DylanDmitri 3y agoI’ve seen impressive demos with just LLM direct to SQL. Can’t wait to see what people build with these new tools.
- aazo11 3y agoHi Dylan -- new GPT-4 class LLMs have gotten good at writing correct SQL, but while the SQL they generate almost always executes correctly they often write SQL that generates incorrect answers to the question. Some reasons for this can be the business context or definition is not in the table schema, or if the correct query is complex and requires multiple joins.