Này bạn ơi, có phải bạn cũng đang nghe râm ran về mấy anh bạn AI Agent (trợ lý AI thông minh) có thể "hô biến" mọi thứ, phân tích dữ liệu và trả lời mọi câu hỏi kinh doanh trong tích tắc đúng không? Nghe thật hấp dẫn đúng không nào? Cứ tưởng tượng mà xem: chỉ cần hỏi "Tại sao doanh thu tuần trước lại giảm?" là có ngay câu trả lời thông minh, đi kèm ngữ cảnh đầy đủ. Nghe có vẻ như là giấc mơ đã thành hiện thực của mọi nhà quản lý và phân tích dữ liệu!\n\nNhưng mà khoan đã, thực tế phũ phàng hơn một chút đây: Các anh bạn LLM (mô hình ngôn ngữ lớn) lại... tệ bất ngờ trong việc xử lý dữ liệu phân tích. Ngạc nhiên chưa? Không chỉ là vấn đề với "dữ liệu khổng lồ" đâu nhé; mà ngay cả việc hiểu bạn đang hỏi gì và phải tìm kiếm ở đâu trong "núi" cơ sở dữ liệu của bạn, chúng cũng... bó tay. Nếu bạn đang ấp ủ xây dựng các trải nghiệm phân tích thông minh dựa trên AI agent, tin tôi đi, bạn sẽ đụng phải mấy "bức tường" này nhanh thôi.\n\n<b>Những vấn đề mà mấy anh marketing hay... "quên" kể cho bạn nghe</b>\n\n<b>1. LLM "chật vật" với dữ liệu dạng bảng (tabular data)</b>\nTưởng tượng thế này: Mỗi anh LLM được huấn luyện với hàng tỷ từ ngữ, học cách đoán từ tiếp theo trong một câu để tạo ra những đoạn văn "mượt mà". Nhưng dữ liệu phân tích thì lại chẳng theo một "câu chuyện" nào cả. Một cái bảng với 50 cột? Nó đâu phải là một cuốn tiểu thuyết để đọc! Nó là một bản đồ quan hệ đa chiều, nơi mà sự tương quan giữa các con số mới là thứ quan trọng hơn là trình tự.\nThử đưa cho LLM một cái bảng dữ liệu hiệu suất bán hàng được phân cách bằng dấu phẩy mà xem, nó sẽ cố gắng "đọc" như một bài văn xuôi vậy đó. Kết quả là gì? Rất có thể nó sẽ bỏ lỡ những mối quan hệ cốt lõi tạo nên ý nghĩa và những suy luận giá trị.\n<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zgd7ev0hcrcn7xw2c7gg.png' alt='Kết quả đánh giá LLM về khả năng tạo truy vấn SQL'>\n\n<b>2. Khả năng viết SQL của LLM: "Hên xui" là chính!</b>\nDù được tung hô ầm ĩ về khả năng viết code, nhưng trên thực tế, các LLM hiếm khi viết được câu lệnh SQL hoàn hảo ngay từ lần đầu tiên. Chúng tôi đã tự kiểm chứng điều này qua công cụ <a href='https://llm-benchmark.tinybird.live/'>đánh giá SQL của LLM</a> do Tinybird phát triển. Và bạn không cần phải tin lời chúng tôi đâu nhé! Nghiên cứu từ Stanford cũng sớm chỉ ra rằng ngay cả các mô hình ngôn ngữ hàng đầu cũng <a href='https://arxiv.org/abs/2407.19517'>vật lộn đáng kể với việc tạo ra các truy vấn SQL phức tạp</a>, đặc biệt là với các phép nối (join) và cú pháp đặc thù của từng cơ sở dữ liệu.\n<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zgd7ev0hcrcn7xw2c7gg.png' alt='Kết quả đánh giá LLM về khả năng tạo truy vấn SQL'>\n\n<b>3. Truy vấn phân tích chạy "rùa bò" sẽ "giết chết" trải nghiệm AI agent</b>\nTrong phân tích dữ liệu, bạn thường xuyên phải truy vấn trên các bảng dữ liệu khổng lồ. Một câu truy vấn được viết "ẩu" có thể chạy mất vài phút (đôi khi là cả chục phút!), hoặc ngốn một lượng tài nguyên máy tính khổng lồ. Điều đó không chỉ là tốn kém về tiền bạc mà còn là một trải nghiệm người dùng cực kỳ khó chịu. Hãy thử tưởng tượng mà xem, người dùng mong đợi các trợ lý AI phản hồi trong vài giây, chứ không phải đợi đến khi uống xong tách cà phê rồi quay lại vẫn chưa thấy kết quả!\n\n<b>4. Vấn đề "cạn kiệt" cửa sổ ngữ cảnh (context window exhaustion)</b>\nNếu các prompt (yêu cầu) của bạn (hoặc các công cụ bạn yêu cầu LLM sử dụng) không được thiết kế tốt, lượng dữ liệu trả về từ truy vấn có thể dễ dàng làm "cạn kiệt" cửa sổ ngữ cảnh (hay còn gọi là bộ nhớ làm việc) của LLM. Ví dụ, bạn hỏi "ai là khách hàng hàng đầu theo doanh thu" và có thể nhận về 10.000 dòng dữ liệu. Các LLM không thể xử lý hiệu quả lượng dữ liệu "khủng" đó, và người dùng thì chắc chắn cũng không thể tiêu hóa nổi từng ấy thông tin đâu nhé!\n<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://dev-to-uploads.s3.amazonaws.com/uploads/articles/65r1ry16nsqc2o0dvwxr.png' alt='Biểu đồ minh họa cửa sổ ngữ cảnh tăng lên theo số lượng hàng dữ liệu trả về từ truy vấn cơ sở dữ liệu'>\n\n<b>5. Dữ liệu của bạn... quá phức tạp!</b>\nCơ sở dữ liệu, kho dữ liệu (data lakes), và kho dữ liệu phân tích (data warehouses), đặc biệt là trong các tổ chức lớn, có thể rất lớn và cực kỳ "lộn xộn". Chúng tôi đã thấy các tổ chức có hàng trăm bảng và các lược đồ (schemas) với hàng trăm cột trong mỗi bảng. Phân tích hiện đại liên quan đến các chế độ xem vật lý (materialized views), điểm cuối API SQL, các lambda truy vấn được tham số hóa, và các mô hình dữ liệu phức tạp. Các LLM được huấn luyện trên các ví dụ SQL chung chung sẽ không tài nào hiểu được kiến trúc cụ thể của bạn. Chúng sẽ đoán, và chúng sẽ... đoán sai (nhưng lại rất tự tin đấy nhé!).\n\n<b>Những gì chúng tôi đã học được khi xây dựng Tinybird MCP Server</b>\nChúng tôi là một trong những đơn vị đầu tiên triển khai máy chủ MCP (một giao thức mới để LLM tương tác với dữ liệu) cho cơ sở dữ liệu phân tích của mình, chỉ hai ngày sau khi Anthropic công bố giao thức này. Và gần đây, chúng tôi đã phát hành <a href='https://www.tinybird.co/blog-posts/introducing-the-tinybird-mcp-server-your-real-time-data-llm-ready'>máy chủ Tinybird MCP được host từ xa</a> cho tất cả người dùng Tinybird, biến một không gian làm việc Tinybird thành một bộ công cụ mà các LLM có thể "suy luận" được.\nKể từ đó, chúng tôi cũng đã xây dựng và tinh chỉnh <a href='https://www.youtube.com/watch?v=pLI1xLxpUTw'>giao diện người dùng Explorations</a>, sử dụng MCP làm nền tảng để giải quyết (hoặc lách) nhiều vấn đề mà chúng tôi đã đề cập ở trên.\nSau khi "vật lộn" với việc xây dựng hàng ngàn truy vấn phân tích bằng LLM, đây là những gì chúng tôi đã học được và thấy hiệu quả:\n\n<b>1. Ngữ cảnh (Context) là Vua!</b>\nĐể phân tích dữ liệu và trả lời các câu hỏi kinh doanh một cách chính xác mà không "nói linh tinh" (hallucinating), các LLM cần ngữ cảnh:\n<ul><li>Ngữ cảnh tĩnh: giúp LLM hiểu các tài nguyên của bạn.</li><li>Ngữ cảnh động và ngữ nghĩa: giúp LLM hiểu dữ liệu của bạn.</li></ul>\nKết hợp lại, chúng giúp LLM ánh xạ ý định người dùng với dữ liệu của bạn và tạo ra các truy vấn phân tích giải thích "những gì đang diễn ra" trong doanh nghiệp của bạn.\nCung cấp cho LLM một lược đồ (schema) là ổn khi bạn có hai hoặc ba bảng được đặt tên tốt với vài cột và một trường hợp sử dụng đơn giản. Nhưng điều đó sẽ không hiệu quả khi bạn muốn LLM hiểu toàn bộ doanh nghiệp và tất cả dữ liệu của nó. Tuy nhiên, đây là một số kỹ thuật giúp LLM hiểu tài nguyên của bạn:\n\n<b>a. Hãy ghi lại mọi thứ như là ngữ cảnh cho LLM</b>\nCác chế độ xem vật lý (materialized views), các điểm cuối API, thậm chí cả các tham số mà các điểm cuối đó chấp nhận, đều phải được mô tả theo cách mà LLM hiểu được: bằng văn bản, dấu đầu dòng, cấu trúc (ví dụ: thẻ XML), v.v. Một bộ hướng dẫn tổng thể cho mỗi nhóm tài nguyên cũng rất hữu ích. Quan trọng nhất, bạn phải hướng dẫn LLM sử dụng các mô tả đó làm ngữ cảnh.\nKhi chúng tôi thiết kế các pipe (đường ống) và nguồn dữ liệu của Tinybird, chúng tôi đã thêm khả năng bao gồm một mô tả. Lúc đó, nó chỉ là một cải tiến nhỏ về chất lượng cuộc sống cho người đọc. Giờ đây, khi các trường hợp sử dụng AI agent bùng nổ, đó lại là một trong những đoạn mã quan trọng nhất mà bạn có thể viết trong Tinybird. Tạm biệt những mô tả ngắn gọn, chào đón những giải thích chi tiết và toàn diện!\nVí dụ về cách mô tả chi tiết nguồn dữ liệu `orders`:\n<pre><code>DESCRIPTION &gt; The `orders` table contains raw transactional data representing customer purchases. Each row corresponds to a single order line item and includes metadata about the product, customer, geography, and revenue. This table powers all revenue-related analytics across: - <b>Time</b>: via `timestamp` - <b>Geography</b>: via `country` - <b>Product dimensions</b>: via `product_id` and `category` - <b>Customer behavior</b>: via `customer_id` ### Column semantics and behaviors: - `order_id`: Unique identifier for each order line. Not necessarily globally unique across customers. - `timestamp`: The time when the order occurred. Used for time-series analysis and trend detection. - `customer_id`: Internal identifier for the customer. High-cardinality. Used to group behavior or analyze cohorts. - `country`: ISO 2-letter country code (e.g., \"US\", \"DE\", \"ES\"). Used for geographic breakdowns. - `product_id`: Unique identifier for the product SKU. High-cardinality. Can be linked to a product catalog if available. - `category`: Mid-cardinality grouping of products (e.g., \"Electronics\", \"Apparel\", \"Books\"). Good for segmentation and drilldowns. - `quantity`: Number of items purchased in the order. - `unit_price`: Price per item at the time of purchase. - `revenue`: Total amount paid for this line (`unit_price * quantity`). Used for sales aggregation. ### Relationships and usage patterns: - Each order line is tied to a single product and customer. - Common aggregations include: total revenue, order count, avg order value (AOV), revenue per country/category. - LLMs should use `timestamp` for any time filtering (e.g., \"last week\"). - `revenue` is the key metric for trend analysis, anomaly detection, and business health checks. - Can be grouped by `country` or `category` for higher-level insights. - Expected to be used with rolling windows, week/month aggregates, and MoM/YoY comparisons. ### Notes for LLMs: - Use `sum(revenue)` to compute total sales. - Use `avg(revenue)` or `sum(revenue)/countDistinct(order_id)` to compute AOV. - Combine `country` + `timestamp` to compare revenue across time and region. - To detect a drop in revenue, compare recent time slices (e.g. week-over-week or month-over-month).TOKEN \"revenue\" APPENDSCHEMA &gt; `order_id` UInt64 `json:$.order_id`, `timestamp` DateTime `json:$.timestamp`, `customer_id` UInt64 `json:$.customer_id`, `country` LowCardinality(String) `json:$.country`, `product_id` UInt64 `json:$.product_id`, `category` LowCardinality(String) `json:$.category`, `quantity` UInt32 `json:$.quantity`, `unit_price` Float64 `json:$.unit_price`, `revenue` Float64 `json:$.revenue`ENGINE MergeTreeENGINE_PARTITION_KEY toYYYYMM(timestamp)ENGINE_SORTING_KEY (timestamp, country)ENGINE_TTL timestamp + INTERVAL 12 MONTH</code></pre>\n\n<b>b. Cung cấp dữ liệu mẫu</b>\nNhư đã nói ở trên, dữ liệu lớn làm cạn kiệt cửa sổ ngữ cảnh của LLM. Vậy nên, việc sử dụng các tập con dữ liệu sẽ giúp nén ngữ cảnh trong khi vẫn đảm bảo độ chi tiết cần thiết:\n<ul><li>Chạy một truy vấn nhỏ chỉ với vài dòng để cho LLM thấy mỗi bảng hoặc tài nguyên trả về gì.</li><li>Cung cấp quyền truy cập vào các chế độ xem đã được tổng hợp sẵn (pre-aggregated views) để cung cấp quyền truy cập vào chuỗi thời gian, bộ đếm chiều dữ liệu duy nhất và phạm vi số.</li></ul>\n\n<b>c. Tạo các mô hình ngữ nghĩa (semantic models)</b>\nCác mô hình ngữ nghĩa giúp LLM "hiểu" sâu hơn về dữ liệu của bạn. Chúng giải thích:\n<ul><li>Các sự kiện (facts): các giá trị số.</li><li>Các chiều (dimensions): các danh mục và thời gian.</li><li>Các chỉ số (metrics): các giá trị tổng hợp.</li></ul>\nVà trích xuất các mẫu dữ liệu từ:\n<ul><li>Các giá trị mẫu.</li><li>Phạm vi thời gian.</li><li>Phân phối số.</li><li>Thông tin về tính chất "cardinality" và tính duy nhất.</li><li>Siêu dữ liệu lược đồ (schema metadata) và kiểu dữ liệu.</li><li>Các câu hỏi và truy vấn mẫu của người dùng.</li><li>Mối quan hệ giữa các bảng.</li></ul>\nChúng có thể được xây dựng động hoặc bạn có thể sử dụng một LLM để tạo chúng một cách tĩnh.\nĐây là một ví dụ về mô hình ngữ nghĩa chi tiết cho bảng `orders`:\n<pre><code>## `orders` Datasource This data source contains revenue-generating transactions from customer purchases. Each row represents a line item in an order and includes time, location, product, and financial details. It is the core table for revenue analytics across time, geography, and product hierarchy. --- ### 1. Schema Overview - <b>Engine</b>: `MergeTree` A high-performance table optimized for time-based queries and aggregations. - <b>ENGINE_PARTITION_KEY</b>: `toYYYYMM(timestamp)` Used to segment data by month for efficient storage and access. - <b>ENGINE_SORTING_KEY</b>: `(timestamp, country)` Enables fast retrieval of time-based and region-based queries. - <b>ENGINE_TTL</b>: `timestamp + INTERVAL 12 MONTH` Retains historical data for one year. - <b>Columns</b>: - `order_id` (UInt64): Unique identifier per order line. Not globally unique but stable within ingestion. - `timestamp` (DateTime): Timestamp of the transaction. Used for temporal filtering and partitioning. - `customer_id` (UInt64): Internal customer ID. High cardinality. Enables user-level and cohort analysis. - `country` (LowCardinality(String)): Country code (e.g., \"US\", \"FR\", \"BR\"). Medium cardinality. - `product_id` (UInt64): Unique product identifier. High cardinality. - `category` (LowCardinality(String)): Product grouping such as \"Electronics\", \"Furniture\", etc. - `quantity` (UInt32): Number of items in the order line. - `unit_price` (Float64): Unit price at the time of transaction. - `revenue` (Float64): Calculated as `quantity * unit_price`. --- ### 2. Key Columns #### `timestamp` - <b>Type</b>: `DateTime` - <b>Format</b>: `YYYY-MM-DD HH:MM:SS` - <b>Example Values</b>: - \"2025-06-30 14:12:08\" - \"2025-07-01 09:45:15\" - <b>Notes</b>: Used for filtering by day, week, month, or rolling windows. #### `revenue` - <b>Type</b>: `Float64` - <b>Range</b>: 0.00 - 10,000.00+ - <b>Distribution</b>: Right-skewed with outliers - <b>Usage</b>: Main fact value for business reporting, KPIs, and trend analysis. #### `country` - <b>Type</b>: `String` - <b>Examples</b>: \"US\", \"DE\", \"BR\", \"ES\" - <b>Cardinality</b>: ~100 - <b>Usage</b>: Geographic filtering, segmentation, and breakdowns. #### `category` - <b>Type</b>: `String` - <b>Examples</b>: \"Electronics\", \"Clothing\", \"Books\" - <b>Cardinality</b>: ~10–30 - <b>Usage</b>: High-level product analysis, useful for bar charts and comparisons. --- ### 3. Facts, Dimensions, and Metrics #### Facts - `revenue` - `quantity` - `unit_price` #### Dimensions - `timestamp` (temporal) - `country` (geographic) - `category` (product) - `customer_id` (entity) #### Metrics - `SUM(revenue)`: Total sales - `COUNT(DISTINCT order_id)`: Unique order lines - `AVG(revenue)`: Average order value (AOV) - `SUM(quantity)`: Total items sold - `SUM(revenue) / COUNT(DISTINCT customer_id)`: Revenue per customer - `SUM(revenue) / COUNT(*)`: Revenue per transaction line --- ### 4. Data Patterns - <b>Time range</b>: Rolling window of 12 months. Mostly active within past 90 days. - <b>Seasonality</b>: Weekly and monthly patterns—sales often spike on weekends or during campaigns. - <b>Currency normalization</b>: Revenue assumed to be in a single currency (e.g., USD). - <b>Country bias</b>: US and EU countries dominate volume. - <b>Skew</b>: 80/20 rule: few categories or customers account for most revenue. - <b>Completeness</b>: All fields are non-null; data is clean and consistently formatted. --- ### 5. Relationships and Join Potential - Can be joined on `product_id` to a product catalog for metadata (not included here). - Can be joined on `customer_id` to a customer profile table. - Often aggregated by `category`, `country`, or `timestamp`. - Not normalized—revenue is fully materialized for fast querying. --- ### 6. Example Questions the LLM Should Be Able to Answer - \"Why did revenue drop last week in the US?\" - \"Which categories contributed most to last month's sales?\" - \"What was the average order value for France in June?\" - \"How does current revenue compare to the same week last year?\" - \"Which customers had the highest spend in Q2?\" - \"Was the revenue drop due to fewer orders or lower AOV?\" - \"Did any category underperform relative to last month?\" --- ### 7. Query Tips for the LLM - Always filter by `timestamp` with explicit ranges (e.g., `&gt;= now() - INTERVAL 7 DAY`) - Use `country` = 'US' or any region as a filter when geographic context is needed - Use `category` for group-by breakdowns - Pre-aggregate when possible using MATERIALIZED views for week/month summaries - Use ratio comparisons (`this_week/last_week`) for trend explanations</code></pre>\nVới một truy vấn như "Tại sao doanh thu tuần trước ở Mỹ lại giảm?", ngữ cảnh tĩnh và các mô hình ngữ nghĩa giúp LLM:\n<ul><li>Chọn các bảng chính cho doanh thu.</li><li>Phát hiện các chiều thời gian để lọc "tuần trước".</li><li>Ánh xạ "US" với một chiều dữ liệu phù hợp.</li><li>Tìm các sự kiện và chỉ số liên quan.</li><li>Hiểu các mối quan hệ, sự bất thường và xu hướng.</li></ul>\nSự khác biệt giữa việc nói "Doanh số giảm 15%" và "Doanh số giảm 15%, nhưng đó là điều bình thường vào thứ Ba, và chúng ta thực sự tăng 23% so với tháng trước" chính là tất cả những gì bạn cần để đưa ra quyết định kinh doanh đúng đắn!\n\n<b>2. Xây dựng các vòng lặp truy vấn (query loops) có khả năng học hỏi</b>\nNgữ cảnh là cần thiết, nhưng chưa đủ đâu nhé! Các LLM cũng cần khả năng truy cập dữ liệu và đặc biệt là khả năng tự động sửa lỗi.\nThay vì cứ hy vọng SQL hoàn hảo ngay lần đầu tiên, hãy áp dụng những điều sau:\n<ul><li>Xác thực các truy vấn trước khi thực thi chúng.</li><li>Chạy các truy vấn `LIMIT 1` để đảm bảo chúng có thể thực thi thành công.</li><li>Truyền các thông báo lỗi trở lại cho LLM cùng với ngữ cảnh. Sử dụng chúng trong một vòng lặp để LLM học hỏi và thử lại với phản hồi.</li></ul>\nVí dụ về vòng lặp truy vấn:\n<pre><code>data = None\nattempts = 0\nfeedback = ""\nwhile attempts &lt; MAX_ATTEMPTS:\n result = llm.generate_sql(schema, prompt, feedback)\n r = requests.get(f\"{TINYBIRD_API_URL}/v0/sql?q={result}\")\n response = r.json()\n data = response.get(\"data\", [])\n if data:\n break\n error = response.get(\"error\")\n feedback += f\"{error}\\n\"\n attempts += 1</code></pre>\nCác thông báo lỗi chi tiết giờ đây quan trọng hơn bao giờ hết!\nĐồng thời: Hãy hướng dẫn LLM áp dụng các <a href='https://www.tinybird.co/blog-posts/5-rules-for-writing-faster-sql-queries'>thực hành tốt nhất về SQL</a>, ví dụ: sử dụng khóa sắp xếp để lọc, lọc trước khi join, chỉ chọn các cột cần thiết, v.v. Những chi tiết này rất quan trọng đối với hiệu suất truy vấn, giúp mọi thứ chạy nhanh như chớp!\n<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://dev-to-uploads.s3.amazonaws.com/uploads/articles/owyj1qte3jfnf9zur609.png' alt='Sơ đồ luồng tạo và xác thực truy vấn SQL của LLM với xử lý lỗi'>\n\n<b>3. Sử dụng bộ đánh giá LLM-as-a-judge</b>\nKhi các lỗi tạo truy vấn khó xác định một cách chắc chắn, hãy sử dụng một LLM thứ hai (như một "thẩm phán") để đánh giá:\n<ul><li>Phát hiện các vấn đề về cú pháp, hàm không hợp lệ, hoặc tài nguyên không tồn tại.</li><li>Đưa kết quả đó trở lại cho LLM tạo truy vấn.</li></ul>\nVòng lặp này giúp lấp đầy khoảng trống phản hồi mà nếu không có, các AI agent sẽ bị "treo" giữa chừng và không thể tự học hỏi để cải thiện.\n\n<b>Đây mới là điều đột phá thực sự!</b>\nSự "phép màu" thực sự xảy ra khi bạn ngừng cố gắng làm cho các LLM hoàn hảo trong việc viết SQL, và bắt đầu làm cho chúng hoàn hảo trong việc hiểu doanh nghiệp của bạn, dữ liệu của nó, và cả cơ sở hạ tầng, công cụ phân tích dữ liệu mà bạn đã có sẵn.\nKhi một LLM biết rằng điểm cuối `conversion_rate` của bạn chấp nhận các phạm vi ngày và phân đoạn người dùng, hiểu rằng các buổi sáng thứ Ba luôn có xu hướng chậm lại, và có thể giải thích tại sao bộ phận marketing lại quan tâm đến phân tích nhóm (cohort analysis), đó là lúc bạn có được phân tích thực sự thông minh. Nó không chỉ là tạo ra các truy vấn hoàn hảo. Mà là tạo ra những hiểu biết sâu sắc hoàn hảo!\n\n<b>Chúng ta sẽ đi đến đâu từ đây?</b>\nCác công ty giải quyết được vấn đề phân tích bằng AI agent sẽ không phải là những công ty có LLM tốt nhất đâu. Mà họ sẽ là những người thu hẹp được khoảng cách giữa các câu hỏi của con người, được hình thành bằng ngôn ngữ tự nhiên, và những sắc thái tinh tế của dữ liệu đang được truy vấn.\nĐiều đó có nghĩa là xây dựng các hệ thống có khả năng:\n<ul><li>Hiểu dữ liệu của bạn tốt như các chuyên viên phân tích hàng đầu.</li><li>Lặp lại để đạt được câu trả lời chính xác – không chỉ là cú pháp đúng.</li><li>Cung cấp ngữ cảnh, không chỉ là các phép tính khô khan.</li><li>Mở rộng quy mô theo độ phức tạp của bạn, chứ không phải bất chấp nó.</li></ul>\nTương lai của phân tích là làm cho tư duy phân tích trở nên dễ tiếp cận với tất cả mọi người cần nó. Và điều đó sẽ xảy ra... nhanh chóng!

Lê Lân

14/08/2025

Khám phá cách theo dõi hành vi người dùng trong ứng dụng Flutter thông qua các sự kiện xem màn hình (screen view) và đóng ứng dụng (app close). Hướng dẫn chi tiết triển khai với Firebase Analytics, NavigatorObserver, và xử lý vòng đời ứng dụng để thu thập dữ liệu giá trị, giúp bạn tối ưu trải nghiệm người dùng.

Lê Lân

20/07/2025

Khám phá báo cáo đánh giá khả năng tạo SQL của 19 mô hình LLM phổ biến trên bộ dữ liệu 200 triệu dòng GitHub. Xem điểm hiệu suất, độ chính xác và so sánh với con người.

Lê Lân

24/06/2025

Khám phá Snowflake Copilot Inline – tính năng AI đột phá tích hợp trực tiếp vào Snowflake Workspaces, giúp bạn viết, tối ưu SQL và sửa lỗi cực nhanh, biến bạn thành 'phù thủy' dữ liệu chỉ trong tích tắc. Đừng bỏ lỡ công cụ thay đổi cuộc chơi này!

Lê Lân

22/06/2025