ข้ามไปยังเนื้อหา

เบื้องหลัง Cursor! เจาะลึก Fast Regex Search ติดปีก AI Agent ค้นหาโค้ดพริบตา

เทคโนโลยี
3 ครั้ง
0 ความเห็น
4 นาที
เบื้องหลัง Cursor! เจาะลึก Fast Regex Search ติดปีก AI Agent ค้นหาโค้ดพริบตา
Image Credit: Cursor
By Suphansa Makpayab
TL;DR

Cursor เผยเบื้องหลังการพัฒนาระบบ Fast Regex Search สำหรับ AI Agent โดยใช้เทคนิค Sparse N-grams ร่วมกับการทำ Index บนเครื่อง Local เพื่อแก้ปัญหาการค้นหาโค้ดที่ล่าช้าในโปรเจกต์ขนาดใหญ่ ช่วยลด Latency และเพิ่มความเร็วในการทำงานของ AI อย่างก้าวกระโดด

ย้อนกลับไปในปี 1973 ตอนที่เครื่องมือพื้นฐานอย่าง grep ถือกำเนิดขึ้น คงไม่มีใครคิดว่ามันจะกลายมาเป็นอาวุธคู่กายของ AI ยุคปัจจุบัน เมื่อเทรนด์การเขียนโค้ดด้วย AI Agent มาถึง ปรากฏว่าเหล่า Agent ทั้งหลายชื่นชอบการใช้เครื่องมือจำพวก grep ในการค้นหาบริบทของโค้ดเป็นอย่างมาก แต่ปัญหาคือเมื่อต้องเจอกับโปรเจกต์ขนาดใหญ่ระดับเอนเทอร์ไพรส์ (Monorepos) เครื่องมือยอดฮิตที่ว่าเร็วอย่าง ripgrep ก็ยังต้องใช้เวลาสแกนไฟล์นานกว่า 15 วินาที ซึ่งนั่นนานพอที่จะทำให้กระบวนการคิดของ AI สะดุดและเสียจังหวะ

ล่าสุด Cursor เครื่องมือเขียนโค้ดยอดฮิต ได้ออกมาเปิดเผยเบื้องหลังการแก้ปัญหานี้ ด้วยการสร้างดัชนี (Index) สำหรับการค้นหาด้วย Regular Expressions (Regex) โดยเฉพาะ เพื่อให้ AI อย่าง Composer 2 สามารถค้นหาโค้ดได้อย่างฉับไวโดยไม่ต้องสแกนใหม่ทุกไฟล์
วิวัฒนาการของการค้นหาโค้ด: จาก Trigram สู่ Sparse N-grams

การจะทำ Index ให้ค้นหา Regex ได้นั้นไม่ใช่เรื่องง่าย หากใช้เทคนิค Trigram (หั่นข้อความทีละ 3 ตัวอักษร) แบบคลาสสิก ดัชนีก็จะบวมเต่งและกินทรัพยากรมหาศาล ครั้นจะหันไปหา Suffix Arrays แบบที่ใช้ค้นหาโค้ด Linux Kernel ก็เจอปัญหาว่าอัปเดตข้อมูลแบบเรียลไทม์ยากเกินไป หรือแม้แต่เทคนิค Probabilistic Masks ที่ใช้ Bloom filter (คล้ายระบบของ GitHub) ก็ดันมีจุดอ่อนตรงที่ถ้าข้อมูลอัปเดตบ่อยๆ ตัวกรองจะทำงานรวนจนประสิทธิภาพตก

คำตอบที่ Cursor เลือกใช้คือ Sparse N-grams ซึ่งเป็นเทคนิคระดับเทพที่เลือกหั่นคำตาม "น้ำหนัก" (Weight) ของตัวอักษรคู่กัน แทนที่จะหั่นทุกๆ 3 ตัวอักษรแบบทื่อๆ อัลกอริทึมจะให้คะแนนตัวอักษรคู่ที่ หายาก สูงกว่าคู่ที่เจอบ่อย (โดยอ้างอิงสถิติจาก Open-Source โค้ดหลายเทราไบต์) ผลลัพธ์คือระบบจะสร้าง Index เฉพาะจุดที่สำคัญ ทำให้ตอนที่ AI ค้นหา มันจะดึงเฉพาะไฟล์ที่มีโอกาสตรงเป้าจริงๆ มาตรวจสอบขั้นสุดท้าย ช่วยลดจำนวนไฟล์ที่ต้องสแกนทิ้งไปได้มหาศาล

ทำไมต้องรันบน Local Machine?

สิ่งที่น่าสนใจคือ Cursor เลือกที่จะเก็บ Index เหล่านี้ไว้บน เครื่องของผู้ใช้เอง (Local Machine) แทนที่จะโยนขึ้น Cloud เหมือนระบบ Semantic Search ทั่วไป เหตุผลก็คือ:

  • ลด Latency: โมเดล AI ต้องการความเร็วขั้นสุด การต้องส่งรีเควสต์ไปกลับเซิร์ฟเวอร์ทุกครั้งที่หาโค้ดคือตัวการที่ทำให้ AI ทำงานช้าลง

  • ความสดใหม่ของข้อมูล (Freshness): AI จำเป็นต้อง "อ่านโค้ดที่ตัวเองเพิ่งเขียนไป" ได้ทันที หากหาไม่เจอ มันจะเริ่มหลงทางและเสีย Token ไปฟรีๆ

  • ความเป็นส่วนตัว: โค้ดของบริษัทระดับเอนเทอร์ไพรส์มีความปลอดภัยสูง การสแกนทุกอย่างบนเครื่องผู้ใช้จึงตอบโจทย์ที่สุด

เพื่อไม่ให้กิน RAM ของนักพัฒนาจนเกินงาม Cursor จัดการแยกไฟล์ Index เป็นสองส่วน คือไฟล์ Lookup Table ขนาดเล็กที่เก็บเฉพาะค่า Hash นำมาทำ mmap ไว้ในหน่วยความจำเพื่อความไว และไฟล์ Postings ที่อยู่บนฮาร์ดดิสก์ โดยอิงสถานะทั้งหมดผูกไว้กับ Git Commit ทำให้โหลดและซิงก์ข้อมูลได้เร็วปรี๊ด

ในยุคที่ทุกบริษัทต่างพยายามสร้าง AI ให้ฉลาดขึ้น การมีสมองที่ดีอย่างเดียวอาจไม่พอ แต่ต้องมีระบบดึงความจำที่เร็วดั่งสายฟ้าด้วย งานนี้ Cursor พิสูจน์ให้เห็นแล้วว่า การหยิบเทคนิคอัลกอริทึมข้อความสุดคลาสสิกมาปรับแต่งให้เข้ากับยุค AI คือกุญแจสำคัญที่ทำให้ Agent ทำงานได้จริงในสเกลระดับโลก ไม่ใช่แค่เก่งแต่ในโปรเจกต์ Hello World อีกต่อไป

ความเห็น (0)

เข้าสู่ระบบเพื่อแสดงความเห็น

เข้าสู่ระบบ

ยังไม่มีความเห็น

เป็นคนแรกที่แสดงความเห็นในบทความนี้