สร้างระบบไฟล์เสมือนเพื่อแทนที่ RAG สำหรับ AI Document Assistant

 (mintlify.com)
3 คะแนน โดย GN⁺ 25 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เพื่อก้าวข้ามข้อจำกัดของ การค้นหาแบบอิง RAG เดิม จึงเปลี่ยนไปใช้ โครงสร้างระบบไฟล์เสมือน ที่จัดเอกสารเป็นไฟล์และไดเรกทอรี
  • ได้พัฒนา ChromaFs ที่สามารถรันคำสั่ง grep, cat, ls, find บนพื้นฐานของ ฐานข้อมูล Chroma ได้โดยไม่ต้องคัดลอกไฟล์จริง
  • ด้วยแนวทางนี้ เวลาในการสร้างเซสชันลดลงจาก 46 วินาทีเหลือ 100 มิลลิวินาที และต้นทุนการประมวลผลส่วนเพิ่มลดลงจนอยู่ที่ แทบ 0 ดอลลาร์
  • การควบคุมสิทธิ์เข้าถึงจัดการผ่าน การกรอง RBAC จากเมทาดาทาเส้นทางไฟล์ ทำให้ไม่ต้องมีคอนเทेनเนอร์แยกหรือการจัดการกลุ่มผู้ใช้เพิ่มเติม
  • ผลลัพธ์คือ Document Assistant ของ Mintlify สามารถให้บริการขนาดใหญ่ได้ด้วยโครงสร้างที่ ตอบสนองทันที ต้นทุนต่ำ และไร้สถานะ

แนวทางระบบไฟล์เสมือนที่ก้าวข้ามข้อจำกัดของ RAG

  • การค้นหาเอกสารแบบอิง RAG เดิมจะคืนมาเพียงบางช่วงข้อความที่ตรงกับคิวรี ทำให้ตอบคำถามที่ครอบคลุมหลายหน้า หรือค้นหาวลีอย่างแม่นยำได้ยาก
  • เพื่อแก้ปัญหานี้ จึงเปลี่ยนโครงสร้างเอกสารให้ สำรวจได้เหมือนระบบไฟล์ โดยแมปแต่ละหน้าเอกสารเป็นไฟล์ และแต่ละเซกชันเป็นไดเรกทอรี
  • เอเจนต์สามารถสำรวจเอกสารได้โดยตรงผ่านคำสั่ง grep, cat, ls, find ทำให้ค้นหาเอกสารได้ในรูปแบบเดียวกับที่นักพัฒนาจัดการโค้ดเบส

ปัญหาคอขวดของคอนเทนเนอร์

  • แนวทางทั่วไปคือสร้าง สภาพแวดล้อมแซนด์บ็อกซ์ที่แยกออกจากกัน และโคลนรีโพซิทอรี เพื่อให้เอเจนต์มีระบบไฟล์จริงใช้งาน
  • แต่ในผู้ช่วยฝั่งฟรอนต์เอนด์ ความหน่วงในการสร้างเซสชันรุนแรงมาก โดย เวลาในการสร้างเซสชัน p90 อยู่ที่ราว 46 วินาที
  • เมื่อคิดจากการสนทนา 850,000 ครั้งต่อเดือน แม้ใช้สเปกขั้นต่ำ (1 vCPU, RAM 2GiB, คงเซสชันไว้ 5 นาที) ก็ยังมี ต้นทุนโครงสร้างพื้นฐานมากกว่า 70,000 ดอลลาร์ต่อปี
  • เพื่อลบคอขวดนี้ จึงต้องการ ระบบไฟล์เสมือนที่ตอบสนองได้ทันทีและทำงานด้วยต้นทุนต่ำ

การสร้างเชลล์เสมือน — ChromaFs

  • แทนที่จะใช้ระบบไฟล์จริง จะให้เพียง ภาพลวงตาของระบบไฟล์เสมือน
  • เนื่องจากข้อมูลเอกสารเดิมถูกทำดัชนีไว้ใน ฐานข้อมูล Chroma อยู่แล้ว จึงสร้าง ChromaFs ขึ้นบนพื้นฐานนี้
  • ChromaFs จะดักคำสั่ง UNIX แล้วแปลงเป็นคิวรีของ Chroma
  • ผลลัพธ์คือ เวลาในการสร้างเซสชันลดจาก 46 วินาทีเหลือ 100 มิลลิวินาที และต้นทุนการประมวลผลส่วนเพิ่มลดลงจนอยู่ที่ แทบ 0 ดอลลาร์
Metric Sandbox ChromaFs
P90 Boot Time ~46 วินาที ~100ms
Marginal Compute Cost ~$0.0137/การสนทนา ~$0
Search Mechanism สแกนดิสก์ คิวรีเมทาดาทาของ DB
Infrastructure แซนด์บ็อกซ์ภายนอก เช่น Daytona นำ DB เดิมกลับมาใช้
  • พัฒนาบนพื้นฐาน just-bash (Vercel Labs) และรองรับคำสั่ง grep, cat, ls, find, cd
  • ใช้อินเทอร์เฟซ IFileSystem ของ just-bash เพื่อคงตรรกะการทำ pipe และการจัดการ flag ไว้เหมือนเดิม พร้อมทั้ง แปลงการเรียกเข้าถึงไฟล์ให้เป็นคิวรีของ Chroma

การบูตสแตรปต้นไม้ไดเรกทอรี

  • ChromaFs ต้องรู้ล่วงหน้าว่ามีไฟล์ใดอยู่บ้างก่อนเริ่มทำงาน จึงเก็บต้นไม้ไฟล์ทั้งหมดไว้ในคอลเลกชันของ Chroma ในรูป JSON แบบบีบอัด (__path_tree__)
  • เมื่อเซิร์ฟเวอร์เริ่มต้น จะดึงข้อมูลนี้มาและกู้คืนเป็นโครงสร้างในหน่วยความจำ 2 แบบ
    • Set<string> ของเส้นทางไฟล์
    • Map<string, string[]> ของรายการลูกในแต่ละไดเรกทอรี
  • หลังจากนั้น คำสั่ง ls, cd, find จะถูกประมวลผล ทันทีจากหน่วยความจำภายในโดยไม่ต้องเรียกเครือข่าย และเซสชันถัดไปของไซต์เดียวกันก็สามารถนำต้นไม้ที่แคชไว้กลับมาใช้ได้

การควบคุมสิทธิ์เข้าถึง

  • ต้นไม้เส้นทางมีฟิลด์ isPublic และ groups รวมอยู่ด้วย และจะคงไว้เฉพาะไฟล์ที่ผู้ใช้เข้าถึงได้ตามโทเค็นเซสชันของผู้ใช้
  • ไฟล์ที่ไม่มีสิทธิ์เข้าถึงจะถูกลบออกจากต้นไม้โดยสมบูรณ์ ทำให้เอเจนต์ไม่สามารถรับรู้ถึงเส้นทางนั้นได้
  • ในแซนด์บ็อกซ์แบบเดิม ต้องจัดการกลุ่มผู้ใช้ลินุกซ์, chmod, การแยกคอนเทนเนอร์ ฯลฯ แต่ใน ChromaFs สามารถทำ RBAC ได้ด้วยตรรกะการกรองแบบง่ายเท่านั้น
Path Access Visible
/auth/oauth.mdx public ✓
/auth/api-keys.mdx public ✓
/internal/billing.mdx admin, billing ✗
/api-reference/users.mdx public ✓
/api-reference/payments.mdx billing ✗

การประกอบชิ้นส่วนเอกสารกลับเข้าด้วยกัน

  • เอกสารที่เก็บใน Chroma ถูก แบ่งเป็นหลายชิ้นเพื่อใช้สร้าง embedding
  • เมื่อรัน cat /auth/oauth.mdx ระบบจะดึงทุกชิ้นที่มี slug page เดียวกัน จากนั้นเรียงตาม chunk_index แล้วรวมเข้าด้วยกัน
  • ผลลัพธ์จะถูกแคชไว้ จึงไม่เกิดการดึง DB ซ้ำ แม้ในเวิร์กโฟลว์ grep แบบเรียกซ้ำ
  • ไฟล์ขนาดใหญ่ เช่น OpenAPI spec จะถูกลงทะเบียนเป็น lazy file pointer และจะดึงจาก S3 เฉพาะเมื่อมีการเข้าถึง
  • การเขียนทั้งหมดจะคืนข้อผิดพลาด EROFS (ระบบไฟล์แบบอ่านอย่างเดียว) เพื่อคงโครงสร้างที่ปลอดภัยและ ไร้สถานะ

การปรับแต่ง Grep

  • คำสั่ง grep -r จะช้ามากหากทำเป็นการสแกนผ่านเครือข่ายแบบตรงไปตรงมา จึงมีการปรับแต่งด้วย โครงสร้างการกรองสองขั้นตอน
    • ขั้นที่ 1: ใช้คิวรีของ Chroma ($contains, $regex) เพื่อ คัดเลือกไฟล์ผู้สมัคร
    • ขั้นที่ 2: ดึงล่วงหน้าเข้า Redis cache แล้วให้ just-bash ทำ การกรองละเอียดในหน่วยความจำ
  • ทำให้การค้นหาแบบ recursive ขนาดใหญ่สามารถเสร็จได้ในระดับ มิลลิวินาที

บทสรุป

  • ChromaFs ขับเคลื่อน Document Assistant ของ Mintlify ที่มีการใช้งานมากกว่า 30,000 ครั้งต่อวัน จากผู้ใช้หลายแสนคน
  • ด้วยการแทนที่แซนด์บ็อกซ์ จึงทำให้เกิด การสร้างเซสชันทันที, ต้นทุนส่วนเพิ่มใกล้ศูนย์, RBAC ในตัว, และ โครงสร้างไร้สถานะ
  • สามารถใช้งานได้โดยตรงบนเว็บไซต์เอกสารทั้งหมดของ Mintlify (mintlify.com/docs)

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

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

 
GN⁺ 25 일 전
ความคิดเห็นจาก Hacker News

  • เหตุผลที่การค้นหาแบบอิงระบบไฟล์กลับมาได้รับความสนใจอีกครั้ง ก็เพราะเรากำลังค้นพบรูปแบบของ semantic search ที่ไม่อิง embedding ใหม่อีกครั้ง
    เหมือนบรรณารักษ์ที่จัดหนังสือลงชั้นตามหัวข้อ การจัดไฟล์ตามโดเมนก็ตีความได้ง่ายกว่า
    นี่เป็นวิธีค้นหาที่มีมานานแล้ว แต่เพิ่งกลับมาตระหนักถึงคุณค่าของมันอีกครั้งในตอนนี้
    บล็อกโพสต์ที่เกี่ยวข้อง

    • บรรณารักษศาสตร์ แบบดั้งเดิมได้จับรูปแบบเชิงลึกของโครงสร้างข้อมูลไว้แล้ว
      แนวคิดนี้ยังถูกถ่ายทอดไว้อย่างดีใน Ralph Wrecks The Internet ของ Pixar
      ทวีตอ้างอิง 1, ทวีตอ้างอิง 2
    • ฉันกำลังทำงานกับโค้ดเบสที่มีไฟล์ Python มากกว่า 400 ไฟล์ และ RAG แบบอิง embedding มักดึง ชิ้นส่วนโค้ดที่ไม่เกี่ยวข้อง แต่มีคำคล้ายกันมาให้บ่อยมาก
      แต่พอให้เอเจนต์สำรวจ directory tree โดยตรง มันก็เริ่มเข้าใจโครงสร้างโมดูลภายใน 30 วินาที และเริ่มขอไฟล์ที่ถูกต้อง
      ฉันลืมไปว่าลำดับชั้นของไดเรกทอรีนั้นเป็น knowledge graph ที่มนุษย์สร้างขึ้นอยู่แล้ว
    • พอสร้างระบบค้นหาสำหรับ LLM ไปเรื่อย ๆ สุดท้ายก็ลงเอยด้วยการประดิษฐ์ reverse index (concordance) ขึ้นมาใหม่
      ซึ่งจริง ๆ แล้วก็คือแนวคิดเดียวกับ inverted index ของ Google ไม่ได้ใหม่เสียทีเดียว
    • ดูเหมือนว่าจะมีคนตั้งต้นว่า RAG ต้องใช้ vector search เท่านั้น แล้วทุกคนก็ไหลตามกันไป
    • ผู้ช่วย AI สุดท้ายแล้วก็เป็น ตัวละครเสมือน ที่ LLM เติมคำต่อให้อัตโนมัติ ดังนั้นกลไกที่ตีความได้เหมือนปฏิสัมพันธ์ทางภาษาของมนุษย์จึงได้เปรียบกว่า

  • สำหรับฉัน RAG ไม่ได้เปิดทางให้ฉันอ่านเนื้อหาโดยตรง
    ตอนนี้เลยหันมารวมความรู้เป็น static page แบบ Markdown แล้ว build เป็นไฟล์ JSON หลังแก้ไข เพื่อให้เอเจนต์ query จากแหล่งข้อมูลนี้
    ลิงก์อธิบาย

  • ข้ออ้างว่าการค้นหาแบบระบบไฟล์ดีกว่า RAG ฟังดูชวนสับสน
    การค้นหาด้วยคีย์เวิร์ดแบบ grep เป็นวิธีเก่า ส่วน RAG ใช้ vector search
    แต่ในฐานข้อมูล เราสามารถทำดัชนีเนื้อหาเป็น ลำดับชั้น แท็ก หรือโครงสร้างตามต้องการ ได้
    การค้นหาก็ผสมได้หลายแบบ ทั้งคีย์เวิร์ด เวกเตอร์ tf-idf BM25 ฯลฯ
    การกลับไปใช้ระบบไฟล์ให้ความรู้สึกเหมือนถอยกลับไปสู่เทคโนโลยีระดับยุค 60

    • ก็จริง แต่ในทางปฏิบัติ เอเจนต์ทำงานได้ดีกว่าเมื่อทำงานกับไฟล์โดยตรง
      coding agent แบบ CLI จะทำตัวฉลาดขึ้นมากเมื่อเข้าถึงไฟล์ได้
    • ฉันได้ผลลัพธ์ที่ดีจาก agentic search ที่อิงฐานข้อมูล
      ประเด็นสำคัญคือเอเจนต์สามารถรัน ad-hoc query ได้ด้วยตัวเอง
      ถ้าใช้ DB ที่รองรับทั้ง embedding และ full-text search และเปิดให้เอเจนต์ query ได้อย่างอิสระ ก็ถือว่า agentic มากพอแล้ว
    • จริง ๆ แล้วระบบไฟล์ส่วนใหญ่ภายในก็ใช้ โครงสร้างฐานข้อมูล อยู่แล้ว
      การใช้ระบบไฟล์แบบฐานข้อมูลจึงไม่ใช่เรื่องใหม่
    • วิธีที่บทความพูดถึงสุดท้ายก็ดูเหมือนจะเป็นสิ่งนี้อยู่ดี
    • ฉันคิดว่าการให้เอเจนต์สำรวจหลาย data source ได้โดยตรงน่าจะดีกว่า

  • การคำนวณว่ามีค่าใช้จ่ายเกิน 70,000 ดอลลาร์ต่อปีจากบทสนทนา 850,000 ครั้งต่อเดือนฟังดูแปลก ๆ
    ฉันสงสัยว่า CPU กับหน่วยความจำถูกใช้ไปกับอะไรเยอะขนาดนั้น จนมารู้ว่าเป็นเพราะ ChromaFs แบบ just-bash ของ Vercel Labs

    • ถ้าให้ container แบบแยกขาด กับแต่ละเอเจนต์ ต่อให้ไม่ทำอะไรเลย หน่วยความจำก็ยังถูกจองค้างไว้ ทำให้ต้นทุนสูงขึ้น

  • ฉันกำลังเพลิดเพลินกับ ยุคฟื้นฟูของแอปพลิเคชัน CLI
    ฉันสร้าง virtual file system ด้วย FUSE ที่ mirror ระบบไฟล์จริงของ Mac เพื่อจำกัดเอเจนต์ให้อยู่ได้แค่ใน tree นั้น
    แต่ละ repo จะมีเอเจนต์แบบรันระยะยาวของตัวเอง และควบคุมสิทธิ์ผ่าน virtual file system
    โปรเจกต์ bashguard

  • เราใช้ทั้ง virtual file system (VFS) และ RAG
    หัวใจของ RAG คือคุณภาพของข้อมูล เราแบ่งเอกสารตามหน่วยความหมายและสร้าง metadata กับลิงก์
    จากนั้นใช้ voyage contextual embedding เพื่อฝังแต่ละ chunk พร้อมข้อมูลของเอกสาร
    ตอนค้นหา เอเจนต์สามารถตามลิงก์ต่อหรือวิเคราะห์ต้นฉบับได้
    คุณภาพของ reranking ส่งผลต่อประสิทธิภาพอย่างมาก

    • VFS ของเรา สร้างบน Postgres และฉายออกมาในรูปแบบไฟล์/ไดเรกทอรี
      รองรับ grep, bm25, jq, เครื่องมือพรีวิว ฯลฯ และทำงานบน Pydantic AI

  • การทำ emulation ของ POSIX shell ด้วย TypeScript เพื่อค้นหาแบบลำดับชั้นดูเป็น การออกแบบเกินความจำเป็น
    ทุกครั้งที่รัน ls หรือ grep ก็เพิ่มรอบการอนุมาน ทำให้ latency สูงขึ้น

    • ถ้าเป็น วิธีเอา FUSE ไปวางทับบน chunk ก็น่าจะไม่ต้องมี shell emulation

  • ฉันอาจไม่รู้เรื่อง tech stack มากนัก แต่ก็สงสัยว่าทำไมถึงต้องสร้าง shell ปลอม ขึ้นมา
    โซลูชันแบบ FUSE ดูเป็นธรรมชาติกว่า

    • จริง ๆ เคยพิจารณา FUSE adapter แต่ ช้าเกินไป
      เราไม่ได้ต้องการความเข้ากันได้กับ POSIX แบบสมบูรณ์ และต้องการแค่การสำรวจเอกสารแบบอ่านอย่างเดียว
      ดังนั้นการรองรับเพียงบางคำสั่งของ bash จึงง่ายกว่า

  • ในบริบทของการทำให้เอกสารเข้าถึงได้ผ่านเครื่องมือระบบไฟล์ AI SDK ของ Vercel ก็น่าสนใจ
    มันใส่เอกสาร .mdx ไว้ใน root ของแพ็กเกจ npm เพื่อชี้นำให้เอเจนต์ grep จากเอกสารในเครื่อง ก่อน
    ตัวอย่าง SKILL.md

  • นี่เป็นแนวทางที่ดีสำหรับสตาร์ทอัพอย่าง Mintlify แต่ใน องค์กรที่ซับซ้อน อาจใช้งานจริงได้ยากกว่า
    ในสภาพแวดล้อมที่โครงสร้างไม่เป็นลำดับชั้นหรือเอกสารถูกปะปนกัน RAG จะมีประโยชน์กว่า

    • ที่นี่กรณีใช้งานคือการค้นหาโค้ดซึ่งเป็น use case ที่ชัดเจน จึงเรียบง่าย
      RAG ไม่ใช่คำตอบสารพัดอย่าง และทีม Claude Code ก็ได้ข้อสรุปเดียวกัน
    • เพราะ เทคโนโลยี OCR พัฒนาไปมากแล้ว ถ้าเอกสารสามารถทำ OCR ได้ แนวทางนี้ก็น่าจะทำให้ใช้ได้ทั่วไปขึ้น
    • ถ้าเอา VFS ไปครอบบนการจัดระเบียบเอกสารที่ซับซ้อน สุดท้ายมันก็เป็นเพียง รูปแบบหนึ่งของตัวทำดัชนี และถ้าไม่มีการควบคุมสิทธิ์ก็จะเกิดปัญหาด้านความปลอดภัย