Semble - การค้นหาโค้ดสำหรับเอเจนต์ที่ใช้โทเคนน้อยกว่า grep ถึง 98%

 (github.com/MinishLab)
2 คะแนน โดย GN⁺ 2 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Semble เป็นไลบรารีค้นหาโค้ดที่สร้างมาเพื่อให้เอเจนต์ค้นหาเฉพาะชิ้นส่วนโค้ดที่ต้องการได้ทันทีด้วยคำค้นแบบภาษาธรรมชาติและโค้ด
  • เมื่อเทียบกับ grep+read จะใช้โทเคน น้อยลงประมาณ 98% และส่งคืนเฉพาะชังก์ที่เกี่ยวข้องแทนการอ่านทั้งไฟล์
  • ทำดัชนีรีโพซิทอรีขนาดเฉลี่ยได้ใน ประมาณ 250ms และตอบคำค้นได้ในราว 1.5ms โดยทำงานบน CPU ได้โดยไม่ต้องใช้ API key, GPU หรือบริการภายนอก
  • เบนช์มาร์กดำเนินการด้วยคำค้นราว 1,250 รายการบน 63 รีโพซิทอรีใน 19 ภาษา และระบุว่า Semble ทำคุณภาพได้ 99% ของ CodeRankEmbed Hybrid ขณะที่การทำดัชนีเร็วกว่า 218 เท่า
  • ในเบนช์มาร์กด้านประสิทธิภาพโทเคน Semble ใช้โทเคนน้อยลงเฉลี่ย 98% และไปถึง recall 94% ได้ด้วยเพียง 2k โทเคน ส่วน grep+read ไปถึง recall 85% ด้วย context window ขนาด 100k
  • ใช้งานผ่าน MCP server ได้กับ Claude Code, Cursor, Codex, OpenCode และเอเจนต์ที่รองรับ MCP โดยรีโพซิทอรีจะถูก clone และทำดัชนีเมื่อจำเป็น และแคชดัชนีไว้ตลอดเซสชัน
  • รองรับการใช้งานแบบ Bash ด้วย จึงสามารถใส่เวิร์กโฟลว์ semble search และ semble find-related ลงใน AGENTS.md หรือ CLAUDE.md ได้ และวิธีนี้จำเป็นสำหรับซับเอเจนต์ของ Claude Code และ Codex CLI
  • CLI รองรับทั้งพาธในเครื่องและ Git URL แบบ https:// และหากละ path ไว้ จะใช้ไดเรกทอรีปัจจุบันเป็นค่าเริ่มต้น
  • ใช้เป็นไลบรารี Python ได้เช่นกัน โดยสามารถผนวกการค้นหาเข้ากับเครื่องมือแบบกำหนดเองผ่าน SembleIndex.from_path, SembleIndex.from_git, search, find_related
  • ภายในใช้ tree-sitter แบ่งไฟล์ออกเป็นชังก์ที่เข้าใจโค้ด จากนั้นผสาน embedding potion-code-16M ของ Model2Vec กับ BM25 แล้วรวมคะแนนด้วย Reciprocal Rank Fusion
  • การจัดอันดับใช้การถ่วงน้ำหนักเชิงคำศัพท์สำหรับคำค้นแบบสัญลักษณ์, การบูสต์ชังก์ที่เป็นนิยาม, การจับคู่รากคำของ identifier, ความเกี่ยวข้องภายในไฟล์เดียวกัน และการลดน้ำหนักให้กับ test, legacy, example และ .d.ts
  • เนื่องจากใช้โมเดล embedding แบบสถิต จึงไม่มี transformer forward pass ตอน query ทำให้ค้นหาได้ในระดับมิลลิวินาทีบน CPU
  • semble savings จะประเมินโทเคนที่ประหยัดได้โดยเปรียบเทียบจำนวนอักขระทั้งไฟล์ของไฟล์เฉพาะที่ชังก์ที่ส่งคืนสังกัดอยู่ กับจำนวนอักขระของ snippet ที่ส่งคืนในแต่ละครั้งที่ค้นหา และสถิติจะถูกเก็บไว้ใน ~/.semble/savings.jsonl
  • ติดตั้งแพ็กเกจได้จาก PyPI ชื่อ semble และเมื่อใช้งาน MCP ให้ใช้รูปแบบ uvx --from "semble[mcp]" semble
  • ไลเซนส์เป็น MIT

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

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

 
GN⁺ 2 시간 전
ความเห็นจาก Hacker News

  • พอได้ลองใช้เครื่องมือแบบนี้แล้ว ผมเห็นว่าเมื่อโค้ดเดอร์พึ่งพาเครื่องมือ AI มากเกินไปจนฉลาดน้อยลง ตัว AI เองก็ฉลาดน้อยลงด้วย
    AI แบบเอเจนต์ทุกวันนี้ฉลาดพอจะหาเส้นทางที่ค่อนข้างเหมาะสมในการสำรวจหรือค้นหาโค้ดได้อยู่แล้ว แต่พอเอาเครื่องมือแบบนี้มาต่อเข้าไป มันมักมีแนวโน้มจะเดินเกมแบบหักโหมเกินไป เพราะผลการค้นหาแทบจะให้มาแค่ตัวชี้ ไม่ใช่รายละเอียดทั้งหมด
    ผมลองให้ Pi ติดตามเส้นทางการเก็บข้อมูลและค้นหาแบบครบทั้งกระบวนการในโปรเจ็กต์ที่ซับซ้อนพอสมควร ผลคือ codebase-memory-mcp ใช้โทเค็นขาเข้า/ขาออก 85k/4.4k, ค่าตั้งปกติของผมใช้ 67k/3.2k, และถ้าไม่มีเครื่องมืออะไรเลยใช้ 80k/3.2k
    คุณภาพของผลลัพธ์กับปริมาณข้อมูลเท่ากัน และเครื่องมือนี้ไม่ได้แค่ไม่ดีขึ้น แต่แย่ลงเล็กน้อยด้วย
    ค่าตั้งปกติของผมคือใส่บรรทัดเดียวใน AGENTS.md และ CLAUDE.md ว่า “ให้อ่าน PROJECT.md ก่อน”
    ใน PROJECT.md ผมใส่แค่คำอธิบายโปรเจ็กต์ 2-3 บรรทัด, รายชื่อไฟล์ที่เกี่ยวข้องพร้อมคำอธิบายหนึ่งบรรทัด, ข้อควรระวัง, และข้อความสำหรับ LLM ว่า “ถ้าการเปลี่ยนแปลงนั้นคุ้มค่า ให้แก้ไฟล์นี้ด้วย จุดประสงค์ของไฟล์นี้คือทำให้เห็นภาพรวมคร่าวๆ ของโปรเจ็กต์ และถ้าจำเป็นค่อยไปสำรวจต่อจากตรงนั้น”

    • คำพูดที่ว่า “AI แบบเอเจนต์ฉลาดพอจะหาเส้นทางที่ปรับเหมาะอย่างมากสำหรับการสำรวจหรือค้นหาโค้ดได้แล้ว” ไม่ตรงกับประสบการณ์ของผม
      ที่ทำงานผมเคยใช้ Augment Code มาก่อน ซึ่งมี Context Engine คล้าย MCP ที่ตอบคำถามภาษาธรรมชาติกับโค้ดที่ทำดัชนีไว้ล่วงหน้า
      หลังจากนั้นย้ายมาใช้ Claude Code แต่แปลกตรงที่ทั้งที่มีเครื่องมืออ่านเป็นช่วงอยู่แล้ว มันกลับพยายามใช้ sed อ่านไฟล์จากช่วงบรรทัดที่มันจำได้เอง
      ผมไม่แน่ใจว่านั่นจะเรียกว่าเป็นเส้นทางที่ปรับเหมาะอย่างมากจริงหรือเปล่า
    • codebase-memory-mcp กับ semble ไม่ได้เหมือนกันเป๊ะ แต่เป็นการเปรียบเทียบที่น่าสนใจ เลยจะเพิ่มไว้ในรายการงานที่ต้องตรวจสอบ และถ้าได้จะลองเพิ่มลงในเบนช์มาร์กด้วย
      ถ้ามีโอกาสลองเทียบแบบเดียวกันกับ semble ได้ น่าจะเป็นฟีดแบ็กที่มีประโยชน์มาก เพราะสถานการณ์ “ของจริง” แบบนี้เอาไปทำเบนช์มาร์กหรือทำซ้ำค่อนข้างยาก

  • น่าสนใจดี ผมก็ทำงานในด้านนี้อยู่เหมือนกัน แต่ใช้แนวทางต่างออกไป
    แทนที่จะสร้างดัชนี ผมทำ grep ที่ฉลาดกว่าเดิม โดยเพิ่มการจัดอันดับและการรับรู้โครงสร้างโค้ดให้ทั้งกับ codebase และข้อความทั่วไป และเพราะใช้เวลาส่วนใหญ่ไปกับการแก้ปัญหาเรื่องประสิทธิภาพ มันเลยทำงานได้เร็วมาก
    ควรเอาไปเพิ่มเป็นตัวเทียบกับ https://github.com/boyter/cs แล้วดูว่า LLM ชอบอะไรกับคำถามแบบที่ผมถาม
    มันก็มี MCP เหมือนกัน แต่ไม่ได้สร้างดัชนีสำหรับการค้นหา และเพราะใช้การดัดแปลงเชิงความหมายของโค้ดแทน BM25 ปกติ เลยอยากรู้ว่าการจัดอันดับจะออกมาอย่างไร
    เครื่องมือนี้ดูจะเหมาะกับคำถามอย่าง “การยืนยันตัวตนทำงานอย่างไร” มากกว่า ส่วน cs จะทำ authenticate --only-declarations แล้วให้น้ำหนักผลลัพธ์ตามเนื้อหาไฟล์ คือพิจารณาว่าจุดที่แมตช์เป็นโค้ดหรือคอมเมนต์ และตามความซับซ้อนโดยรวมของไฟล์
    กดดาวไว้แล้ว เดี๋ยวจะติดตามต่อ

  • ผมรู้ว่าเครื่องมือนี้ทำมาเพื่อ AI แต่กลับสนใจจะเอามาใช้เองมากกว่า เวลาต้องสำรวจ codebase ใหม่หรือของตัวเอง
    มันดูมีประโยชน์เวลาจะรีแฟกเตอร์อะไรสักอย่างแล้วอยากเห็น ภาพรวมทั้งหมด ว่าต้องไปแก้ตรงไหนบ้าง
    LSP ก็ช่วยทำเรื่องแบบนี้ได้ แต่เครื่องมือนี้ดูเหมือนจะไปได้ไกลกว่าอีกขั้น

  • ผมลองประเมินอยู่บ้างกับ Pi และ GPT 5.5
    ทดสอบทั้ง RTK เปิด / headroom เปิด / เปิดทั้งคู่ / ปิดทั้งคู่ โดยทุกกรณีใช้ system instruction มาตรฐานของ Pi และไม่มี AGENTS.md
    จำไม่ได้แล้วว่าทดสอบอะไรเป๊ะๆ แต่เป็นชุดประเมินเอเจนต์มาตรฐานที่คนใช้กัน มีทั้ง Python ซึ่งเป็นภาษาที่ผมใช้ และ TypeScript อีกหนึ่งชุด
    ผมไม่ได้อ้างว่านี่เป็นการทดสอบที่เข้มงวดหรือดีมากนะ ถ้าใช้เวลาสักวันปรับ AGENTS.md กับ system prompt และ tool instruction ของ Pi ก็น่าจะได้ผลลัพธ์ที่ดีกว่านี้ สิ่งหนึ่งที่ผมเรียนรู้จากการรันประเมินคือรายละเอียดเล็กๆ แบบนี้เปลี่ยนผลลัพธ์ได้มาก
    แต่กรณีที่ ปิดทั้งคู่ กลับดีกว่าอย่างชัดเจน จนผมหยุดทดสอบหลังจบ 3 รอบได้เลย
    ปัญหาคือแม้บางครั้งการใช้คอนเท็กซ์จะลดลง แต่จำนวนเทิร์นจนจบงานเพิ่มขึ้น ทำให้ต้นทุนรวมของบทสนทนาสูงกว่าเดิม
    มันทำให้ผมตระหนักมากขึ้นว่าคนแชร์เครื่องมือแบบนี้กันเยอะมาก แต่กลับไม่มีการประเมินเลย หรือไม่ก็ยากจนน่าสงสัยว่าจะทำซ้ำได้ หรืออย่างในกรณีนี้คือทำเบนช์มาร์กเยอะมากแต่กลับ วัดผิดอย่าง
    เครื่องมือนี้อาจใช้โทเค็นน้อยกว่า grep จริง และเบนช์มาร์กก็พิสูจน์เรื่องนั้น แต่ประเด็นสำคัญไม่ใช่ตรงนั้น ประเด็นคือเอเจนต์ใช้เครื่องมือนี้แล้วทำงานคุณภาพเท่าเดิมได้เร็วขึ้นและถูกลงหรือไม่

    • ตอนนี้ทั้งวงการ AI มีปัญหาเรื่อง การทดสอบไม่พอ
      ไม่ใช่แค่ปัญหาของเครื่องมือนี้ แต่เป็นปัญหาของทุกอย่างที่เอา AI ไปต่อกับ codebase หรือ workflow การพัฒนา
      ก่อนมี AI เองก็ไม่มีเทสต์สำหรับวัดว่า “สิ่งนี้ทำให้พัฒนาได้เร็วและดีขึ้นแค่ไหน” อยู่แล้ว และตอนนี้ก็ยังไม่ได้เพิ่มเข้าไป
    • ในโลก AI ผมคิดว่าจะเจอสถานการณ์แบบ “ทำได้ ก็เลยทำ โดยไม่คิดว่าควรทำไหม” บ่อยมาก

  • ผมอยากเห็น agent benchmark ของจริง เช่น เอา grep ออกจาก Claude Code หรือ Copilot CLI แล้วใส่เครื่องมือนี้แทน
    ผมดู RTK กับ LSP หลายตัวมาแล้ว และโมเดลมันถูก reinforcement กับ grep แรงเกินไป จนไม่ไว้ใจผลลัพธ์ในรูปแบบอื่น แล้วชอบลองใหม่หรืออ่านซ้ำ
    เพราะโมเดลไม่เชื่อผลจากเครื่องมืออื่น การประหยัดโทเค็นเลยหายไปหมด

    • ผมเขียนไว้ใน CLAUDE.md แบบ global (~/.Claude) ให้ใช้ LSP แทน grep แล้วหลังจากนั้นปัญหานี้ก็หายไป
    • Codex CLI รัน RTK ได้ค่อนข้างดี อย่างน้อยก็กับ GPT 5.5 xhigh
      แต่สิ่งที่น่ารำคาญคือเวลามันไม่รองรับ CLI flag บางอย่างของ find มันจะขึ้นข้อความผิดพลาดแทนที่จะส่งผลลัพธ์เต็มของคำสั่งกลับมา
      พอเป็นแบบนั้นเอเจนต์ก็เสียโทเค็นไปกับการลองใหม่ หรือแย่กว่านั้นคือโดนพรอมป์ต์ขู่จนกลัวว่าไม่ควรรันคำสั่งถ้าไม่มี RTK แล้วก็ไม่ลองเลย
    • เราก็สนใจเบนช์มาร์กแบบนี้เหมือนกัน และมันอยู่ในโรดแมปพร้อมกับการ ปรับพรอมป์ต์และคำอธิบายให้เหมาะที่สุด เพื่อให้โมเดลใช้งานได้ง่ายขึ้น
      แม้จะเป็นเพียงหลักฐานเชิงประสบการณ์ แต่เราก็ใช้เครื่องมือนี้เองด้วย และจนถึงตอนนี้มันทำงานได้ค่อนข้างดี
      โมเดลของ Anthropic ดูเหมือนจะเรียกใช้เครื่องมือนี้และเชื่อผลลัพธ์ที่ได้
    • การประหยัดโทเค็นยิ่งสำคัญขึ้นเรื่อยๆ แต่สิ่งสำคัญอีกอย่างคือเอเจนต์เชื่อผลลัพธ์และหยุดค้นหาหรือไม่
      อย่าวัดแค่เอาต์พุตจากการค้นหา ต้องวัด ลูปของเอเจนต์ทั้งระบบ
    • อย่างน้อย Codex ก็เชื่อฟังถ้าบอกว่า grep มักช้าเกินไป ให้ใช้ rg แทน แต่พอเพิ่ม RTK เข้าไป มันกลับใช้ grep ผ่าน RTK ซึ่งน่าหงุดหงิดอยู่บ้าง

  • ไอเดียดูดี เลยลองเล่นนิดหน่อย
    ผมทดสอบบนรีโพ browsercode(https://github.com/browser-use/browsercode) และใช้พรอมป์ต์ว่า “ให้ใช้เฉพาะ semble CLI แล้วตอบว่า Browsercode มีเครื่องมืออะไรให้เอเจนต์นอกเหนือจากเครื่องมือ OpenCode พื้นฐาน อธิบาย schema ของ input/output ของเครื่องมือให้ถูกต้อง และสรุปสั้นๆ ว่ามันทำอะไรและทำงานอย่างไร”
    ผมแปะชิ้นส่วน AGENTS.md จาก https://github.com/MinishLab/semble#bash-integration ลงไปด้วย
    สำหรับการทดสอบที่ไม่ใช้ Semble ผมเปลี่ยนคำถามให้ใช้แค่ rg กับ fd CLI
    ทั้งสองกรณีใช้ Pi กับ gpt-5.4 medium และตั้งค่าอื่นๆ แบบน้อยที่สุด ผมยังเช็กด้วยว่าเคสหนึ่งใช้แค่ rg กับ fd ส่วนอีกเคสใช้แค่ semble จริงๆ
    ถ้าไม่ใช้ Semble โมเดลใช้คอนเท็กซ์ 10.9% และใช้ API credit $0.144 ส่วนตอนใช้ Semble ใช้ 9.8% และ $0.172
    คำตอบที่ได้ก็แทบจะเหมือนกัน ถือว่าใกล้มาก
    ผมทดสอบอีกรอบกับรีโพ OpenCode โดยคำถามคือ “ติดตามเส้นทางตั้งแต่จุดที่ตัวแปรแวดล้อม OPENCODE_EXPERIMENTAL_EXA ถูกตั้งเป็น 1 ไปจนถึงผลที่ปรากฏใน system prompt หรือเครื่องมือที่มอบให้กับ OpenCode agent”
    ผมใส่คำสั่งและเอกสารแบบเดียวกับด้านบน
    เวอร์ชันที่ไม่ใช้ Semble ละเอียดกว่านิดหน่อย และยังพูดถึงด้วยว่าเส้นทางเรียกเครื่องมือจะไปเรียก Exa หรือไม่ ขึ้นอยู่กับว่าเปิด Exa หรือ Parallel เป็น web search provider หรือเปล่า แต่คำตอบต่อคำถามจริงนั้นทั้งสองเวอร์ชันถูกต้อง
    เวอร์ชัน Semble ใช้คอนเท็กซ์ 14.7% / ค่า API $0.282 ส่วนเวอร์ชันไม่ใช้ Semble ใช้ 19.0% / $0.352
    ในแง่ประสิทธิภาพของคอนเท็กซ์ Semble ชนะชัดเจน แต่ก็น่าสังเกตว่าเวอร์ชันไม่ใช้ Semble จบเร็วกว่าเกือบสองเท่า
    แน่นอนว่านี่เป็นแค่การลองเล่นของผมเอง ผลลัพธ์อาจต่างออกไปได้

  • คำกล่าวที่ว่า “ใช้โทเค็นน้อยกว่า grep 98%” นี่หมายถึงให้เชื่อว่า grep สิ้นเปลืองมากจนโมเดลต้องอ่านขยะไร้ประโยชน์ 98% ทุกครั้งเลยหรือ?
    ผมรู้สึกว่าคำอ้างนี้อาจไม่เป็นตัวแทนของภาพรวม หรือไม่ก็มีอย่างอื่นที่หายไประหว่างทางเวลาคัดทิ้งคอนเท็กซ์ส่วนใหญ่ก่อนจะส่งให้โมเดล

    • 98% นั้นไม่ได้เทียบกับแค่เอาต์พุตของ grep แต่เทียบกับ ลูป grep+read
      เวลาเอเจนต์เจอ codebase ที่ไม่คุ้น มันมักจะเริ่มจาก cat file หรืออ่านไฟล์ทั้งไฟล์ อย่างน้อยในประสบการณ์ของผมก็เป็นแบบนั้น
      ถ้าคุณทำให้เอเจนต์ใช้แค่ grep -C N แล้วหยุดได้อย่างสม่ำเสมอ ผมอยากรู้การตั้งค่ามาก เพราะผมคิดว่าคุณภาพของผลลัพธ์จากแบบนั้นต่ำเกินกว่าจะใช้เป็นคอนเท็กซ์ที่มีประโยชน์
    • Claude เคยมีปัญหาอ่านเอาต์พุตหลายร้อยกิโลไบต์เพราะไปแมตช์โดนของใน node_modules
      ripgrep ช่วยได้ ดังนั้นการเพิ่มบรรทัดหนึ่งในไฟล์ความจำให้มันใช้ก็ดูสมเหตุสมผล
    • grep จะแสดงทุกบรรทัดที่แมตช์
      ถ้า LLM ค้นหาอะไรสักอย่าง มันอาจมีสัญญาณรบกวนเยอะ และอาจต้องค้นหาแบบนั้นเพราะยังระบุสิ่งที่ต้องการให้เฉพาะเจาะจงไม่ได้
      การค้นหาแบบมุ่งเป้าไปที่เป้าหมาย สามารถลดจำนวนโทเค็นได้
      แต่การเปรียบเทียบนี้ดูเหมือนจะเทียบระหว่างการได้เฉพาะส่วนที่จำเป็นกับการอ่านทั้ง codebase

  • ขอให้ฟีดแบ็กหน่อยว่า codex-cli ค้างเวลามันเรียกตัวนี้ผ่าน MCP
    โปรเซส semble เองก็ค้างเป็นซอมบี้อยู่แบบนั้นไม่จบ ไม่รู้เพราะอะไร และในล็อกก็ไม่มีอะไรเลย
    ถ้าเรียกผ่านสกิลแบบ CLI, GPT 5.5 จะพยายามยิงคำค้นหาไปที่ ripgrep เยอะมาก เหมือนมันคุ้นกับ ripgrep อยู่แล้ว
    ผมไม่แน่ใจว่าวิธีนี้มีประสิทธิภาพแค่ไหน และจากเอกสารสั้นๆ บน GitHub กับคำสั่งสำหรับเอเจนต์ก็ยังไม่ชัดว่าอะไรคือแนวทางที่ดีที่สุด
    อีกอย่าง ตอนติดตั้งสำหรับ bash ผมก็เจอข้อผิดพลาดเกี่ยวกับการเชื่อมต่อภายนอก GitHub อยู่หลายครั้ง ไม่รู้ว่าเกี่ยวกับอาการค้างหรือเปล่า
    เพิ่มเติมคือเอเจนต์ของผมยังพยายามใช้ ripgrep ต่อด้วย เลยดูซ้ำซ้อน เหมือนมันมีปัญหาเรื่องความเชื่อใจ
    ถ้ามี คำอธิบายสกิลสำหรับเอเจนต์ ที่ละเอียดขึ้น ก็น่าจะช่วยชี้นำเอเจนต์ให้ใช้ได้ถูกทาง

    • ขอบคุณมากสำหรับฟีดแบ็กละเอียดๆ
      เรื่องบั๊ก ถ้าช่วยเปิด issue พร้อมรายละเอียดการตั้งค่าได้จะดีมาก เราอยากสืบและแก้เรื่องนี้แน่นอน
      ปัญหาการยิงหลายคำค้นหาก็เป็นฟีดแบ็กที่ดีมากเช่นกัน เราจะลองอัปเดตพรอมป์ต์กับคำสั่ง และเพิ่มเทสต์ที่เกี่ยวข้องเพื่อไม่ให้เกิดแบบนี้
      ส่วนข้อผิดพลาดการเชื่อมต่อภายนอกระหว่างติดตั้ง น่าจะมาจาก uv ไปดึง dependency จาก PyPI และคงไม่ใช่สาเหตุของอาการค้าง

  • ไอเดียดูดี
    ขอเสริมปัญหาที่เกี่ยวข้องอีกอย่างคือ ใน codebase เล็กๆ Claude บางครั้งสามารถใส่ทั้ง codebase เข้าไปในคอนเท็กซ์ทีเดียวแล้วจัดการได้ด้วยโทเค็นน้อยมากอยู่แล้ว แต่กลับใช้เวลาเยอะไปกับการค้นหาสิ่งต่างๆ
    วิธีเลี่ยงที่ใช้ได้ดีคือใส่ทั้งไดเรกทอรีเข้าไปในคอนเท็กซ์ตั้งแต่ start hook
    แบบนั้น Claude จะข้ามช่วง “คลำทางในความมืด” ทุกครั้งที่เริ่มงานไปได้
    ผมเคยเห็นโปรเจ็กต์ดีๆ ตัวหนึ่งที่ให้ภาพรวมแบบมีสตับสำหรับรีโพขนาดใหญ่กับโมเดลด้วย แต่จำชื่อไม่ได้แล้ว

    • อาจจะเป็น aider ไหม? https://aider.chat/2023/10/22/repomap.html
    • เห็นด้วยเลย เอเจนต์ไม่ค่อยรู้ข้อมูลอย่างจำนวนไฟล์หรือขนาดไฟล์ของสิ่งที่มันกำลังดูอยู่
      แต่ถ้าเป็น codebase เล็ก สิ่งที่อยากหาก็มักจะหาได้ง่ายด้วย ดังนั้นการค้นหาก็ยังช่วยลดต้นทุนได้อยู่

  • ปัญหาที่ใหญ่กว่าของวิธีแก้แบบนี้คือ AI ส่วนใหญ่ทุกวันนี้ใช้ grep และการค้นหาได้เก่งมากอยู่แล้วเพราะผ่านการฝึกมา
    ถ้าคุณยื่นเครื่องมือใหม่ให้ AI เครื่องมือนั้นจะไปดึงเอา ความสามารถในการรับรู้ ของ AI ออกไปบางส่วน
    มนุษย์มักจะ “เรียนรู้” วิธีใช้เครื่องมือแบบนั้นได้ แต่การเรียนรู้ของ LLM ถูกตรึงไว้แล้ว และมันมีความชำนาญลึกมากกับเครื่องมือเดิมอย่าง grep อยู่ก่อนแล้ว
    ตัวอย่างเช่น AI รู้วิธีใช้คำสั่ง Linux อย่าง tree เพื่อสำรวจ codebase อยู่แล้ว และมันก็ถูกฝึกกับสิ่งนี้มาดีพอ
    ปัญหาอีกอย่างคือ การสร้างตัวอย่างที่แสดงให้เห็นว่าเครื่องมือแบบนี้มีประโยชน์ทำได้ง่าย แต่การพิสูจน์จริงๆ ว่าการเสียความสามารถเชิงรับรู้ที่เครื่องมือเหล่านี้ก่อขึ้นจะถูกชดเชยด้วยประโยชน์ในงานระยะยาวนั้นทำได้ยาก
    สัญชาตญาณแรกของผมคือ ในงานระยะยาว สติปัญญาที่นำไปใช้งานได้จริง น่าจะลดลงสุทธิ ทำให้เอเจนต์แย่กว่าตอนใช้เครื่องมือเดิม
    การพิสูจน์ว่าเป็นตรงกันข้ามไม่ใช่เรื่องง่าย แต่ก็อาจเป็นโจทย์ที่น่าลองอยู่เหมือนกัน