Nao - Cursor สำหรับข้อมูล

 (getnao.io)
25 คะแนน โดย xguru 2025-05-12 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เป็น AI code editor บนพื้นฐาน VS Code ที่ออกแบบมาเฉพาะสำหรับงานข้อมูล โดยเชื่อมต่อกับ BigQuery/Snowflake/Postgres ได้โดยตรง และมีความสามารถในการสร้างโค้ดอัตโนมัติตามสคีมาข้อมูลพร้อมทั้งตรวจสอบคุณภาพ
  • ขณะที่เครื่องมือเดิมที่อิง LLM มักเติม SQL อัตโนมัติโดยไม่เข้าใจสคีมาข้อมูล nao ใช้แท็บ AI แบบ RAG และเครื่องมือเอเจนต์เพื่อสร้างโค้ด SQL/Python/YAML ที่แม่นยำ
  • สามารถเขียน รัน และทำ visualization ของSQL pipelineได้ในอินเทอร์เฟซเดียว
  • รองรับPython pipelineในสภาพแวดล้อมเดียวกัน และรองรับเวิร์กโฟลว์ dbt ด้วย
  • มองเห็นได้ในครั้งเดียวทั้งความแตกต่างของข้อมูลผลลัพธ์ก่อนและหลังการเปลี่ยนโค้ดและปัญหาคุณภาพข้อมูล ช่วยให้ deploy ได้รวดเร็วโดยไม่ต้องทดสอบมาก หรือหลีกเลี่ยงความผิดพลาด
  • การใช้งานหลัก
    • ใช้สร้าง data pipeline (SQL, dbt เป็นต้น)
    • ตรวจจับข้อมูลที่ขาดหาย/ซ้ำซ้อน/outlier
    • เปรียบเทียบข้อมูลระหว่างสภาพแวดล้อมพัฒนาและ production
    • รันทดสอบที่กำหนดไว้ล่วงหน้าและสรุปผล
  • ผสานการทำงานกับ dbt, เครื่องมือ BI และ data warehouse เพื่อมอบสภาพแวดล้อม IDE ที่เหมาะกับทั้ง data engineer, analyst และ data scientist
  • รองรับ BigQuery, Snowflake, Postgres และจะรองรับ Databricks, Iceberg, Redshift ในเร็ว ๆ นี้
  • มีแผนผสานการทำงานกับLooker, Power BI, Metabase, Tableauด้วย
  • ขณะนี้มีให้ใช้เฉพาะเวอร์ชัน Mac และมีแผนรองรับ Windows/Linux
  • ความแตกต่างจาก Cursor และ MCPs
    • Cursor ต้องเรียก MCP หลายครั้งเพื่อให้ได้ data context ส่วน Nao ใช้งานได้ตลอดจาก RAG เดียว
    • MCPs ทำงานได้อย่างจำกัดภายใน Cursor และความยืดหยุ่นของ UI ก็น้อยกว่า
    • Nao มาแบบแพ็กเกจพร้อมใช้ ไม่ต้องตั้งค่า ติดตั้งส่วนขยาย ยืนยันตัวตน หรือสร้าง CI/CD จุดแข็งคือช่วยยกระดับประสบการณ์พัฒนาได้แม้สำหรับผู้ที่ไม่ใช่ผู้เชี่ยวชาญ

FAQ

  • ใครควรใช้ nao?
    • ผู้เขียน SQL, dbt analytics engineer, data scientist, data engineer และสมาชิกทุกคนในทีมข้อมูล
  • ต่างจาก Cursor อย่างไร?
    • เป็นIDE ที่เหมาะกับ data contextด้วยความสามารถอย่างการสร้างโค้ดโดยรับรู้สคีมาข้อมูล, การตรวจคุณภาพข้อมูลอัตโนมัติ และการคาดการณ์ผลกระทบจากการเปลี่ยนแปลง
  • รองรับภาษาอะไรบ้าง?
    • รองรับทุกภาษา แต่ปรับให้เหมาะกับ SQL เป็นพิเศษ
  • ช่วยงานเวิร์กโฟลว์ dbt อย่างไร?
    • เข้าใจ dbt model, source, document, test และ lineage ระดับคอลัมน์ พร้อมให้ทั้ง autocomplete และ visualization
  • ความปลอดภัยของข้อมูลเป็นอย่างไร?
    • ข้อมูลจะถูกประมวลผลในเครื่องเท่านั้น และจะขออนุญาตผู้ใช้ก่อนส่งไปยัง LLM
    • โค้ดหรือสคีมาจะไม่ถูกจัดเก็บ ใช้เพียง embeddings เท่านั้น

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-05-12
ความคิดเห็นจาก Hacker News

  • มีการชี้ว่า โปรเจกต์ข้อมูลที่ขับเคลื่อนด้วย LLM หลายตัวแม้จะยืดหยุ่นและช่วยงานได้ดี แต่ทำซ้ำได้ยากและขาดความเป็นอินเทอร์แอ็กทีฟ และมองว่า Nao นำแนวคิดนี้ไปทำได้ดี, Buckaroo ที่ฉันสร้างเป็น UI ตารางข้อมูลสำหรับ Jupyter และ Pandas/Polars ที่ให้ดูข้อมูลได้ทันทีด้วยตารางล่าสุด, ฮิสโตแกรม และสถิติสรุป, เมื่อวานเพิ่งเปิดตัวฟีเจอร์ทำความสะอาดอัตโนมัติใน Buckaroo ซึ่งจะเลือกวิธีทำความสะอาดข้อมูลแบบ heuristic และให้โค้ดที่ยืนยันแล้ว, ทำงานได้ รวดเร็วมาก ภายใน 500ms, ลองใช้กลยุทธ์การทำความสะอาดได้หลายแบบแล้วเลือกสิ่งที่เหมาะที่สุดได้, ปัญหาง่าย ๆ ไม่จำเป็นต้องผ่าน LLM, เป็นโอเพนซอร์สและมี ความสามารถในการขยายต่อ สูง

    • ฉันก็กำลังพัฒนาของที่คล้ายกันมากอยู่เหมือนกัน, แม้จะยังไม่สมบูรณ์เท่า Buckaroo แต่คิดว่า แอปแบบฝังในโน้ตบุ๊ก มีประโยชน์มาก

    • ชอบ มุมมอง ที่ใช้แสดงภาพ data profiling มาก, คิดว่านี่คือแกนสำคัญของการทำความเข้าใจข้อมูล

  • คิดว่าเป็น ไอเดียที่ยอดเยี่ยม มาก, อยากรู้ว่าฝึก Tab model อย่างไร, ใช้ Fill in the middle หรืออิงจาก edit history หรือไม่, เมื่อวานมีคนแชร์บล็อกโพสต์เกี่ยวกับ Cursor tab autocomplete ที่คล้ายกันพอดี เลยอ่านอย่างสนใจ

    • เราใช้ โมเดล Fill in the middle (โมเดลที่เทรนเองจาก Mistral และ Qwen) โดยใส่ data context ของผู้ใช้เข้าไปด้วย, และใช้ SQL parser ที่พัฒนาขึ้นเองเพื่อให้ schema context ที่เหมาะสมตามตำแหน่งเคอร์เซอร์

  • หลังจากใช้งานต่อเนื่องมาหลายสัปดาห์ รู้สึกว่า เวิร์กโฟลว์ดีขึ้นอย่างมากจริง ๆ, ตอนนี้เลือกใช้มันแทน VSCode กับส่วนขยายมากกว่าครึ่งแล้ว, ฟีเจอร์แชตสำหรับ exploratory data analysis, worksheet และการ ติดตาม lineage ของคอลัมน์ เปลี่ยนเกมสำหรับการพัฒนา dbt อย่างแท้จริง, ฟีเจอร์เหล่านี้ให้ความรู้สึกว่า ถูกออกแบบมาอย่างพิถีพิถัน ให้เข้ากับวิธีทำงานจริงของฉัน, Claire และ Christophe ก็ตอบสนองต่อฟีดแบ็กได้ทันทีและเพิ่มหรือแก้ฟีเจอร์ได้รวดเร็ว, ผลิตภัณฑ์กำลัง พัฒนาไปในทิศทางที่ถูกต้องอย่างรวดเร็ว

    • ขอบคุณสำหรับคำพูดดี ๆ และขอบคุณที่ช่วย ปรับปรุง nao ด้วย

  • รู้สึกว่าน่าสนใจมาก, ดูวิดีโอ YouTube หลายรอบแล้ว และประทับใจมากกับการ ย่นวงจรฟีดแบ็ก ได้ขนาดนั้น, เจ๋งมากจริง ๆ

    • ขอบคุณ, เป้าหมายของเราก็คือการ ย่น feedback loop ตรงนี้แหละ, เพราะทีมข้อมูลมักมี feedback loop ที่ยาวกว่าวิศวกรซอฟต์แวร์ เราเลยพยายามลดสิ่งนั้นเพื่อ ทำให้งานข้อมูลใกล้กับ flow การพัฒนามากขึ้น

  • สงสัยว่านี่ทำงานได้เฉพาะตอนใช้ raw SQL หรือเปล่า, โปรเจกต์ของฉันใช้ Postgres + TypeScript และเขียนคิวรีด้วย query builder อย่าง Kysely เลยอยากรู้ว่าสามารถใช้ได้ตอนนี้ไหม

    • ตอนนี้ Tab ทำงานได้ดีที่สุดกับ raw SQL (ไฟล์ SQL ล้วนหรือสตริง), แต่ถ้าใช้ chat/agent แล้วบอกว่าคุณใช้ Kysely พร้อมส่ง warehouse context ไปด้วย ก็พอรับมือได้ระดับหนึ่ง, ฉันเพิ่งเคยได้ยินชื่อ Kysely แต่ดู GIF แนะนำโปรเจกต์แล้ว autocomplete ดูดีมาก, แม้จะต่างจากแนวทางแบบ tab แต่ก็น่าสนใจ

  • อยากรู้ว่าข้อมูล/พรอมป์ต์ของฉันถูกส่งไปยังโมเดลมากแค่ไหน, schema ของฉันคงไม่เป็นไร แต่ข้อมูลใน warehouse มักเป็น ข้อมูลอ่อนไหว, เข้าใจว่าน่าจะมีแพ็กเกจ enterprise เลยอยากทราบล่วงหน้าว่ามีการส่งข้อมูล/ผลลัพธ์ที่นอกเหนือจากโค้ดไปยังเซิร์ฟเวอร์หรือไม่ หรือส่งเฉพาะโค้ด

    • ตัวข้อมูลจะไม่ถูก ส่งไปยังโมเดล เว้นแต่ผู้ใช้จะอนุญาตอย่างชัดเจน, บนเซิร์ฟเวอร์จะเก็บเพียง embedding ของ codebase และ data schema, เนื้อหาข้อมูลจะเข้าถึงได้ เฉพาะในเครื่องของผู้ใช้แบบ local เท่านั้น, เมื่อ agent รันคิวรีใน warehouse จะขอ การอนุมัติ ก่อนว่าอ่านผลลัพธ์ได้หรือไม่, ถ้าไม่อนุญาตก็จะไม่ส่งไปยัง LLM และสามารถ พรีวิวแบบ local ได้, หากใช้เวอร์ชัน enterprise พรอมป์ต์และคอนเท็กซ์จะได้รับการปกป้องแยกต่างหากโดยไม่ผ่าน public LLM endpoint

  • มีใครอยากได้ลิงก์แนะนำ เครื่องมือที่ขับเคลื่อนด้วย LLM สำหรับ data engineering และ data science ไหม

    • ฉันกำลังรวบรวม repository รายการ ของเครื่องมือ LLM แนวนี้อยู่, วางแผนว่าจะทำให้เสร็จเร็ว ๆ นี้

  • ชอบฟีเจอร์ที่มีอยู่ มาก, อยากรู้ว่าในอนาคตมีแผนรองรับ SQLite ด้วยไหม

    • แน่นอน, ดูแล้วน่าจะเพิ่มได้ไม่ยากนัก, ในรีลีสถัดไปจะมี DuckDB เข้ามาด้วย และ SQLite ก็น่าจะเพิ่มได้, อยากรู้ว่าที่ใช้ SQLite เป็นเพราะ การพัฒนาแบบ local หรือเปล่า

  • สงสัยว่าจัดการอย่างไรเวลาต้องทำ transitive join ข้ามหลาย ตาราง ทั้งที่ไม่มี FK/PK, นอกจากนั้นคิดว่าฟีเจอร์วิเคราะห์การใช้งานหรือรีไรต์ คิวรีที่ไม่มีประสิทธิภาพ ที่มีอยู่แล้วก็น่าจะเป็น killer feature ได้เหมือนกัน

    • สำหรับการ join เราจะให้โมเดลเห็นทั้ง schema ของแต่ละตาราง รวมถึงรูปแบบการ join ที่เคยใช้ไปแล้วใน repository/ประวัติคิวรี เพื่อช่วย อนุมานความสัมพันธ์ ระหว่างกัน, ส่วนการวิเคราะห์การใช้งานก็อยู่ในโรดแมปการพัฒนาแน่นอน, เราวางแผนเข้าถึง log ของ data warehouse เพื่อ วัดการใช้งานจริง ของแต่ละตาราง