ChatBI Product Design: Making Data Queries as Natural as Conversation

Introduction

#

I’ve been exploring ways to let non-technical people query data easily, which led me to the ChatBI space. The traditional data analysis pipeline is just too long: business teams submit requests, analysts write SQL, run queries, create charts, send emails. From question to answer, it takes hours at best, days at worst. ChatBI’s premise is simple—users speak a sentence, the system returns charts and reports. Sounds great, but there are plenty of pitfalls in practice. Let’s walk through the product design thinking and key challenges behind ChatBI.

What Problem Does ChatBI Actually Solve

#

Traditional data analysis has three persistent pain points.

First, high barriers. To query data you need to know SQL, understand table schemas, and grasp the business metrics framework. These aren’t skills you pick up in a couple of days, so companies have to maintain a team of data analysts.

Second, slow response times. From submitting a request to getting results, it takes hours at best, days at worst. Business moves fast, and by the time the data arrives, the moment has passed.

Third, shallow exploration. Under the traditional model, the cost of doing a deep-dive analysis is high. Most people stick to fixed dashboards and rarely do exploratory or root-cause analysis.

ChatBI’s core value proposition is straightforward: users speak a sentence, the system understands it, generates SQL, and renders a chart. With well-crafted prompts, it can also produce written analysis reports. What takes a traditional analyst days can be done by ChatBI in minutes. This isn’t about replacing analysts—it’s about freeing them to do higher-value deep research while ChatBI handles routine queries¹.

Behind “One Sentence, One Chart”: NL2SQL

#

ChatBI’s product logic can be summarized in a single pipeline:

User speaks a sentence → System extracts metrics, dimensions, filters, and time constraints → Generates SQL → Combines with visualization capabilities to render charts

Let’s say a user asks: “How much did Q1 sales in East China grow year-over-year?”

The system needs to:

1. Identify the metric: Sales amount (mapped to a specific database field)
2. Identify dimensions: East China (region dimension), Q1 (time dimension)
3. Identify comparison logic: Year-over-year growth (requires querying the same period last year)
4. Generate SQL: Translate all of the above into a database query
5. Choose the right chart: Comparison data works best with bar charts or line charts
6. Render results: Display the chart and key figures to the user

This is what’s known as NL2SQL (Natural Language to SQL)²—using a large language model as a “translator” that converts natural language into SQL that databases can understand.

Three Key Implementation Challenges

#

It sounds great in theory, but in practice there are three unavoidable challenges.

How Does the LLM Understand Your Data Model

#

Database fields are typically English abbreviations—sal_amt, region_id, yr_qtr. How does the LLM know that sal_amt means sales amount, or region_id means region?

The solution is to include field meanings in the Prompt. You spell out each table’s purpose, each field’s Chinese name and business definition in the system prompt, giving the LLM a “dictionary” to reference when interpreting user questions. This sounds simple, but in practice, when you’re dealing with complex table schemas, the prompt engineering workload adds up fast.

How Do You Guide Users to Ask Good Questions

#

Most users facing an open-ended analysis system either don’t know what to ask, or ask questions the system can’t answer.

The solution is question recommendation. The system suggests high-frequency questions or potentially valuable analysis directions based on the user’s role and query history. For example, if the user is an East China regional sales manager, the system might recommend questions like “This month’s sales trend for East China” or “City-level performance rankings in East China.” This is essentially a recommendation system problem³ that needs to incorporate user profiles and data permissions.

How Do You Make Results Visual and Readable

#

A raw table of numbers isn’t very useful. You need charts to present data intuitively.

The solution is to integrate visualization plugins. The system automatically selects the appropriate chart type based on data characteristics—line charts for trends, bar charts for comparisons, pie charts for proportions. You also use prompts to control the LLM’s output format, ensuring the data can be correctly rendered by chart components.

One extension worth mentioning: root-cause analysis. Through prompt engineering, the LLM can not only return data results but also analyze underlying causes. If a user asks “Why did East China sales drop?”, the system doesn’t just show the decline—it automatically correlates potential contributing factors.

Three Product Forms of ChatBI

#

Depending on use case and implementation complexity, ChatBI can take three forms.

Form 1: Full Database Query

#

Users ask anything, and the system searches across multiple tables for relevant fields. For instance, asking “sales amount by region” requires the system to find and join fields across sales tables, region tables, and product tables. Highest difficulty, but best user experience. Suitable for scenarios with relatively clean data models and manageable table complexity.

Form 2: Specified Data Model Query

#

The data model is known upfront, and queries run against it. This is equivalent to telling the system in advance “this question should query this table,” reducing the LLM’s comprehension burden. A middle-ground approach with moderate implementation difficulty, suitable for fixed business scenarios with well-understood data models.

Form 3: KPI Deep Analysis

#

Focuses on the metrics companies track daily (DAU, GMV, conversion rate), paired with complex prompts for deep analysis. The metric definitions and analysis frameworks are pre-set, and the LLM mainly handles report generation and root-cause analysis. Lowest difficulty and most direct value—ideal for starting with an MVP to validate effectiveness before expanding to more complex scenarios⁴.

Technical Implementation: Building a Data Agent

#

To quickly prototype a ChatBI demo, you can use low-code platforms like Coze or Dify⁵. The core idea is to build a Data Agent with these key steps:

1. Define the data model: Configure database table schemas and field meanings
2. Design the Prompt: Specify the Agent’s role (data analyst), capability boundaries (what data it can query), and output format (charts + text)
3. Configure tools: Database query connectors, visualization chart plugins
4. Set up the workflow: User input → Intent recognition → SQL generation → Data query → Chart rendering → Result output

A typical prompt structure might look like this:

Role: You are a professional data analyst
Capabilities: Query the database based on user questions and generate visualizations
Data Model:
  - Table: loan_application
    Fields:
      - loan_amt: Loan amount (CNY)
      - region_id: Region code
      - apply_date: Application date
Output Format: Tabular data + recommended chart type + brief analysis text

One caveat though: building a production-grade ChatBI product requires the team to have at least basic data competency (knowing SQL is a minimum). A demo is not the finish line. Real-world data model complexity far exceeds what you encounter in prototypes. Permission controls, data security, query performance optimization, error handling—these are problems that demos gloss over but production systems must address head-on.