Cerebras สร้างคลังความรู้ภายในองค์กรอย่างไร

• สร้างและเปิดตัว Cerebras Knowledge ที่ดึงข้อมูลจาก Slack/ที่เก็บโค้ด/เอกสาร/ฐานข้อมูลภายในโดยตรงจากแหล่งเดิม และภายใน 3 เดือนหลังเปิดตัวก็รองรับคำถามจากพนักงาน/ระบบอัตโนมัติ/เอเจนต์ได้มากกว่า 15,000 ครั้งต่อวัน
• แทนที่จะย้ายข้อมูลทั้งหมดไปไว้ในเครื่องมือเดียว ระบบเชื่อมต่อเข้ากับ ตาราง embedding บน Postgres ที่ใช้สคีมาร่วมกัน และแยกชั้นการเก็บข้อมูล/การค้นถาม/การยืนยันตัวตน·สิทธิ์การเข้าถึง·การตรวจสอบ·การวิเคราะห์ ออกจากกัน เพื่อให้เพิ่มแหล่งข้อมูลใหม่ได้ง่าย
• การค้นหาใน Slack ใช้แค่ embedding ของข้อความต้นฉบับอย่างเดียวไม่พอ จึงใช้ทั้งการค้นหาแบบ full-text/การค้นหา embedding/inverse document frequency/การลดน้ำหนักตามเวลา ร่วมกัน และทำ embedding แยกสำหรับสรุปเธรดกับชุดข้อความสำคัญรายช่วง
• สำหรับทุกคำถาม LLM จะวางแผนก่อนว่าจะใช้เครื่องมือค้นหาใด จากนั้นจึงรวบรวมผลแบบขนานแล้วรวมด้วย RRF และโมเดล reranking ส่วนใน MCP จะเปิดเผยความสามารถค้นหาเดียวกันนี้เป็นเครื่องมือพื้นฐานขนาดเล็กและเสถียรโดยตรง
• ไม่ค้นทั้งองค์กรแบบเหมารวม แต่กำหนดค่าเริ่มต้นเป็น ขอบเขตการค้นหาระดับโปรเจกต์ ที่รวม Slack channel/ที่เก็บ/พื้นที่เอกสาร เป็นต้น เพื่อให้แต่ละทีมได้ผลลัพธ์ที่เกี่ยวข้องมากกว่า

---

เก็บข้อมูลโดยตรงจากจุดที่ข้อมูลถูกสร้างขึ้น

• ในทีม data center operations/การออกแบบชิป/ฮาร์ดแวร์/การฝึก/การอนุมาน/คลาวด์แพลตฟอร์มของ Cerebras มีคนใหม่เข้าร่วมหลายร้อยคนทุกปี ทำให้คำถามอย่าง “X อยู่ที่ไหน”, “ใครคือผู้เชี่ยวชาญเรื่อง Y”, “Z คืออะไร” ถูกถามซ้ำอยู่เสมอ
• พวกเขามองว่าวิธีบันทึกข้อมูลทั้งหมดไว้ในแพลตฟอร์มเดียวใช้ได้ไม่ดีในงานจริง
  • ข้อมูลเกิดขึ้นในเครื่องมือที่เหมาะกับงานนั้น เช่น การแก้ไขข้อเสนอในเอกสาร, เธรด Slack, การอ้างอิงโค้ดบน GitHub, เมตาดาต้าสถานะใน Jira
  • แต่ละแพลตฟอร์มถูกปรับแต่งให้เหมาะกับโดเมนเฉพาะผ่านการพัฒนาผลิตภัณฑ์และการวิเคราะห์มานาน จึงตัดสินใจไม่บังคับให้ผู้ใช้เปลี่ยนวิธีทำงาน
• ในขั้นตอนการเก็บข้อมูลจึงเชื่อมต่อกับแต่ละแพลตฟอร์มโดยตรง เพื่อลดการเปลี่ยนแปลงพฤติกรรมการทำงานเดิมให้น้อยที่สุด

สถาปัตยกรรมที่มีตาราง embedding กลางเป็นศูนย์กลาง

• คลังความรู้ประกอบด้วย 3 ชั้น
  • แพลตฟอร์มที่เก็บและจัดเก็บข้อมูลภายใน
  • แพลตฟอร์มที่ใช้ค้นถามข้อมูลที่เก็บแล้ว
  • ชั้นที่ใช้การยืนยันตัวตน/การกำหนดสิทธิ์/การตรวจสอบ/การวิเคราะห์
• ตรงกลางมีตาราง Postgres เดียวที่เก็บ embedding/สรุปต้นฉบับ/เมตาดาต้า จากหลายแหล่ง
• เธรด Slack, ที่เก็บโค้ด, ระบบเอกสาร, netlist และฐานข้อมูลแบบกำหนดเอง ใช้อินเทอร์เฟซแถว embedding แบบเดียวกัน
• แต่ละแหล่งข้อมูลจะระบุคำนิยามข้อมูล วิธีเชื่อมต่อ และรอบการเก็บข้อมูล และทันทีที่เขียนลงตารางกลางก็สามารถค้นได้ผ่านอินเทอร์เฟซค้นถามเดียวกัน
• จงใจทำให้อินเทอร์เฟซข้อมูลเรียบง่าย เพื่อให้นักพัฒนา Cerebras สร้างตัวเชื่อมต่อแยกเองได้

การค้นหาแบบผสมที่จำเป็นสำหรับ Slack

• Slack เป็นแหล่งข้อมูลที่สำคัญที่สุดสำหรับการสนทนาวิศวกรรมล่าสุด
• การค้นหาเวกเตอร์ด้วยการทำ embedding จากข้อความต้นฉบับอย่างเดียวทำให้หาข้อมูลที่เกี่ยวข้องทั้งหมดได้ยาก
  • ข้อความสั้นอย่าง “โอเค ดีเลย” และคำอธิบาย kernel แบบละเอียดถูกเก็บในหน่วยข้อความแบบเดียวกัน
  • ข้อความสั้นมักมี cosine similarity สูงกว่าข้อความที่ยาวและละเอียดกว่า
  • ความหมายของข้อความแต่ละอันขึ้นอยู่กับบทสนทนาแวดล้อม
• แต่ละเธรดใน Slack ถูกค้นพร้อมกัน 4 วิธี
  • การค้นหาแบบ full-text ใช้หาโทเค็นที่ต้องตรงเป๊ะ เช่น สตริงข้อผิดพลาด/ชื่อ flag/ชื่อโฮสต์ ซึ่งมักเลือนหายไปใน embedding
  • การค้นหา embedding เชื่อมคำถามและคำตอบที่ใช้คำต่างกัน เช่น “กู้คืนหลัง manifest แล้วค้าง” กับ “checkpoint หยุดที่ NFS mount”
  • inverse document frequency (IDF) ช่วยดันอันดับข้อความสั้นที่มี flag การตั้งค่าหายาก และลดคะแนนวลีตอบสนองทั่วไปที่พบบ่อย
  • การลดน้ำหนักตามเวลา ทำให้ในคำตอบที่เกี่ยวข้องพอๆ กัน เธรดใหม่ถูกเลือกก่อนเธรดเก่าที่อาจอธิบายโครงสร้างพื้นฐานแบบเดิม
• ไม่เชื่อคะแนนแบบใดแบบหนึ่งเพียงอย่างเดียว แต่รวมรายการอันดับจากตัวค้นแต่ละตัวเข้าด้วยกันตอน query

การเก็บข้อมูลแบบเรียลไทม์ด้วย Socket Mode

• ติดตั้ง Slack bot ใน workspace และรับอีเวนต์ข้อความทั้งหมดผ่านการเชื่อมต่อ WebSocket แบบต่อเนื่องของ Socket Mode
• อัปเดตแบบเรียลไทม์โดยไม่ต้องเรียก Web API ซ้ำๆ และลดการใช้โควตา rate limit
• เมื่ออีเวนต์มาถึง ระบบจะตอบกลับทันที ลบข้อมูลซ้ำด้วย event ID ที่เสถียร แล้วทำเครื่องหมายให้ consumer ฝั่งเก็บข้อมูลไปประมวลผล
• ไม่เก็บข้อความใหม่แบบแยกเดี่ยว แต่ดึงทั้งเธรดที่ข้อความนั้นสังกัดกลับมาใหม่
  • เก็บข้อความแม่และคำตอบทั้งหมดไว้ในหนึ่งแถว
  • เมื่อมีคำตอบใหม่เพิ่มในเธรดเดิม ระบบจะอัปเดตข้อความแม่/คำตอบพี่น้อง/รายชื่อผู้ร่วมสนทนา/เวลาที่มีกิจกรรมล่าสุด ให้เป็นปัจจุบันทั้งหมด
• ตั้งแหล่งข้อมูลแยกตามแต่ละ Slack channel เพื่อให้ช่องที่เปลี่ยนบ่อยอย่างช่องตอบสนองเหตุการณ์ ตั้งรอบเก็บข้อมูลสั้นกว่าช่องอื่นได้

การกลั่นและจัดโครงสร้างเธรด

• ข้อความ Slack ต้นฉบับสามารถค้นด้วยคีย์เวิร์ดได้ทันทีหลังบันทึกผ่าน GIN full-text index ของ Postgres
• สำหรับข้อมูลที่ใช้ค้นหาเวกเตอร์ LLM จะดึงสิ่งต่อไปนี้จากทั้งเธรด
  • คำถามหนึ่งบรรทัดที่วิศวกรน่าจะค้นจริง
  • สรุปสั้น
  • วิธีแก้ปัญหา
  • ระบบที่เกี่ยวข้องและการอ้างอิงโค้ด
• จากนั้นนำรายการที่ดึงมาไปทำ embedding และเก็บไว้ในตารางกลาง โดยไม่ทำ embedding กับบทสนทนาต้นฉบับโดยตรง
• จากการทดลอง เมื่อทำให้เธรดถูกทำให้เป็นรูปแบบเดียวกันอย่างสม่ำเสมอ ความแม่นยำเพิ่มขึ้นมาก และเมตาดาต้าเพิ่มเติมก็เป็นสัญญาณที่มีประโยชน์กว่าสำหรับการค้นหาเชิงความหมาย

Bursting เพื่อเก็บข้อความสำคัญในเธรดยาว

• การมีแค่สรุประดับเธรดยังทำให้ข้อความสำคัญในบทสนทนายาวบางส่วนตกหล่น
• จึงรวมข้อความต่อเนื่องจากผู้เขียนคนเดียวกันเป็น burst และเติมหัวข้อของเธรดไว้ด้านหน้าเป็นบริบท ก่อนทำ embedding แยกต่างหาก
• ทำให้สามารถค้นเจอคำตอบจากบทสนทนาแยกย่อยที่ไม่ถูกใส่ไว้ในสรุประดับเธรดได้อย่างอิสระ
• คำนวณสัญญาณถ่วงน้ำหนักเพื่อไม่ให้ข้อความสัญญาณต่ำเข้าไปในฐานข้อมูล และเก็บเฉพาะชุดที่ผ่านเกณฑ์
  • มีโทเค็นหายากที่มี IDF ตั้งแต่ 4.0 ขึ้นไปในทั้งคอร์ปัส
  • ความยาวรวมของข้อความที่รวมกันอย่างน้อย 200 อักขระ
  • มี reaction emoji ในอย่างน้อยหนึ่งข้อความเพื่อเพิ่มน้ำหนักทางสังคม
• ชุดที่ผ่านเงื่อนไขจะถูกเก็บลงตาราง embedding กลางควบคู่กับเรคคอร์ดระดับเธรด

การทำ embedding แบบเพิ่มเฉพาะส่วนสำหรับที่เก็บโค้ดขนาดใหญ่

• เมื่อเครื่องมือ command-line อย่าง Claude Code แพร่หลายขึ้น พวกเขาเคยมองว่า grep อาจเพียงพอสำหรับโค้ด แต่หลังจากตรวจสอบความเห็นในอุตสาหกรรมและผลการค้นหาเชิงความหมายในโค้ดเบสขนาดใหญ่ของ Cursor ก็เริ่มใช้ code embedding
• ที่เก็บภายในบางส่วนมีขนาดเกิน 40GB ทำให้ต้นทุนของการทำ embedding ใหม่ทั้งก้อนอย่างต่อเนื่องเป็นความท้าทายหลัก
• หลังจากทดลองหลายอย่าง จึงเลือก CocoIndex ซึ่งเป็นเฟรมเวิร์ก open source สำหรับทำ document embedding ที่ออกแบบมาสำหรับ vectorizing codebase
• โค้ดถูกแบ่งด้วยขอบเขต regex ตามภาษา จากหน่วยใหญ่ไปหาเล็ก
  • เริ่มจากขอบเขตระดับบนอย่าง class ก่อน
  • ถ้า chunk ยังใหญ่เกินไป ก็ลดลงไปที่ method และบล็อกที่เล็กกว่า
  • ในไฟล์เดียวอาจมี embedding หลายตัวที่ระดับความละเอียดต่างกัน เช่น ระดับไฟล์/ระดับฟังก์ชัน
• CocoIndex จะเก็บเมตาดาต้าการซิงก์ไว้ใน Postgres เพื่อทำ embedding และส่งออกใหม่เฉพาะ chunk โค้ดที่เปลี่ยนไปในแต่ละ commit
• หลังจากจำนวนที่เก็บเพิ่มขึ้น ก็เปลี่ยนการ onboarding มาใช้ไฟล์คอนฟิกที่ทีมส่งเข้ามาเองได้ พร้อมรองรับ allowlist/blocklist ตามเส้นทางไฟล์

การเชื่อมต่อแหล่งข้อมูลแบบกำหนดเอง

• บางทีมต้องการใช้อินเทอร์เฟซค้นหาเดียวกันกับข้อมูลในฐานข้อมูลเดิม โดยไม่ต้องย้ายมันไปไว้ใน Slack หรือระบบเอกสาร
• แหล่งข้อมูลแบบกำหนดเองถูกมองเป็นสคริปต์ปลั๊กอิน
  • ทีมสามารถส่ง Python module ขนาดเล็กผ่าน pull request เพื่ออ่านระบบเดิมและส่งออกแถวในรูปแบบตาราง embedding กลาง
  • พร้อมเพิ่มคอนฟิกแหล่งข้อมูลที่สอดคล้องกันไปด้วย
• แค่เขียนลงฐานข้อมูลที่ใช้ร่วมกันด้วยสคีมาร่วม ก็จะค้นได้ร่วมกับ Slack/โค้ด/เอกสาร โดยระบบส่วนที่เหลือไม่ต้องมีการจัดการเฉพาะเพิ่มเติม

การวางแผน query และรันเครื่องมือแบบขนาน

• สำหรับทุกคำถาม LLM จะรันขั้นวางแผนสั้นๆ ก่อน เพื่อกำหนดเครื่องมือและแหล่งข้อมูลที่จะใช้
• เครื่องมือหลักมีดังนี้
  • subsystem_index: สรุปโดย LLM แยกตามไฟล์
  • search: การค้นหาเวกเตอร์ที่รวมดัชนี Slack/wiki/โค้ด/อื่นๆ และผสานผลกับ reranking ภายใน
  • search_slack: ค้นหา Slack โดยตรง
  • search_code: ripgrep สำหรับที่เก็บซอร์ส
  • recent_prs: pull request ล่าสุดที่เกี่ยวข้องกับคำถาม
  • who_knows: ค้นหาคนที่แสดงความเชี่ยวชาญจริงในหัวข้อหนึ่งๆ
• ตัววางแผนใช้รายการโปรเจกต์/แหล่งข้อมูลรายโปรเจกต์/คำอธิบายแบบย่อว่าแต่ละแหล่งตอบคำถามแบบใดได้ดี
• ตัวรันจะเรียกเครื่องมือที่เลือกแบบขนาน ปรับผลลัพธ์ให้อยู่ในรูปแบบหลักฐานร่วมกัน แล้วส่งต่อให้ LLM ตัวสังเคราะห์สุดท้าย

RRF และ reranking

• เอกสารที่แชร์แค่คำศัพท์เดียวกับ query แต่จริงๆ ตอบคำถามคนละเรื่อง อาจขึ้นมาอยู่ด้านบนได้ จึงมีขั้น reranking แยกต่างหาก
• รายการอันดับจากตัวค้นต่างๆ ถูกผสานด้วย Reciprocal Rank Fusion (RRF)
  • สำหรับแต่ละรายการที่เอกสารปรากฏ จะบวก weight / (60 + rank)
  • ค่า weight เริ่มต้นคือ 1.0 และค่าคงที่ smoothing คือ 60
  • เอกสารที่ขึ้นสูงอย่างสม่ำเสมอในหลายตัวค้น อาจแซงเอกสารที่ได้อันดับ 1 จากตัวค้นเพียงตัวเดียว
• รวม chunk ที่ซ้ำกันกลับไปยังหน่วยต้นฉบับ และจำกัดจำนวนผลลัพธ์ต่อไฟล์ เพื่อสร้างผู้เข้าชิงอันดับต้น 20 ที่หลากหลาย
• โมเดล reranking ขนาดเล็กจะให้คะแนนแต่ละเอกสาร 0~10 โดยอิงจากคำถามเดิม แล้วเก็บ 10 อันดับแรกไว้
• ผลลัพธ์สุดท้ายจะเติมบริบทโดยรอบกลับเข้าไปอีกครั้ง
  • ถ้าตรงกับส่วนหนึ่งของ wiki ก็จะดึงอีกสองส่วนที่อยู่ติดกันมาด้วย เพื่อไม่ให้หัวข้อ/เงื่อนไขล่วงหน้า/ข้อควรระวัง หายไปจากการแบ่ง chunk
• ผลการค้นหาจะถูกส่งกลับเป็นชุดหลักฐานที่ผ่านการรวมหลายตัวค้น/ลบข้อมูลซ้ำในระดับหน่วยต้นฉบับ/reranking ตามคำถาม/ขยายบริบทรอบข้าง

การแบ่งบทบาทระหว่าง MCP กับเว็บ UI

• ใน MCP แทนที่จะมี endpoint เดียวแบบ “ตอบคำถาม” ระบบจะเปิด ความสามารถค้นหาพื้นฐาน อย่าง search_slack, search_code, search, who_knows เป็นเครื่องมือแยกแต่ละตัว
• เพื่อลดต้นทุนและเพิ่มความเร็วในการเรียกใช้เครื่องมือ จึงตัดการพึ่งพา LLM ออกให้มากที่สุด
  • ทำให้ขอบเขตอินพุตและเอาต์พุตแคบ มีโครงสร้าง และเสถียร
  • ใช้กฎการให้คะแนนแบบเบากับ pipeline เดี่ยวอย่าง vector search/lexical search/ripgrep แล้วส่งกลับแถวหลักฐานดิบ
• ทำให้เอเจนต์ที่เข้ากันได้กับ MCP เช่น Claude Code กลายเป็น orchestration engine ที่ตัดสินใจว่าจะเรียกเครื่องมืออะไร ลำดับไหน และจะผสมผลลัพธ์อย่างไร
• ในเว็บ UI ระบบจะนำเครื่องมือเดียวกันมาเชื่อมเป็น pipeline การ query ที่สมบูรณ์
  • planner จะดูคำถามและโปรเจกต์ที่เปิดใช้งาน เพื่อเลือกเครื่องมือค้นหาที่ต้องเรียก
  • executor จะประมวลผลการเรียกแบบขนานและแปลงเป็นสคีมาหลักฐานร่วมที่มีคะแนน/ความใหม่/คำใบ้แหล่งที่มา
  • synthesizer จะสร้างคำตอบจากคำถามและชุดหลักฐาน พร้อมการอ้างอิง/ข้อควรระวัง/การบูรณาการข้ามแหล่งข้อมูล
• ผู้ใช้เพียงแค่ถามและรับคำตอบ แต่ภายในจะทำงานเป็นลำดับ planner → executor → synthesizer

ขอบเขตการค้นหาระดับโปรเจกต์

• เมื่อคอร์ปัสมีขนาดใหญ่ขึ้น ความเกี่ยวข้องของการค้นทั้งองค์กรตลอดเวลาลดลงอย่างรวดเร็ว
  • ทีมคอมไพเลอร์ไม่ต้องการให้ขั้นตอนปฏิบัติการโครงสร้างพื้นฐานโผล่มาในผลค้นหา และในทางกลับกันก็เช่นกัน
• จึงนำ โปรเจกต์ มาเป็น workspace เริ่มต้นที่ใช้รัน query
  • รวม Slack channel/ที่เก็บโค้ด/ฐานข้อมูลภายใน/พื้นที่เอกสาร เฉพาะตามทีมหรืองาน
  • ช่อง incident ที่ใช้ร่วมกันหรือที่เก็บแพลตฟอร์มส่วนกลางหนึ่งชุด สามารถถูกอ้างถึงในหลายโปรเจกต์ได้โดยไม่ต้องทำสำเนาข้อมูล
• ระหว่าง onboarding ผู้ใช้จะถูกชวนให้เลือกหรือสร้างโปรเจกต์เริ่มต้นที่ตรงกับงาน เช่น ML training infrastructure/Compiler/Data Center Operations
• โปรเจกต์เริ่มต้นจะถูกเก็บไว้ในโปรไฟล์ผู้ใช้และจำกัดขอบเขตทุก query โดยอัตโนมัติ ทำให้วิศวกรใหม่เริ่มค้นหาได้ทันทีโดยไม่ต้องรู้จักช่องและที่เก็บที่เกี่ยวข้องก่อน

คลังความรู้ที่ยังคงใช้เครื่องมือเดิม

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