Cerebras ने अपना इन-हाउस knowledge base कैसे बनाया

 (x.com/cerebras)
6 पॉइंट द्वारा GN⁺ 1 시간 전 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • Slack/कोड रिपॉज़िटरी/डॉक्यूमेंट/आंतरिक डेटाबेस से उनकी मौजूदा जगहों पर सीधे डेटा इकट्ठा करने वाला Cerebras Knowledge बनाया और लॉन्च के 3 महीनों में ही कर्मचारियों/ऑटोमेशन/एजेंट्स से रोज़ 15,000 से अधिक सवाल संभालने लगा
  • सभी डेटा को एक ही टूल में ले जाने के बजाय, उसे सामान्य schema वाली Postgres embedding table से जोड़ा गया और ingestion/query/authentication·authorization·audit·analytics लेयर्स को अलग रखा गया ताकि नए data source आसानी से जोड़े जा सकें
  • Slack search में केवल raw text embeddings काफ़ी नहीं थे, इसलिए full-text search/embedding search/inverse document frequency/time decay को साथ में इस्तेमाल किया गया, और thread summary तथा महत्वपूर्ण individual utterance groups को अलग से embed किया गया
  • हर query पर LLM पहले यह plan करता है कि कौन से search tools इस्तेमाल होंगे, फिर results को parallel में इकट्ठा किया जाता है और RRF व reranking model से जोड़ा जाता है; MCP में यही search functionality छोटे और स्थिर primitive tools के रूप में सीधे expose की गई है
  • पूरे संगठन में बिना सोचे-समझे search करने के बजाय, Slack channels/repositories/document spaces आदि को जोड़ने वाला project-level search scope default रखा गया ताकि हर टीम को अधिक प्रासंगिक results मिलें

जहाँ जानकारी बनती है, वहीं से सीधे संग्रह

  • Cerebras की data center operations/chip design/hardware/training/inference/cloud platform teams में हर साल सैकड़ों नए लोग जुड़ते हैं, जिससे “X कहाँ है”, “Y का expert कौन है”, “Z क्या है” जैसे सवाल बार-बार आते थे
  • कंपनी ने माना कि सारी जानकारी को एक single platform में लिखवाने का तरीका वास्तविक कामकाज में ठीक से नहीं चलता
    • जानकारी उसी टूल में बनती है जो उस काम के लिए सबसे उपयुक्त हो, जैसे document proposal edits, Slack threads, GitHub code references, Jira status metadata
    • हर platform लंबे product development और analysis के ज़रिए अपने क्षेत्र के लिए optimized है, इसलिए लोगों को उसका इस्तेमाल बदलने के लिए मजबूर नहीं किया गया
  • ingestion स्टेज पर हर platform से सीधे connect करके मौजूदा work behavior में बदलाव को न्यूनतम रखा गया

सामान्य embedding table केंद्रित आर्किटेक्चर

  • knowledge base तीन layers से बना है
    • आंतरिक डेटा को इकट्ठा और store करने वाला platform
    • stored data पर query चलाने वाला platform
    • authentication/authorization/audit/analytics लागू करने वाली layer
  • इसके केंद्र में एक single Postgres table है, जिसमें कई sources के embeddings/raw text summary/metadata store होते हैं
  • Slack threads, code repositories, document systems, netlists और custom databases सभी एक ही embedding row interface का इस्तेमाल करते हैं
  • हर data source डेटा की परिभाषा, connection method और ingestion cycle बताता है, और common table में लिखते ही वही data उसी query interface से searchable हो जाता है
  • Cerebras developers अलग connectors बना सकें, इसलिए data interface को जानबूझकर सरल रखा गया

Slack के लिए ज़रूरी hybrid search

  • Slack सबसे महत्वपूर्ण data source था, जहाँ ताज़ा engineering discussions होती थीं
  • raw text पर साधारण embeddings लगाने वाली vector search से सारी relevant जानकारी निकालना मुश्किल था
    • “हाँ, ठीक है” जैसे छोटे messages और kernel की विस्तृत explanation एक ही message unit में store होते थे
    • कई बार छोटे messages, लंबे और विस्तार वाले messages से cosine similarity में ऊपर आ जाते थे
    • individual messages का अर्थ अक्सर आसपास की conversation पर निर्भर करता था
  • हर Slack thread को चार तरीकों से एक साथ search किया गया
    • full-text search error strings/flag names/host names जैसे exact tokens ढूँढती है, जो embeddings में धुंधले हो सकते हैं
    • embedding search “manifest के बाद restore रुक जाता है” और “NFS mount पर checkpoint रुक जाता है” जैसे अलग शब्दों में पूछे गए सवाल-जवाब जोड़ती है
    • inverse document frequency (IDF) दुर्लभ configuration flags वाले छोटे messages की ranking बढ़ाती है और आम प्रतिक्रियात्मक वाक्यों के score घटाती है
    • time decay समान relevance वाले answers में पुराने threads की जगह नए threads को प्राथमिकता देती है, क्योंकि पुराने threads पुराने infrastructure को समझा सकते हैं
  • किसी एक score पर भरोसा करने के बजाय, query समय पर हर searcher की ranking lists को जोड़ा जाता है

Socket Mode आधारित real-time ingestion

  • Slack bot को workspace में install किया गया और Socket Mode की persistent WebSocket connection से सभी message events प्राप्त किए गए
  • बार-बार Web API call किए बिना real time में updates मिलते रहे और rate limit consumption कम हुआ
  • event आते ही तुरंत response दिया जाता है, stable event ID से deduplication किया जाता है, और फिर उसे ingestion consumer के processing के लिए mark किया जाता है
  • नया message अलग से store नहीं किया जाता, बल्कि उस message वाला पूरा thread फिर से fetch किया जाता है
    • parent message और उसके सभी replies को एक row में store किया जाता है
    • मौजूदा thread में reply जुड़ने पर parent/sibling replies/participants list/last activity time सब updated रहते हैं
  • हर Slack channel के लिए अलग data source रखा गया ताकि incident response channels जैसे ज़्यादा बदलने वाले channels के लिए ingestion cycle छोटा रखा जा सके

Thread distillation और structuring

  • raw Slack text को Postgres GIN full-text index के ज़रिए store होते ही keyword search के लिए उपलब्ध कराया गया
  • vector search के लिए LLM पूरे thread से ये चीज़ें निकालता है
    • एक लाइन का वह सवाल जिसे कोई engineer वास्तव में search कर सकता है
    • छोटा summary
    • समाधान का तरीका
    • संबंधित systems और code references
  • इन निकाली गई चीज़ों को embed करके common table में store किया जाता है; मूल conversation text को सीधे embed नहीं किया जाता
  • experiments में पाया गया कि thread को consistent format में normalize करने से accuracy काफ़ी बढ़ी, और अतिरिक्त metadata ने semantic search के लिए अधिक उपयोगी signals दिए

लंबे threads में individual messages बचाने के लिए Bursting

  • सिर्फ़ thread-level summary से लंबे conversations के महत्वपूर्ण messages छूट जाने की समस्या बनी रही
  • एक ही author के लगातार भेजे गए messages को continuous utterance group (burst) में जोड़ा गया, और thread topic को context के रूप में आगे लगाकर अलग से embed किया गया
  • इससे thread summary में शामिल न हुई side conversations के answers भी independently searchable हो गए
  • low-signal utterances डेटाबेस में न जाएँ, इसके लिए weighted signals निकाले गए और threshold पार करने वाले groups ही store किए गए
    • पूरे corpus में IDF 4.0 या उससे अधिक वाले rare tokens शामिल हों
    • combined utterance length कम से कम 200 characters हो
    • एक या अधिक messages पर reaction emoji हो ताकि social weight मिले
  • शर्तें पूरी करने वाले groups को thread-level records के साथ common embedding table में store किया गया

बड़े code repositories की incremental embeddings

  • Claude Code जैसे command-line tools के फैलने के साथ कंपनी को लगा कि code के लिए शायद grep ही काफ़ी हो, लेकिन industry लोगों की राय और Cursor के large codebase semantic search results देखने के बाद code embeddings अपनाए गए
  • कुछ internal repositories 40GB से बड़े थे, इसलिए पूरे data को लगातार फिर से embed करना एक बड़ा cost challenge था
  • कई experiments के बाद codebase vectorization के लिए optimized open source document embedding framework CocoIndex चुना गया
  • language-specific regex boundaries का इस्तेमाल बड़े units से छोटे units की ओर करते हुए code को split किया गया
    • पहले class जैसी upper boundaries इस्तेमाल की गईं
    • chunk बहुत बड़ा होने पर method और छोटे block boundaries तक उतरा गया
    • एक ही file में file-level/function-level जैसी अलग granularities की कई embeddings बन सकती हैं
  • CocoIndex, Postgres में sync metadata रखता है, इसलिए हर commit पर सिर्फ़ बदले हुए code chunks को दोबारा embed और export किया जाता है
  • repositories बढ़ने के बाद onboarding को ऐसे config files पर शिफ्ट किया गया जिन्हें teams खुद submit कर सकें, और file-path allowlists/blocklists का support जोड़ा गया

Custom data sources को जोड़ना

  • कुछ teams चाहती थीं कि वे अपने मौजूदा databases की जानकारी को Slack या document system में शिफ्ट किए बिना उसी search interface से इस्तेमाल कर सकें
  • custom sources को plugin scripts की तरह माना गया
    • teams existing system को पढ़कर common embedding table format वाली rows export करने वाला छोटा Python module pull request के रूप में submit करती हैं
    • उसके साथ संबंधित data source config भी जोड़ा जाता है
  • जैसे ही shared database में common schema के हिसाब से data लिखा जाता है, वह Slack/code/documents के साथ searchable हो जाता है; बाकी systems में अलग handling की ज़रूरत नहीं होती

Query planning और tools का parallel execution

  • हर सवाल के लिए LLM पहले एक छोटा planning step चलाता है, जिसमें तय होता है कि कौन से tools और data sources इस्तेमाल होंगे
  • मुख्य tools ये हैं
    • subsystem_index: file-by-file LLM summaries
    • search: Slack/wiki/code/other indexes को जोड़ने वाली vector search, जो भीतर merge और reranking करती है
    • search_slack: Slack direct search
    • search_code: source repositories पर ripgrep
    • recent_prs: सवाल से जुड़े recent pull requests
    • who_knows: किसी खास विषय पर वास्तविक expertise दिखाने वाले लोगों की search
  • planner projects की सूची, हर project के data sources, और हर source किन सवालों का जवाब बेहतर देता है—इन सबके compressed descriptions का इस्तेमाल करता है
  • executor चुने गए tools को parallel call करता है, results को common evidence format में normalize करता है, और फिर उन्हें final synthesis LLM को भेजता है

RRF और reranking

  • सिर्फ़ query और शब्दावली साझा करने वाले, लेकिन वास्तव में अलग सवाल का जवाब देने वाले documents ऊपर आ सकते हैं, इसलिए अलग reranking step रखा गया
  • अलग-अलग searchers की ranking lists को Reciprocal Rank Fusion (RRF) से जोड़ा गया
    • हर list में document की मौजूदगी पर weight / (60 + rank) जोड़ा जाता है
    • default weight 1.0 है और smoothing constant 60 है
    • कई searchers में लगातार ऊपर आने वाला document, सिर्फ़ एक searcher में पहले स्थान वाला document पछाड़ सकता है
  • duplicate chunks को source unit के हिसाब से मिलाया जाता है और प्रति file results की संख्या सीमित करके विविध top-20 candidates बनाए जाते हैं
  • एक छोटा reranking model मूल सवाल के आधार पर हर document को 0~10 score देता है और top 10 बचाए जाते हैं
  • final results में आसपास का context फिर से जोड़ा जाता है
    • wiki section match होने पर साथ की दो adjacent sections भी लाई जाती हैं ताकि title/prerequisites/cautions chunk split में गायब न हों
  • search result कई searchers के combination, source-level deduplication, question-based reranking और surrounding context expansion से गुज़रे evidence bundles के रूप में लौटता है

MCP और web UI के बीच भूमिका-विभाजन

  • MCP में एक ही “सवाल का जवाब दो” endpoint देने के बजाय search_slack, search_code, search, who_knows जैसी search primitives को अलग-अलग tools के रूप में expose किया गया
  • tools को तेज़ और सस्ता रखने के लिए जहाँ तक संभव हो LLM dependency हटाई गई
    • input और output की range को संकीर्ण, structured और stable रखा गया
    • vector search/lexical search/ripgrep जैसी single pipelines पर हल्के scoring rules लगाकर raw evidence rows लौटाई जाती हैं
  • Claude Code सहित MCP-compatible agents एक orchestration engine बन जाते हैं, जो तय करते हैं कि कौन सा tool कब बुलाना है और results को कैसे जोड़ना है
  • web UI में यही tools एक complete query pipeline में जोड़े जाते हैं
    • planner सवाल और active project देखकर चुनता है कि कौन से search tools call करने हैं
    • executor calls को parallel में चलाकर score/freshness/source hints सहित common evidence schema में बदलता है
    • synthesizer सवाल और evidence bundles के आधार पर citation/cautions/sources के बीच integration सहित जवाब बनाता है
  • user बस सवाल पूछता है और जवाब पाता है, लेकिन अंदर planner → executor → synthesizer flow चलता है

Project-level search scope

  • corpus बड़ा होने के साथ पूरे संगठन में हर बार search करने वाले तरीके की relevance तेज़ी से गिरने लगी
    • compiler team नहीं चाहती थी कि search results में infrastructure operations procedures आएँ, और उलटी स्थिति भी सही थी
  • projects को query execution के default workspace के रूप में लाया गया
    • खास Slack channels/code repositories/internal databases/document spaces को team या task के हिसाब से group किया गया
    • shared incident channels या central platform repository को कई projects में reference किया जा सकता है, बिना data copy किए
  • onboarding के दौरान ML training infrastructure/Compiler/Data Center Operations जैसे काम-उपयुक्त default projects चुनने या बनाने को कहा गया
  • default project को user profile में store किया गया और सभी queries का scope अपने-आप सीमित किया गया, ताकि नए engineers संबंधित channels और repositories पहले सीखे बिना भी search शुरू कर सकें

मौजूदा tools को बनाए रखने वाला knowledge base

  • knowledge base का operating principle यह है कि जानकारी को एक कठोर single system में शिफ्ट करने के बजाय वहीं से इकट्ठा किया जाए जहाँ वह पहले से बन रही है
  • कई search methods को जोड़कर evidence जल्दी खोजा जाता है, साथ ही वास्तविक enterprise data की विविधता को स्वीकार करने और संगठन के बढ़ने पर भी उपयोगी बने रहने वाली संरचना तैयार की जाती है

संबंधित पढ़ाई

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.