Cerebras đã xây dựng kho tri thức nội bộ như thế nào

• Cerebras đã xây dựng Cerebras Knowledge, thu thập trực tiếp từ Slack/kho mã/tài liệu/cơ sở dữ liệu nội bộ ngay tại vị trí hiện có; chỉ 3 tháng sau khi ra mắt, hệ thống xử lý hơn 15.000 câu hỏi mỗi ngày từ nhân viên/tự động hóa/agent
• Thay vì chuyển toàn bộ dữ liệu vào một công cụ, họ kết nối dữ liệu vào bảng embedding Postgres theo schema chung, đồng thời tách các lớp thu thập/truy vấn/xác thực·phân quyền·kiểm toán·phân tích để dễ dàng thêm nguồn dữ liệu mới
• Tìm kiếm Slack không đủ nếu chỉ embedding văn bản gốc, nên hệ thống dùng kết hợp tìm kiếm toàn văn/embedding search/tần suất nghịch đảo tài liệu/time decay, đồng thời embedding riêng phần tóm tắt thread và các cụm phát ngôn cá nhân quan trọng
• Với mỗi truy vấn, LLM trước tiên lập kế hoạch các công cụ tìm kiếm sẽ dùng, thu thập kết quả song song rồi hợp nhất bằng RRF và mô hình reranking; trong MCP, cùng các chức năng tìm kiếm đó được công khai trực tiếp dưới dạng các công cụ nguyên thủy nhỏ và ổn định
• Thay vì tìm kiếm vô điều kiện trên toàn tổ chức, hệ thống đặt mặc định phạm vi tìm kiếm theo dự án, gom các kênh Slack/kho mã/không gian tài liệu..., để cung cấp kết quả phù hợp hơn cho từng nhóm

---

Thu thập trực tiếp tại nơi thông tin được tạo ra

• Trong các nhóm vận hành trung tâm dữ liệu/thiết kế chip/phần cứng/huấn luyện/suy luận/nền tảng cloud của Cerebras, mỗi năm có hàng trăm người mới gia nhập, khiến các câu hỏi như “X ở đâu”, “ai là chuyên gia về Y”, “Z là gì” lặp đi lặp lại
• Họ nhận định rằng cách ghi mọi thông tin vào một nền tảng duy nhất không vận hành tốt trong công việc thực tế
  • Thông tin được tạo ra trong công cụ phù hợp với từng tác vụ, chẳng hạn đề xuất chỉnh sửa tài liệu, thread Slack, tham chiếu mã GitHub, metadata trạng thái Jira
  • Mỗi nền tảng đã được tối ưu cho một lĩnh vực cụ thể qua quá trình phát triển và phân tích sản phẩm lâu dài, nên họ quyết định không ép mọi người thay đổi cách sử dụng
• Ở bước thu thập, hệ thống kết nối trực tiếp với từng nền tảng để giảm thiểu thay đổi trong hành vi làm việc hiện có

Kiến trúc xoay quanh bảng embedding chung

• Kho tri thức gồm ba lớp
  • Nền tảng thu thập và lưu trữ dữ liệu nội bộ
  • Nền tảng truy vấn dữ liệu đã lưu
  • Lớp áp dụng xác thực/phân quyền/kiểm toán/phân tích
• Ở trung tâm là một bảng Postgres duy nhất lưu embedding/tóm tắt văn bản gốc/metadata từ nhiều nguồn
• Thread Slack, kho mã, hệ thống tài liệu, netlist và cơ sở dữ liệu tùy chỉnh đều dùng cùng một giao diện hàng embedding
• Mỗi nguồn dữ liệu chỉ định định nghĩa dữ liệu, cách kết nối và chu kỳ thu thập; ngay khi được ghi vào bảng chung, dữ liệu có thể được tìm kiếm qua cùng một giao diện truy vấn
• Giao diện dữ liệu được cố ý giữ đơn giản để các nhà phát triển Cerebras có thể tự tạo connector riêng

Tìm kiếm kết hợp cần thiết cho Slack

• Slack là nguồn dữ liệu quan trọng nhất, nơi diễn ra các thảo luận kỹ thuật mới nhất
• Chỉ dùng vector search áp dụng embedding đơn giản lên văn bản gốc là khó tìm đầy đủ thông tin liên quan
  • Những tin nhắn ngắn như “ừ, được” và phần giải thích kernel chi tiết được lưu ở cùng đơn vị tin nhắn
  • Tin nhắn ngắn thường xếp cao hơn tin nhắn dài và chi tiết hơn theo cosine similarity
  • Ý nghĩa của từng tin nhắn phụ thuộc vào cuộc hội thoại xung quanh
• Mỗi thread Slack được tìm kiếm đồng thời theo bốn cách
  • Tìm kiếm toàn văn tìm các token chính xác dễ bị làm mờ trong embedding, như chuỗi lỗi/tên flag/tên host
  • Embedding search kết nối câu hỏi và câu trả lời được diễn đạt bằng từ vựng khác nhau, như “khôi phục bị dừng sau manifest” và “checkpoint bị treo trên mount NFS”
  • Tần suất nghịch đảo tài liệu (IDF) nâng hạng các tin nhắn ngắn chứa flag cấu hình hiếm và hạ điểm các cụm phản hồi phổ biến
  • Time decay ưu tiên thread mới hơn so với thread cũ có thể mô tả hạ tầng đã lỗi thời, trong số các câu trả lời có cùng mức liên quan
• Họ không tin cậy một điểm số duy nhất mà kết hợp các danh sách xếp hạng do từng bộ tìm kiếm tạo ra tại thời điểm truy vấn

Thu thập thời gian thực dựa trên Socket Mode

• Bot Slack được cài vào workspace và nhận mọi sự kiện tin nhắn qua kết nối WebSocket liên tục của Socket Mode
• Hệ thống cập nhật theo thời gian thực mà không cần gọi lặp lại Web API, đồng thời giảm tiêu thụ hạn mức rate limit của request
• Khi sự kiện đến, hệ thống phản hồi ngay, loại bỏ trùng lặp bằng event ID ổn định, rồi đánh dấu để consumer thu thập xử lý
• Tin nhắn mới không được lưu độc lập; thay vào đó, toàn bộ thread chứa tin nhắn đó được tải lại
  • Tin nhắn cha và mọi phản hồi được lưu thành một hàng
  • Khi có phản hồi được thêm vào thread hiện có, tin nhắn cha/các phản hồi anh em/danh sách người tham gia/thời điểm hoạt động cuối đều được cập nhật lên trạng thái mới nhất
• Mỗi kênh Slack có nguồn dữ liệu riêng, nên các kênh thay đổi thường xuyên như kênh ứng phó sự cố có thể được đặt chu kỳ thu thập ngắn hơn

Chưng cất và cấu trúc hóa thread

• Văn bản Slack gốc có thể được tìm kiếm theo từ khóa ngay sau khi lưu thông qua chỉ mục toàn văn GIN của Postgres
• Với dữ liệu cho vector search, LLM trích xuất các mục sau từ toàn bộ thread
  • Câu hỏi một dòng mà kỹ sư thực sự có thể tìm kiếm
  • Tóm tắt ngắn
  • Cách giải quyết
  • Hệ thống liên quan và tham chiếu mã
• Các mục được trích xuất được embedding rồi lưu vào bảng chung; bản thân cuộc hội thoại gốc không được embedding trực tiếp
• Trong thử nghiệm, độ chính xác tăng mạnh khi thread được chuẩn hóa theo định dạng nhất quán, và metadata bổ sung cũng cung cấp tín hiệu hữu ích hơn cho tìm kiếm ngữ nghĩa

Bursting để giữ lại từng tin nhắn trong thread dài

• Chỉ tóm tắt ở cấp thread vẫn còn vấn đề bỏ sót các tin nhắn quan trọng trong cuộc hội thoại dài
• Các tin nhắn liên tiếp do cùng một tác giả gửi được kết hợp thành cụm phát ngôn liên tiếp (burst), gắn chủ đề thread ở phía trước làm ngữ cảnh rồi embedding riêng
• Câu trả lời trong các nhánh hội thoại phụ không có trong tóm tắt thread cũng có thể được tìm kiếm độc lập
• Hệ thống tính tín hiệu có trọng số để các phát ngôn tín hiệu thấp không đi vào cơ sở dữ liệu, và chỉ lưu các cụm vượt ngưỡng
  • Chứa token hiếm có IDF từ 4.0 trở lên trong toàn bộ corpus
  • Độ dài phát ngôn kết hợp tối thiểu 200 ký tự
  • Ít nhất một tin nhắn có emoji reaction, nhận được trọng số xã hội
• Các cụm đáp ứng điều kiện được lưu vào bảng embedding chung cùng với bản ghi cấp thread

Embedding tăng dần cho kho mã quy mô lớn

• Khi các công cụ dòng lệnh như Claude Code lan rộng, họ từng cho rằng với mã thì chỉ cần grep là đủ; nhưng sau khi xem xét ý kiến từ người trong ngành và kết quả tìm kiếm ngữ nghĩa trên codebase lớn của Cursor, họ đã đưa code embedding vào sử dụng
• Một số kho nội bộ vượt quá 40GB, khiến chi phí liên tục embedding lại toàn bộ trở thành thách thức lớn
• Sau nhiều thử nghiệm, họ chọn CocoIndex, một framework embedding tài liệu mã nguồn mở chuyên cho vector hóa codebase
• Mã được chia nhỏ bằng cách áp dụng ranh giới regex theo từng ngôn ngữ, từ đơn vị lớn đến đơn vị nhỏ
  • Trước tiên dùng ranh giới cấp cao như class
  • Nếu chunk quá lớn, hạ xuống method và các ranh giới block nhỏ hơn
  • Trong một file, có thể tạo nhiều embedding ở các độ chi tiết khác nhau như cấp file/cấp function
• CocoIndex duy trì metadata đồng bộ trong Postgres để chỉ embedding lại và xuất ra các chunk mã đã thay đổi theo từng commit
• Khi số kho tăng lên, quy trình onboarding được chuyển sang file cấu hình để các nhóm tự gửi, đồng thời hỗ trợ allowlist/blocklist theo đường dẫn file

Kết nối nguồn dữ liệu tùy chỉnh

• Một số nhóm muốn dùng cùng giao diện tìm kiếm mà không chuyển thông tin trong cơ sở dữ liệu hiện có sang Slack hay hệ thống tài liệu
• Nguồn tùy chỉnh được xem như script plugin
  • Nhóm gửi pull request chứa module Python nhỏ đọc hệ thống hiện có và xuất các hàng theo dạng bảng embedding chung
  • Thiết lập nguồn dữ liệu tương ứng cũng được thêm cùng lúc
• Chỉ cần ghi vào cơ sở dữ liệu dùng chung theo schema chung là dữ liệu sẽ được tìm kiếm cùng Slack/mã/tài liệu; phần còn lại của hệ thống không cần xử lý riêng

Lập kế hoạch truy vấn và chạy công cụ song song

• Với mọi câu hỏi, LLM trước tiên chạy một bước lập kế hoạch ngắn để quyết định công cụ và nguồn dữ liệu sẽ dùng
• Các công cụ chính gồm
  • subsystem_index: tóm tắt của LLM theo từng file
  • search: vector search hợp nhất các chỉ mục Slack/wiki/mã/khác, đồng thời merge và rerank bên trong
  • search_slack: tìm kiếm trực tiếp trên Slack
  • search_code: ripgrep trên kho mã nguồn
  • recent_prs: các pull request gần đây liên quan đến câu hỏi
  • who_knows: tìm những người đã thực sự thể hiện chuyên môn về một chủ đề cụ thể
• Planner dùng danh sách dự án/nguồn dữ liệu theo dự án/phần mô tả nén về loại câu hỏi mà từng nguồn trả lời tốt
• Executor gọi song song các công cụ đã chọn, chuẩn hóa kết quả về một định dạng bằng chứng chung, rồi chuyển cho LLM tổng hợp cuối cùng

RRF và reranking

• Vì tài liệu có thể chia sẻ từ vựng với truy vấn nhưng thực ra trả lời một câu hỏi khác vẫn xuất hiện ở vị trí cao, hệ thống có bước reranking riêng
• Danh sách xếp hạng từ các bộ tìm kiếm khác nhau được kết hợp bằng Reciprocal Rank Fusion (RRF)
  • Với mỗi danh sách mà tài liệu xuất hiện, cộng weight / (60 + rank)
  • Trọng số mặc định là 1.0, hằng số làm mượt là 60
  • Tài liệu xuất hiện đều ở vị trí cao trong nhiều bộ tìm kiếm có thể vượt tài liệu chỉ đứng hạng 1 trong một bộ tìm kiếm duy nhất
• Các chunk trùng lặp được gộp theo đơn vị gốc, số kết quả theo file được giới hạn để tạo ra 20 ứng viên hàng đầu đa dạng
• Một mô hình reranking nhỏ chấm điểm từng tài liệu từ 0 đến 10 dựa trên câu hỏi ban đầu và giữ lại top 10
• Kết quả cuối cùng được bổ sung lại ngữ cảnh xung quanh
  • Nếu một section wiki khớp, hệ thống lấy kèm hai section lân cận để tiêu đề/điều kiện tiên quyết/lưu ý không biến mất do chia chunk
• Kết quả tìm kiếm được trả về dưới dạng một cụm bằng chứng đã đi qua kết hợp nhiều bộ tìm kiếm/khử trùng lặp theo đơn vị gốc/reranking dựa trên câu hỏi/mở rộng ngữ cảnh xung quanh

Phân vai giữa MCP và web UI

• Trong MCP, thay vì một endpoint “trả lời câu hỏi”, các chức năng tìm kiếm cơ bản như search_slack, search_code, search, who_knows được công khai thành từng công cụ
• Để có thể gọi công cụ nhanh và rẻ, họ loại bỏ phụ thuộc vào LLM nhiều nhất có thể
  • Giữ phạm vi đầu vào và đầu ra hẹp, có cấu trúc và ổn định
  • Áp dụng các quy tắc chấm điểm nhẹ lên một pipeline đơn lẻ như vector search/tìm kiếm từ vựng/ripgrep để trả về các hàng bằng chứng thô
• Các agent tương thích MCP, bao gồm Claude Code, trở thành engine điều phối quyết định công cụ cần gọi/thứ tự/cách kết hợp kết quả
• Trong web UI, cùng các công cụ được nối thành một pipeline truy vấn hoàn chỉnh
  • Planner xem câu hỏi và dự án đang hoạt động để chọn công cụ tìm kiếm sẽ gọi
  • Executor xử lý các lệnh gọi song song và chuyển đổi thành schema bằng chứng chung gồm điểm số/độ mới/gợi ý nguồn
  • Synthesizer tạo câu trả lời từ câu hỏi và cụm bằng chứng, bao gồm trích dẫn/lưu ý/tích hợp giữa các nguồn
• Người dùng chỉ đặt câu hỏi và nhận câu trả lời, nhưng bên trong là luồng planner → executor → synthesizer

Phạm vi tìm kiếm theo dự án

• Khi corpus lớn lên, mức độ liên quan của cách luôn tìm kiếm trên toàn tổ chức giảm mạnh
  • Nhóm compiler không muốn quy trình vận hành hạ tầng xuất hiện trong kết quả tìm kiếm, và chiều ngược lại cũng tương tự
• Dự án được đưa vào làm workspace mặc định nơi truy vấn được chạy
  • Gom các kênh Slack/kho mã/cơ sở dữ liệu nội bộ/không gian tài liệu cụ thể theo nhóm hoặc nhiệm vụ
  • Một kênh sự cố dùng chung hoặc một kho nền tảng trung tâm có thể được nhiều dự án tham chiếu mà không sao chép dữ liệu
• Trong quá trình onboarding, người dùng chọn hoặc tạo dự án mặc định phù hợp với công việc như hạ tầng huấn luyện ML/Compiler/Data Center Operations
• Dự án mặc định được lưu trong hồ sơ người dùng và tự động giới hạn phạm vi mọi truy vấn, giúp kỹ sư mới có thể bắt đầu tìm kiếm mà không cần biết trước các kênh và kho liên quan

Kho tri thức vẫn giữ các công cụ hiện có

• Nguyên tắc vận hành của kho tri thức là không chuyển thông tin vào một hệ thống cứng nhắc duy nhất, mà thu thập tại nơi thông tin đã được tạo ra
• Bằng cách kết hợp nhiều phương thức tìm kiếm, hệ thống tìm bằng chứng nhanh trong khi vẫn chấp nhận sự đa dạng của dữ liệu doanh nghiệp thực tế, đồng thời tạo ra kiến trúc có thể duy trì tính hữu ích khi tổ chức tăng trưởng