Nao - Cursor cho dữ liệu

• Trình soạn thảo mã AI dựa trên VS Code, chuyên cho công việc dữ liệu, kết nối trực tiếp với BigQuery/Snowflake/Postgres để cung cấp tự động sinh mã theo schema dữ liệu và kiểm tra chất lượng
• Trong khi các công cụ dựa trên LLM hiện có tự động hoàn thành SQL mà không nhận biết schema dữ liệu, nao tạo ra mã SQL/Python/YAML chính xác bằng tab AI dựa trên RAG và công cụ agent
• Có thể viết, chạy và trực quan hóa pipeline SQL trong một giao diện duy nhất
• Pipeline Python cũng được hỗ trợ trong cùng môi trường, đồng thời hỗ trợ cả quy trình dbt
• Có thể xem ngay sự khác biệt của dữ liệu kết quả trước và sau khi thay đổi mã cùng với các vấn đề về chất lượng dữ liệu, giúp triển khai nhanh mà không cần kiểm thử hoặc tránh sai sót
• Các mục đích sử dụng chính
  • Dùng để xây dựng pipeline dữ liệu (SQL, dbt, v.v.)
  • Phát hiện thiếu dữ liệu/trùng lặp/ngoại lệ
  • So sánh dữ liệu môi trường phát triển với môi trường vận hành
  • Chạy và tóm tắt các bài kiểm thử được định nghĩa sẵn
• Tích hợp với dbt, công cụ BI và kho dữ liệu, mang đến môi trường IDE phù hợp cho cả kỹ sư dữ liệu, nhà phân tích và nhà khoa học dữ liệu
• Hỗ trợ BigQuery, Snowflake, Postgres và sắp hỗ trợ Databricks, Iceberg, Redshift
• Cũng sẽ tích hợp với Looker, Power BI, Metabase, Tableau
• Hiện tại chỉ có bản Mac, sắp có cho Windows/Linux
• Điểm khác biệt so với Cursor và MCPs
  • Cursor cần nhiều lần gọi MCP để lấy ngữ cảnh dữ liệu, còn Nao luôn có sẵn trong một RAG duy nhất
  • MCPs chỉ hoạt động hạn chế bên trong Cursor và khả năng thích ứng giao diện cũng kém hơn
  • Nao được đóng gói sẵn, không cần cấu hình, cài extension, xác thực hay xây dựng CI/CD; đây là điểm mạnh giúp cả người không chuyên cũng cải thiện trải nghiệm phát triển

FAQ

• Ai nên dùng nao?
  • Người viết SQL, kỹ sư phân tích dbt, nhà khoa học dữ liệu, kỹ sư dữ liệu và mọi thành viên trong đội dữ liệu
• Khác gì với Cursor?
  • Đây là IDE được tối ưu cho ngữ cảnh dữ liệu với sinh mã dựa trên nhận biết schema dữ liệu, kiểm tra chất lượng dữ liệu tự động và dự đoán tác động của thay đổi
• Hỗ trợ ngôn ngữ nào?
  • Hỗ trợ mọi ngôn ngữ, nhưng đặc biệt được tối ưu cho SQL
• Nó giúp gì cho quy trình dbt?
  • Hiểu các model, source, tài liệu, bài kiểm thử và lineage ở cấp cột của dbt, đồng thời cung cấp tự động hoàn thành và trực quan hóa
• Bảo mật dữ liệu thế nào?
  • Dữ liệu chỉ được xử lý cục bộ và cần có sự cho phép của người dùng trước khi gửi tới LLM
  • Mã hoặc schema không được lưu trữ, chỉ sử dụng embedding

[GN⁺]

Ý kiến trên Hacker News

• Nhiều dự án dữ liệu dựa trên LLM mang lại sự linh hoạt và hữu ích, nhưng khó lặp lại và thiếu tính tương tác; Nao được đánh giá là hiện thực hóa tốt ý tưởng này. Buckaroo do tôi tạo ra là một UI bảng dữ liệu cho Jupyter và Pandas/Polars, cho phép xem dữ liệu ngay lập tức bằng các bảng hiện đại, histogram và thống kê tóm tắt. Hôm qua tôi đã phát hành tính năng tự động làm sạch cho Buckaroo; nó chọn cách làm sạch dữ liệu theo heuristic và cung cấp mã đã được xác nhận. Tốc độ rất nhanh, dưới 500ms. Có thể thử nhiều chiến lược làm sạch và chọn phương án phù hợp nhất. Những bài toán đơn giản thì không cần đi qua LLM. Nó là mã nguồn mở và có khả năng mở rộng rất tốt

  • Tôi cũng đang phát triển thứ gì đó rất giống như vậy; chưa hoàn thiện bằng Buckaroo, nhưng tôi nghĩ ứng dụng nhúng trong notebook khá hữu ích

  • Tôi rất thích view có thể trực quan hóa data profiling; tôi nghĩ đó là phần cốt lõi quan trọng để hiểu dữ liệu

• Tôi thấy đây là một ý tưởng rất hay; tôi tò mò không biết mô hình Tab được huấn luyện như thế nào, liệu là Fill in the middle hay dựa trên edit history. Hôm qua có người chia sẻ một bài blog tương tự về tự động hoàn thành tab của Cursor, tôi đọc và thấy rất thú vị

  • Chúng tôi dùng mô hình Fill in the middle (các mô hình tự huấn luyện từ Mistral và Qwen), đồng thời đưa cả ngữ cảnh dữ liệu của người dùng vào. Tùy theo vị trí con trỏ, chúng tôi dùng một SQL parser tự xây để cung cấp ngữ cảnh schema phù hợp

• Sau khi dùng liên tục vài tuần, tôi cảm nhận workflow thực sự được cải thiện rất nhiều. Tôi chọn nó hơn một nửa số lần thay vì VSCode và extension. Chat, worksheet và tính năng theo dõi lineage của cột cho exploratory data analysis thực sự là thứ thay đổi cuộc chơi trong phát triển dbt. Những tính năng này cho cảm giác được thiết kế cực kỳ tỉ mỉ để khớp với cách tôi làm việc thực tế. Claire và Christophe cũng phản hồi ngay với feedback, thêm và sửa tính năng rất nhanh; sản phẩm đang tiến hóa rất nhanh theo đúng hướng

  • Cảm ơn những lời tốt đẹp, và cũng cảm ơn bạn đã giúp cải thiện nao

• Tôi thấy nó thực sự hấp dẫn; tôi đã xem video YouTube nhiều lần và đặc biệt ấn tượng với cách nó rút ngắn feedback cycle. Rất tuyệt

  • Cảm ơn bạn, đúng là việc rút ngắn vòng lặp phản hồi chính là mục tiêu của chúng tôi. So với kỹ sư phần mềm, các đội dữ liệu thường có feedback loop dài hơn, nên chúng tôi đang cố gắng giảm điều đó để đưa dữ liệu gần hơn với luồng phát triển

• Tôi muốn hỏi liệu cái này chỉ hoạt động khi dùng raw SQL hay không. Dự án của tôi dùng Postgres + TypeScript và viết truy vấn bằng query builder như Kysely; tôi muốn biết liệu có thể dùng ngay bây giờ không

  • Hiện tại Tab hoạt động tốt nhất với raw SQL (file SQL thuần hoặc chuỗi SQL). Tuy vậy, nếu dùng chat/agent thì bạn có thể nói rằng mình đang dùng Kysely và truyền ngữ cảnh warehouse, khi đó nó vẫn xử lý được ở mức độ nào đó. Tôi mới nghe đến Kysely lần đầu, nhưng xem GIF giới thiệu dự án thì autocomplete có vẻ khá ổn. Khác với cách tiếp cận kiểu tab, nhưng rất thú vị

• Tôi muốn biết dữ liệu/prompt của mình được gửi tới mô hình ở mức nào. Schema thì không sao, nhưng dữ liệu trong warehouse thường là dữ liệu nhạy cảm. Tôi đoán là có gói enterprise, nhưng muốn biết trước liệu dữ liệu/kết quả ngoài mã nguồn có được gửi lên server hay chỉ gửi code

  • Bản thân nội dung dữ liệu sẽ không được gửi tới mô hình trừ khi người dùng cho phép rõ ràng. Trên server chỉ lưu embedding của codebase và schema dữ liệu. Nội dung dữ liệu chỉ được truy cập cục bộ trên máy của người dùng. Khi agent chạy truy vấn trên warehouse, trước tiên nó sẽ xin phê duyệt xem có được đọc kết quả đó hay không. Nếu không cho phép thì dữ liệu sẽ không được gửi tới LLM và bạn vẫn có thể xem trước cục bộ. Khi dùng phiên bản enterprise, prompt và context có thể được bảo vệ riêng mà không đi qua endpoint LLM công cộng

• Có ai muốn được gợi ý link tới các công cụ dựa trên LLM cho data engineering và data science không

  • Tôi đang tổng hợp một repository danh sách các công cụ LLM như thế này, và dự định sớm hoàn thiện

• Tôi thích những tính năng hiện có; không biết sau này có dự định hỗ trợ SQLite không

  • Tất nhiên, có vẻ không quá khó để thêm vào. DuckDB cũng sẽ có trong bản phát hành tiếp theo, và chúng tôi cũng có thể thêm SQLite. Tôi tò mò liệu bạn dùng SQLite vì mục đích phát triển cục bộ phải không

• Tôi muốn biết hệ thống xử lý thế nào khi thực hiện transitive join giữa nhiều bảng trong trạng thái không có FK/PK. Ngoài ra, phân tích mức sử dụng/viết lại các truy vấn kém hiệu quả đang tồn tại cũng có vẻ sẽ là một tính năng sát thủ

  • Với join, chúng tôi cung cấp cho mô hình schema của từng bảng cùng các kiểu join đã từng được dùng trong repository/query history để giúp nó suy luận quan hệ. Phân tích mức sử dụng chắc chắn cũng nằm trong roadmap phát triển; chúng tôi đang lên kế hoạch truy cập log của data warehouse để đo lường mức sử dụng thực tế của từng bảng