लेखक: @hi_im_isaac_, @learnwdaniel, @gaozenghao
नोट: पूर्ण तकनीकी ब्लॉग का इंटरैक्टिव संस्करण उपलब्ध है: https://www.cerebras.ai/blog/how-we-built-our-knowledge-base
कर्मचारी हमारे आंतरिक ज्ञानकोष से प्रतिदिन 15,000 से अधिक प्रश्न पूछते हैं। 3 महीने पहले लॉन्च होने के बाद से यह कंपनी में सबसे व्यापक रूप से अपनाए जाने वाले आंतरिक उपकरणों में से एक बन गया है। इसका उपयोग मनुष्यों, ऑटोमेशन और एजेंटों द्वारा किया जाता है।
Cerebras में, हमारी टीमें डेटा सेंटर संचालन, चिप डिज़ाइन, हार्डवेयर, प्रशिक्षण, अनुमान, क्लाउड प्लेटफ़ॉर्म, और बहुत कुछ पर काम करती हैं। हर साल सैकड़ों नए कर्मचारियों के शामिल होने के साथ, हमारे संचार चैनल एक ही प्रश्नों से भर रहे थे:
- "मुझे X कहाँ मिलेगा?"
- "Y का विशेषज्ञ कौन है?"
- "Z क्या है?"
हमने Cerebras Knowledge बनाया ताकि लोगों और सिस्टम को उपयोगी जानकारी से जोड़ा जा सके।
डेटा से वहीं मिलना जहाँ वह रहता है
किसी संगठन के अंदर जानकारी ढूँढना कठिन है। डेटा विभिन्न टूल्स में बिखरा होता है, और हर तिमाही या ऐसे ही कोई एक ही शानदार समाधान प्रस्तावित करता है: चलो सब कुछ एक प्लेटफ़ॉर्म पर रिकॉर्ड करें ताकि सारी जानकारी एक ही जगह हो। एकल सत्य स्रोत का सपना, निश्चित रूप से, व्यवहार में शायद ही काम करता है।
जानकारी वहीं उत्पन्न होती है जहाँ यह सुविधाजनक और एर्गोनोमिक है: दस्तावेज़ में सुझाए गए संपादन, Slack में थ्रेड, GitHub में कोड संदर्भ, और Jira में स्थिति मेटाडेटा। ये प्लेटफ़ॉर्म अपने विशिष्ट डोमेन के लिए तैयार किए गए हैं, वर्षों के उत्पाद इंजीनियरिंग और एनालिटिक्स के माध्यम से अनुकूलित। Google Docs में पुल रिक्वेस्ट पर चर्चा करना एक भयानक अनुभव होगा।
इसलिए हमने एक ऐसी प्रणाली डिज़ाइन करने का निर्णय लिया जिसमें मौजूदा व्यवहार में न्यूनतम बदलाव की आवश्यकता हो। डेटा संग्रह पक्ष पर, इसका मतलब था प्रत्येक प्लेटफ़ॉर्म से सीधे डेटा निकालना।
ज्ञानकोष की संरचना
हमारा ज्ञानकोष तीन चीज़ें प्रदान करता है:
- आंतरिक डेटा एकत्र करने और संग्रहीत करने के लिए एक प्लेटफ़ॉर्म।
- उस डेटा को क्वेरी करने के लिए एक प्लेटफ़ॉर्म।
- एक परत जो प्रमाणीकरण और प्राधिकरण लागू करती है, ऑडिटिंग और एनालिटिक्स के साथ।
मूल में एक एकल Postgres तालिका है जो कई स्रोतों से एम्बेडिंग्स, कच्चे सारांश और मेटाडेटा रखती है। सिस्टम लगातार कंपनी भर से डेटा इन्जेस्ट करता है और क्वेरी-तैयार डेटास्टोर बनाए रखता है।
हम एक डेटा इंटरफ़ेस चाहते थे जो सरल हो लेकिन अधिकांश प्रकार के डेटा के साथ काम कर सके। हम यह भी चाहते थे कि Cerebras के अन्य डेवलपर्स कस्टम कनेक्टर बना सकें। परिणाम जानबूझकर सरल है: प्रत्येक स्रोत, Slack थ्रेड से लेकर नेटलिस्ट तक, एक ही एम्बेडिंग तालिका में आता है, और उस तालिका में कुछ भी तुरंत उसी इंटरफ़ेस के माध्यम से क्वेरी करने योग्य है:
प्रत्येक डेटा स्रोत परिभाषित करता है कि डेटा क्या है, उससे कैसे जुड़ना है, और इसे कितनी बार लाना चाहिए। प्रत्येक परिणामी एम्बेडिंग पंक्ति एक ही इंटरफ़ेस का अनुसरण करती है, भले ही वह Slack, कोड रिपॉजिटरी, दस्तावेज़ प्रणाली, या कस्टम डेटाबेस से आई हो।
हम असंरचित Slack वार्तालापों को कैसे संसाधित करते हैं
Slack सबसे महत्वपूर्ण डेटा स्रोत था जिसे हमें डिज़ाइन करना था। यह वह जगह है जहाँ कंपनी भर में सबसे अद्यतित इंजीनियरिंग चर्चाएँ होती हैं।
हमने शुरू में परीक्षण किया कि क्या कच्चे टेक्स्ट पर सरल एम्बेडिंग्स पर्याप्त रूप से काम करती हैं। हमने जल्दी ही महसूस किया कि सभी प्रासंगिक डेटा से मेल खाने के लिए अकेले वेक्टर खोज अपर्याप्त थी।
Slack संदेश कई चुनौतियाँ प्रस्तुत करते हैं:
- सूचना घनत्व बहुत भिन्न होता है: "हाँ, हाँ, यकीनन माइक" और एक विस्तृत कर्नेल स्पष्टीकरण दोनों संदेश हैं।
- संदेश की लंबाई भिन्न होती है, और छोटे संदेश अक्सर लंबे, अधिक विस्तृत संदेशों को कोसाइन समानता में हरा देते हैं।
- एक संदेश का अर्थ अक्सर आसपास की बातचीत पर निर्भर करता है।
हमें एक संकर दृष्टिकोण की आवश्यकता थी। हमने Slack इन्जेस्टेशन इस तरह बनाया कि प्रत्येक थ्रेड एक साथ कई खोज तकनीकों के माध्यम से पुनर्प्राप्त करने योग्य हो, जहाँ प्रत्येक तकनीक दूसरों की कमजोरियों की भरपाई करती है:
- पूर्ण-पाठ खोज उन सटीक टोकन को पकड़ती है जिन्हें एम्बेडिंग्स धुंधला कर देती हैं: त्रुटि स्ट्रिंग्स, फ़्लैग नाम, होस्ट नाम। जब कोई इंजीनियर एक शाब्दिक त्रुटि संदेश पेस्ट करता है, तो एक सटीक शाब्दिक मिलान लगभग हमेशा सबसे अच्छा सबूत होता है, और कोई भी अर्थ संबंधी समानता उसे पछाड़ नहीं सकती।
- एम्बेडिंग खोज परिभाषा को पकड़ती है। जो व्यक्ति "मेनिफेस्ट लोड के बाद रिस्टोर हैंग हो जाता है" पूछता है और जिसने "NFS माउंट पर चेकपॉइंट रुक जाता है" उत्तर दिया, वे कभी शब्दावली साझा नहीं कर सकते। वेक्टर समानता ही एक प्रश्न को अलग शब्दों में लिखे गए उत्तर से जोड़ती है।(1)
- व्युत्क्रम दस्तावेज़ आवृत्ति सिग्नल को फिलर से अलग करती है। एक छोटा संदेश जो दुर्लभ टोकन के आसपास बना है, जैसे एक अस्पष्ट कॉन्फ़िग फ़्लैग, रैंक करने योग्य है। "बहुत अच्छा, धन्यवाद!" एम्बेडिंग स्पेस में कई प्रश्नों के करीब बैठता है लेकिन एक बार टर्म दुर्लभता को ध्यान में रखने पर लगभग शून्य स्कोर करता है।
- आयु क्षय यह बताता है कि Slack उत्तर समाप्त हो जाते हैं। दो थ्रेड एक ही प्रश्न का उत्तर दे सकते हैं, और छह महीने पहले वाला उस बुनियादी ढांचे का वर्णन कर सकता है जो अब मौजूद नहीं है। जब प्रासंगिकता अन्यथा समान हो, तो नया थ्रेड जीतता है।
कोई भी एकल स्कोरर अपने आप पर भरोसेमंद नहीं है। प्रत्येक तकनीक एक ही कॉर्पस का अपना रैंक किया गया दृश्य उत्पन्न करती है, और उन दृश्यों को क्वेरी समय पर फ्यूज़ किया जाता है (पुनःरैंकिंग देखें)।
सॉकेट मोड
रीयल-टाइम में डेटा एकत्र करने के लिए, हमने अपने वर्कस्पेस में एक Slack बॉट स्थापित किया और इसे सॉकेट मोड में चलाया। Slack हर संदेश ईवेंट को एक स्थायी WebSocket पर हमारे पास धकेलता है, इसलिए हमें Web API को पोल किए बिना और उसकी दर सीमाओं को जलाए बिना रीयल-टाइम अपडेट मिलते हैं।
जब कोई ईवेंट आता है, तो हम तुरंत उसे स्वीकार करते हैं, स्थिर ईवेंट ID का उपयोग करके डुप्लिकेट हटाते हैं, और संदेश को इन्जेस्ट उपभोक्ता के लिए चिह्नित करते हैं।
इन्जेस्ट उपभोक्ता एक नए संदेश को अलगाव में नहीं सहेजता है। यह उस थ्रेड को हल करता है जिससे संदेश संबंधित है और Slack API से पूरी बातचीत, जिसमें मूल और हर उत्तर शामिल है, फिर से लाता है। फिर यह पूरे थ्रेड को एक पंक्ति के रूप में वापस लिखता है। मौजूदा थ्रेड के उत्तर में, इसलिए मूल और सभी सहोदर को फिर से खींचता है, ताकि संग्रहीत सामग्री, प्रतिभागी सूची, और अंतिम गतिविधि टाइमस्टैम्प हमेशा पूर्ण बातचीत को दर्शाते हैं।
हमारे सिस्टम में प्रत्येक Slack चैनल का अपना डेटा स्रोत है। यह डेटा ताजगी के लिए सूक्ष्म-ट्यूनिंग प्रदान करता है। एक टीम, उदाहरण के लिए, एक व्यस्त घटना चैनल को अधिक बार इन्जेस्ट करने का विकल्प चुन सकती है।
थ्रेड और संदेश
कच्चा Slack टेक्स्ट लैंड करते ही कीवर्ड-खोज योग्य होता है क्योंकि हम कच्ची सामग्री पर एक Postgres पूर्ण-पाठ (GIN) इंडेक्स बनाए रखते हैं। हालाँकि, उपयोगी वेक्टर खोज को सक्षम करने के लिए, हम कुछ अतिरिक्त प्रसंस्करण करते हैं।(8)
आसवन के दौरान, एक LLM पूरे थ्रेड से संरचित डेटा निकालता है:
- एक पंक्ति का प्रश्न जो एक इंजीनियर वास्तव में खोजेगा।
- एक छोटा सारांश।
- समाधान।
- उल्लिखित सिस्टम और कोड संदर्भ।
हम इन डेटा बिंदुओं को एम्बेड करते हैं और उन्हें साझा एम्बेडिंग तालिका में लिखते हैं। मूल ट्रांसक्रिप्ट को सीधे एम्बेड नहीं किया जाता है। हमारे प्रयोगों में, जब थ्रेड को एक सुसंगत प्रारूप में सामान्यीकृत किया गया, तो सटीकता में काफी वृद्धि हुई।(7,9) अतिरिक्त मेटाडेटा अर्थ संबंधी मिलान को अधिक उपयोगी सिग्नल भी देता है।
बर्स्टिंग
इस बिंदु पर Slack खोज अच्छी थी, लेकिन हमें एक ही समस्या का सामना करना पड़ता रहा: लंबे थ्रेड के अंदर महत्वपूर्ण संदेश हमेशा थ्रेड-स्तरीय सारांश में प्रस्तुत नहीं होते थे।
व्यक्तिगत संदेशों से सिग्नल बढ़ाने के लिए, हम बर्स्टिंग का उपयोग करते हैं। एक बर्स्ट एक ही लेखक से लगातार संदेशों का एक रन है। हम थ्रेड विषय को संदर्भ के रूप में जोड़कर व्यक्तिगत बर्स्ट को एम्बेड करते हैं(2) क्योंकि कभी-कभी उत्तर एक टैंगेंट संदेश में रहता है जिसकी शब्दावली कभी थ्रेड सारांश में नहीं आती। बर्स्ट एम्बेडिंग्स उस संदेश को अपने आप खोजने योग्य बनाती हैं।
कम-सिग्नल डेटा को डेटाबेस तक पहुँचने से रोकने के लिए, प्रत्येक बर्स्ट को सिग्नलों के भारित संयोजन के विरुद्ध स्कोर किया जाता है और एम्बेड होने से पहले एक सीमा को पार करना होता है:
- इसमें कॉर्पस में अपेक्षाकृत दुर्लभ टोकन होता है, जिसमें कम से कम 4.0 का IDF होता है।
- संयुक्त बर्स्ट कम से कम 200 वर्णों का होता है।
- बर्स्ट में एक या अधिक संदेशों में प्रतिक्रियाएँ होती हैं, जो एक सामाजिक बढ़ावा प्रदान करती हैं।
आसवन के बाद, योग्य बर्स्ट एम्बेड किए जाते हैं और थ्रेड-स्तरीय रिकॉर्ड के साथ एम्बेडिंग तालिका में संग्रहीत किए जाते हैं।
कोड रिपॉजिटरी
शुरू में हमने बहस की कि क्या कोड रिपॉजिटरी को एम्बेड करना आवश्यक है। Claude Code और अन्य कमांड-लाइन टूल के उदय के साथ, कोड एम्बेडिंग बनाना प्रतिकूल लग रहा था जब ऐसा लगता था कि "grep ही सब कुछ है।" उद्योग में दूसरों से बात करने और बड़े कोडबेस में अर्थ संबंधी खोज पर Cursor के निष्कर्षों को पढ़ने के बाद, हमने प्रयास करने का निर्णय लिया।
हमारे पास कई आंतरिक रिपॉजिटरी हैं, कुछ 40 GB से बड़ी। हमारी मुख्य चिंता यह थी कि उन्हें कुशलतापूर्वक अद्यतित कैसे रखा जाए।
[@cocoindex_io](https://x.com/@cocoindex_io) का उपयोग करके कोड एम्बेडिंग बनाए रखना
कई प्रयोगों के बाद, हम CocoIndex पर पहुँचे, एक ओपन-सोर्स दस्तावेज़ एम्बेडिंग फ्रेमवर्क जो कोडबेस को वेक्टराइज़ करने में माहिर है।
प्रत्येक रिपॉजिटरी के लिए, हम भाषा-विशिष्ट regex सीमाओं का उपयोग करके कोड को मोटे से बारीक क्रम में विभाजित करते हैं। स्प्लिटर पहले उच्च-स्तरीय सीमाओं, जैसे क्लास, का प्रयास करता है। यदि परिणामी टुकड़ा अभी भी बहुत बड़ा है, तो यह विधि सीमाओं और फिर छोटे ब्लॉकों पर वापस आ जाता है। हम परिणामी टुकड़ों को एम्बेड करते हैं और वैक्टर को Postgres में लिखते हैं। एक फ़ाइल विशिष्टता के विभिन्न स्तरों पर कई एम्बेडिंग उत्पन्न कर सकती है, जैसे फ़ाइल-स्तर और फ़ंक्शन-स्तर रिकॉर्ड।
CocoIndex Postgres में सिंक्रोनाइज़ेशन मेटाडेटा को ट्रैक करता है। प्रत्येक कमिट पर, यह पूरे रिपॉजिटरी की पुनर्गणना करने के बजाय केवल बदले हुए कोड टुकड़ों को फिर से एम्बेड करता है और पुनः निर्यात करता है। यह हमारे लिए विशेष रूप से अच्छा काम करता है क्योंकि सिंक्रोनाइज़ेशन स्थिति और एम्बेडिंग स्टोर एक ही डेटाबेस में रहते हैं।
जैसे-जैसे कोडबेस की संख्या बढ़ी, हमने रिपॉजिटरी ऑनबोर्डिंग को कॉन्फ़िगरेशन फ़ाइलों में स्थानांतरित कर दिया जिसे टीमें स्वयं सबमिट कर सकती हैं, जिसमें फ़ाइल-पथ स्तर पर अनुमति सूची और अस्वीकृति सूची शामिल है।
कस्टम डेटा स्रोत
कुछ टीमों के पास पहले से ही अपने डेटाबेस थे और वे ज्ञानकोष में भाग लेने के लिए Slack या दस्तावेज़ प्रणाली में डेटा स्थानांतरित नहीं करना चाहते थे। वे अपनी मौजूदा तालिकाओं पर समान क्वेरी सतह चाहते थे।
इसे समर्थन देने के लिए, हम कस्टम स्रोतों को प्लगइन स्क्रिप्ट के रूप में मानते हैं। एक टीम एक छोटे Python मॉड्यूल के साथ पुल रिक्वेस्ट खोलती है जो अपने सिस्टम से पढ़ना और हमारी एम्बेडिंग तालिका के आकार की पंक्तियों को उत्सर्जित करना जानता है, साथ ही एक मिलता-जुलता डेटा स्रोत प्रविष्टि।
जब तक स्क्रिप्ट उसी स्कीमा का उपयोग करके साझा डेटाबेस में लिखती है जैसे हर दूसरी एम्बेडिंग पंक्ति, बाकी स्टैक अपरिवर्तित काम करता है। डेटा Slack, कोड और दस्तावेज़ों के साथ-साथ क्वेरी करने योग्य हो जाता है, सिस्टम में कहीं और विशेष हैंडलिंग की आवश्यकता नहीं होती।
योजना और टूल फैन-आउट
प्रत्येक क्वेरी के लिए, हम पहले एक छोटा योजना पास चलाते हैं जहाँ एक LLM तय करता है कि कौन से टूल और डेटा स्रोत महत्वपूर्ण होने की संभावना है। मुख्य टूल:
- subsystem_index: प्रति-फ़ाइल LLM सारांश।
- search: Slack, विकी, कोड, और अन्य अनुक्रमित स्रोतों पर एकीकृत वेक्टर पाइपलाइन, आंतरिक रूप से मर्ज और पुनःरैंक की गई।
- search_slack: सीधा Slack पुनर्प्राप्ति।
- search_code: स्रोत रिपॉजिटरी पर ripgrep।
- recent_prs: प्रश्न से संबंधित हालिया पुल रिक्वेस्ट।
- who_knows: किसी विषय पर प्रदर्शित विशेषज्ञता वाले लोग।
योजनाकार हमारे द्वारा अनुक्रमित की गई चीज़ों के संक्षिप्त विवरण पर काम करता है: कौन सी परियोजनाएँ मौजूद हैं, प्रत्येक परियोजना में कौन से स्रोत उपलब्ध हैं, और प्रत्येक स्रोत किस उत्तर देने में अच्छा है। उपयोगकर्ता की क्वेरी और सक्रिय दायरे को देखते हुए, यह टूल चयन उत्सर्जित करता है जिसे निष्पादक समानांतर में फैन आउट करता है, एक सामान्य साक्ष्य प्रारूप में सामान्यीकृत करता है, और अंतिम संश्लेषण LLM को पास करता है।(4)
पुनःरैंकिंग
एक दस्तावेज़ शीर्ष के पास सतह पर आ सकता है सिर्फ इसलिए कि वह क्वेरी के साथ शब्दावली साझा करता है जबकि एक अलग प्रश्न का उत्तर देता है। पुनःरैंकिंग से पहले, हम पुनर्प्राप्तिकर्ताओं की असंगत परिणाम सूचियों को पारस्परिक रैंक फ्यूजन (RRF) के साथ जोड़ते हैं। प्रत्येक दस्तावेज़ के लिए, हम प्रत्येक सूची में उसकी उपस्थिति के लिए weight / (60 + rank) जोड़ते हैं, जिसमें डिफ़ॉल्ट वजन 1.0 और स्मूथिंग स्थिरांक 60 है।
स्मूथिंग स्थिरांक सर्वसम्मति को एकल मजबूत वोट से अधिक महत्वपूर्ण बनाता है: एक दस्तावेज़ जो कई पुनर्प्राप्तिकर्ताओं में शीर्ष के पास दिखाई देता है, वह उस दस्तावेज़ को हरा सकता है जो केवल एक में प्रथम स्थान पर है। फिर हम डुप्लिकेट टुकड़ों को वापस एक स्रोत में मर्ज करते हैं, सीमित करते हैं कि प्रत्येक फ़ाइल कितने परिणामों में योगदान कर सकती है, और अधिक विविध शीर्ष बीस के साथ समाप्त होते हैं।
हम मूल क्वेरी और उन उम्मीदवारों को एक छोटे पुनःरैंकर मॉडल को भेजते हैं। यह प्रत्येक दस्तावेज़ को शून्य से दस तक स्कोर देता है, और हम शीर्ष दस रखते हैं।(6)
एक बार रैंकिंग अंतिम हो जाने के बाद, हम विजेताओं में संदर्भ वापस जोड़ते हैं। उदाहरण के लिए, यदि हम एक विकी अनुभाग से मेल खाते हैं, तो हम दो पड़ोसी अनुभागों को खींचते हैं ताकि शीर्षक, पूर्व शर्त और चेतावनियाँ जो चंकिंग ने अलग कर दी थीं, खो न जाएँ। यह पाठकों को एक अकेला पैराग्राफ देने के बजाय एक पूर्ण स्निपेट देता है जो महत्वपूर्ण संदर्भ से रहित है।
तो खोज का आउटपुट साक्ष्य का एक समृद्ध पैकेट है: विभिन्न पुनर्प्राप्तिकर्ताओं से फ्यूज़ किए गए परिणाम, स्रोत स्तर पर डुप्लिकेट हटाए गए, वास्तविक प्रश्न के विरुद्ध पुनःरैंक किए गए, और उसके बाद ही आसपास के संदर्भ के साथ विस्तारित किए गए।
MCP
MCP एकीकरण में, हम पुनर्प्राप्ति बिल्डिंग ब्लॉक्स को सीधे उपकरणों के रूप में उजागर करते हैं, बजाय उन्हें एक "इस प्रश्न का उत्तर दें" एंडपॉइंट के पीछे छिपाने के। ये उपकरण जानबूझकर सरल और जितना संभव हो LLM-मुक्त हैं ताकि ग्राहक उन्हें जल्दी और सस्ते में क्वेरी कर सकें।(5)
प्रत्येक MCP उपकरण एक अंतर्निहित पुनर्प्राप्ति प्राइमिटिव से मेल खाता है, जैसे search_slack, search_code, search, या who_knows। उपकरण इनपुट और आउटपुट संकीर्ण, संरचित और स्थिर हैं, जिससे उन्हें किसी भी क्लाइंट या एजेंट से कॉल करना आसान हो जाता है, बिना उपकरण के अंदर अतिरिक्त ऑर्केस्ट्रेशन तर्क को एम्बेड किए।
अधिकांश उपकरण एक क्वेरी पाइपलाइन चलाते हैं, जैसे वेक्टर खोज, शाब्दिक खोज, या ripgrep, हल्के स्कोरिंग ह्यूरिस्टिक्स लागू करते हैं, और कच्ची साक्ष्य पंक्तियाँ लौटाते हैं।
Claude Code, या कोई भी MCP-संगत एजेंट, ऑर्केस्ट्रेशन इंजन बन जाता है। यह तय करता है कि किन उपकरणों को कॉल करना है, किस क्रम में, और अंतिम उत्तर या कोड संपादन में परिणामों को कैसे इकट्ठा करना है। पुनर्प्राप्ति परत स्वयं अनुरोधों को पूरा करने के लिए उन LLM निर्णयों पर निर्भर नहीं करती है।
वेब UI
वेब UI में, वही उपकरण मौजूद हैं, लेकिन वे एक पूर्ण क्वेरी पाइपलाइन से जुड़े हुए हैं जो प्रत्येक उपयोगकर्ता प्रश्न के लिए अंत से अंत तक चलती है। UI एजेंट योजनाकार और निष्पादक चरणों का मालिक है।
- योजनाकार: एक हल्का LLM पास क्वेरी और सक्रिय प्रोजेक्ट का निरीक्षण करता है, फिर चुनता है कि कौन से पुनर्प्राप्ति उपकरणों को लागू करना है, जैसे search, search_slack, और subsystem_index।
- निष्पादक: सिस्टम उन टूल कॉल को समानांतर में फैन आउट करता है, परिणाम एकत्र करता है, और उन्हें स्कोर, हाल की तारीख और स्रोत संकेतों के साथ एक साझा साक्ष्य स्कीमा में सामान्यीकृत करता है।
- संश्लेषण: एक अंतिम LLM पास टाइप किए गए साक्ष्य बंडल और मूल प्रश्न लेता है, फिर UI में दिखाए गए उत्तर का उत्पादन करता है, जिसमें उद्धरण, चेतावनियाँ और क्रॉस-स्रोत संश्लेषण शामिल है।
उपयोगकर्ता के दृष्टिकोण से, वेब UI बस "एक प्रश्न पूछें और उत्तर प्राप्त करें" है। हुड के नीचे, यह वही योजनाकार → निष्पादक → संश्लेषक पैटर्न चलाता है जिसे MCP क्लाइंट स्पष्ट रूप से फिर से बना सकते हैं।
संगठन
जैसे-जैसे कॉर्पस बढ़ता गया, "हर जगह सब कुछ खोजें" तेजी से बेकार हो गया। कंपाइलर टीमों पर इंजीनियर अपने परिणामों में बुनियादी ढांचा रनबुक नहीं चाहते थे, और इसके विपरीत। प्रोजेक्ट वह तरीका है जिससे हम डिफ़ॉल्ट रूप से खोज को प्रासंगिक बनाते हैं।
प्रोजेक्ट और स्कोप्ड सर्च
हमने प्रोजेक्ट को वर्कस्पेस को व्यवस्थित करने के प्राथमिक तरीके के रूप में पेश किया, जिस पर एक क्वेरी चलती है। एक प्रोजेक्ट डेटा स्रोतों का एक नामित बंडल है: विशिष्ट Slack चैनल, कोड रिपॉजिटरी, आंतरिक डेटाबेस, और एक टीम या पहल के लिए प्रासंगिक दस्तावेज़ स्थान।
प्रोजेक्ट जानबूझकर हल्के होते हैं। एक ही डेटा स्रोत, जैसे साझा घटना चैनल या केंद्रीय प्लेटफ़ॉर्म रिपॉजिटरी, को डुप्लिकेट करने के बजाय कई प्रोजेक्ट द्वारा संदर्भित किया जा सकता है।
ऑनबोर्डिंग और डिफ़ॉल्ट
ऑनबोर्डिंग के दौरान, उपयोगकर्ताओं को एक डिफ़ॉल्ट प्रोजेक्ट चुनने या बनाने का संकेत दिया जाता है जो उनके काम करने के तरीके से मेल खाता है, जैसे ML प्रशिक्षण बुनियादी ढांचा, कंपाइलर, या डेटा सेंटर संचालन।
वह डिफ़ॉल्ट प्रोजेक्ट उपयोगकर्ता प्रोफ़ाइल पर संग्रहीत होता है और स्वचालित रूप से क्वेरी को स्कोप करता है। एक नया इंजीनियर पहले यह जाने बिना कि कौन से Slack चैनल, रिपॉजिटरी या दस्तावेज़ स्थान महत्वपूर्ण हैं, उच्च-सिग्नल उत्तर प्राप्त करता है।
अंतिम विचार
अंत में, ज्ञानकोष इसलिए काम करता है क्योंकि यह लोगों से वहीं मिलता है जहाँ जानकारी पहले से रहती है, बजाय सब कुछ एक कठोर प्रणाली में डालने के। विभिन्न खोज तकनीकों को मिलाकर, हम जल्दी से साक्ष्य सतह पर ला सकते हैं। परिणाम एक खोज अनुभव है जो वास्तविक कंपनी डेटा के लिए पर्याप्त लचीला रहता है, लेकिन Cerebras के बढ़ते रहने पर उपयोगी बने रहने के लिए पर्याप्त संरचित है।
यदि आपने इतना पढ़ा है और यह आपको दिलचस्प लगता है, तो ai/growth टीम भर्ती कर रही है - यदि आप रुचि रखते हैं तो @learnwdaniel से संपर्क करें।
संदर्भ
- माल्कोव और यशुनिन, कुशल और मजबूत अनुमानित निकटतम पड़ोसी खोज पदानुक्रमित नेविगेबल छोटे विश्व ग्राफ का उपयोग करके, arXiv:1603.09320 / IEEE TPAMI 2018.
- एंथ्रोपिक, प्रासंगिक पुनर्प्राप्ति का परिचय, 2024.
- कॉर्मैक, क्लार्क और बुट्चर, पारस्परिक रैंक फ्यूज़न कॉन्डोर्सेट और व्यक्तिगत रैंक लर्निंग विधियों से बेहतर प्रदर्शन करता है, SIGIR 2009.
- ली एट अल., Search-o1: एजेंटिक खोज-संवर्धित बड़े तर्क मॉडल, arXiv:2501.05366, 2025.
- एंथ्रोपिक, MCP के साथ कोड निष्पादन, 2025.
- लियू एट अल., बीच में खोया: भाषा मॉडल लंबे संदर्भों का उपयोग कैसे करते हैं, arXiv:2307.03172, 2023.
- एंथ्रोपिक, XML टैग का उपयोग करें.
- सेल्सफोर्स/स्लैक इंजीनियरिंग, कैसे स्लैक AI अरबों संदेशों को प्रोसेस करता है.
- इम्प्रूविंग एजेंट्स, सर्वश्रेष्ठ नेस्टेड डेटा प्रारूप.
