Recently, when I was shopping on GitHub, I found a very interesting project-FocusSearch/focus_mcp_sql. As a front-end coder who has a little research on Text2SQL, I can't help but want to talk to you about this tool. It is not as "high-end" as those common large-scale model-based frameworks, but instead uses a more down-to-earth approach to solve the problem. Next, I will start with the old story of Text2SQL, and show you what this project can do, and imagine a scenario by the way. Finally, I will talk about why I think it is worth a try by the developers.
What is Text2SQL? A cliché story
If you are a troll in the data circle, SQL is definitely not unfamiliar with it. It is the "language" of the database, allowing us to dig out the information we want from a bunch of tables. But the problem is that not everyone is willing to spend time learning SQL, especially those bosses or analysts who are busy making reports every day. Text2SQL came into being - simply put, it can turn the casual "How is the sales in the last month" you say into a regular SQL statement.
In the early years, Text2SQL relied on rules and statistical models, and its effect was better than nothing. Later, the Big Language Model (LLM) became popular, and frameworks like this began to use LLM to "translate" natural language, and the effect was indeed improved a lot. Sounds beautiful, right? But as you use it, you will find that things are not that simple.
Those "pits" of LLM framework
I have tried several Text2SQL tools based on LLM, and after all I can only say that it is a bit "love and hate". I love it because it can do work, I hate it because some problems drive me crazy:
-
Rely on big models to support the field
These tools are inseparable from LLM. If you want to have a better effect, you have to use stronger models, such as the cutting-edge product like GPT-4. But this thing is as slow as a snail to climb, and the cost is ridiculously high, and small companies or independent developers can't afford it. -
Hallucination problems, it's hard to defend against
Everyone understands LLM’s “nonsense”? I once wanted to check "the product with the highest sales volume last week", but it generated a SQL with a completely wrong date for me. The data that ran out could tell at a glance that something was wrong. The key is that I have to debug myself, but if I know how to write SQL, why do you do? -
Black box operation, totally confused
The generation process is completely a black box, and I have no idea how SQL came about. It is handed over to colleagues who don’t understand the code. When they get the result, they can only bite the bullet and write it. If they make mistakes, they don’t know how to change it. Trust is really hard to establish. -
The bigger the model, the better, but the cost is not small
Want to have fewer hallucinations and more accurate heads? Then you have to use a better model. But this is in a dead loop: the larger the model, the slower the speed, and the weaker the wallet. Real-time application? Don't even think about it.
To be honest, these questions made me a little disappointed with LLM-driven Text2SQL. It was not until I flashed focus_mcp_sql that I felt that I had found some new ideas.
focus_mcp_sql: Play with Text2SQL from a different angle
focus_mcp_sql is a small project encapsulated based on the DataFocus API. Although it is inconspicuous, its ideas are quite clever. It did not directly criticize Natural Language into SQL in one breath, but instead took two steps:
-
Step 1: From natural language to keywords
Use a big model to "translate" your words into several keywords, such as "the last month", "the highest sales" and "product". This step is fast, low-cost, and you can understand the keywords generated at a glance. If it is wrong, just change the keywords directly, and the problem of hallucinations is basically pinned to the cradle. -
Step 2: From keywords to SQL
The process of using these keywords to generate SQL is determined and claims to be 100% accurate. There is no complicated reasoning, just map it directly, and it is so fast that it can fly.
What are the benefits of this step-by-step gameplay? I have summarized a few:
-
Fast, save money
The big model only does lightweight work (generate keywords), and the rest is left to deterministic rules, which makes the calculation much smaller. This is more than a little more efficient than LLM generating SQL in one go. -
The hallucinations are controllable, and non-technical personnel can do it
The keywords are there, and you can tell whether it is right at a glance. Unlike traditional frameworks that directly throw you a bunch of SQL, you have to guess what's wrong. Even the boss can check it out. -
Transparent, use with confidence
You can see the process from beginning to end, not the feeling of "a SQL falling from the sky". If transparent, the result will naturally be more credible. -
So accurate
Keywords to SQL are hard mappings, there is no randomness, and if you are wrong, it is also a problem with keywords, just change them. It is much more reliable than LLM's "Xuanshen Cheng".
What's even cooler is that this project still pressesMCP Standard ProtocolEncapsulated, what does it mean? Simply put, it is possible to easily call it from a big model and integrate it into your system like building blocks. There are also command line call examples on GitHub, such as:
focus_mcp_sql --query "The highest sales product in the last month" --output sqlYou can use the code by simply changing it. If you don’t understand it, you can go to the community to ask about it. The developers are so friendly.
One scenario: Help Xiao Li get the sales report
In order to let everyone experience this tool more intuitively, I made up for a scene. Suppose you are Xiao Li, a market analyst at a home e-commerce company, and the leader asks you to check "the product with the highest sales volume in the past month." You don't know how to SQL, but you still have to work hard.
Using the traditional LLM framework:
You open it and type "The product with the highest sales volume in the last month", and it spits you a SQL:
SELECT product_name, SUM(sales) as total_sales
FROM sales_table
WHERE sale_date >= '2023-09-01'
GROUP BY product_name
ORDER BY total_sales DESC
LIMIT 10;
When the result was found, the data was incorrect - What the hell is "2023-09-01"? It's not the "last month" at all! You stared at this pile of code and didn't know how to change it. You could only go to help with development, but you were criticized, "You can't write SQL by yourself." Embarrassing.
Use focus_mcp_sql:
You change to focus_mcp_sql and enter the same query. The first step is to give you a few keywords:
- "Latest Month"
- "The highest sales"
- "product"
You glance at it and feel it is OK. After confirming it, it will be generated immediately:
SELECT product_name, SUM(sales) as total_sales
FROM sales_table
WHERE sale_date >= DATE_SUB(CURDATE(), INTERVAL 1 MONTH)
GROUP BY product_name
ORDER BY total_sales DESC
LIMIT 10;
When I ran out, I saw it perfect! The "last month" uses dynamic date function, and the data is not accurate. You didn't touch SQL at all, you can do it by checking keywords. When the leader asks you what you did, you can still say confidently: "I can't make any mistakes in the keywords I adjusted myself!"
This experience is simply too exciting. The black box and hallucination problems of traditional frameworks basically do not exist here.
Technical details and developer benefits
To be honest, I was quite curious at the beginning how this "keyword to SQL" was implemented. After looking at the GitHub repository, I guess it may be based on some predefined mapping rules in the DataFocus API. For example, the "last month" corresponds directlyDATE_SUB(CURDATE(), INTERVAL 1 MONTH), this certainty makes me feel much more at ease.
In addition, the details of MCP encapsulation are quite surprising. MCP (Model Context Protocol) is a standard specially designed for model integration. After focus_mcp_sql is encapsulated, developers can use it as a plug-in and directly stuff it into the workflow of the big model. For example, if you use LangChain or other AI frameworks, you can use it as a plug-in tool.
In terms of code, the project has given many examples. The command line call is so simple that it can be run by simply changing it. If you are a novice and the documents are clear enough, you can still shout in the community, and there will always be someone who will help you.
At the end: Why recommend it?
After using the Text2SQL tool a few times, my favorability for focus_mcp_sql has really skyrocketed. It is not as "cold" as those LLM frameworks, but it has a bit of "popular" flavor - fast, accurate, transparent, and not expensive. Developers can save a lot of trouble when using it, especially when they need to make tools for non-technical users. This transparency and controllability are simply a life-saving straw.
If you want to try it, go straightGitHub repositoryTake a look. The code is there, and the documentation is also there, so it's not difficult to run. When you encounter a problem, it is better to find the answers in the community than to think about it yourself. In Text2SQL, focus_mcp_sql is a new idea and is worth playing.
What do you think? Do you have the urge to use it to make a little trouble? Come and leave a message to talk about your thoughts!