व्यावहारिक RAG: गूगल के ओपन नॉलेज फॉर्मेट (OKF) का परीक्षण

यदि आपने एआई एजेंटों को एक वास्तविक कोडबेस में एकीकृत किया है, तो आप शायद वेक्टर सर्च की सीमाओं से परिचित होंगे।

जब आप एक एजेंट को एक एपीआई एंडपॉइंट को रिफैक्टर करने के लिए कहते हैं, तो वह वेक्टर लुकअप के माध्यम से फ़ंक्शन बॉडी को पुनर्प्राप्त करता है। लेकिन इसमें डेटाबेस स्कीमा, प्रमाणीकरण मिडलवेयर लॉजिक और परिनियोजन रनबुक छूट जाते हैं क्योंकि वे वेक्टर स्पेस में पर्याप्त रूप से ओवरलैप नहीं थे।

एजेंट विफल हो जाता है क्योंकि यह संदर्भ के शून्य में काम कर रहा है।

इस "संदर्भ-संयोजन" समस्या को हल करने के लिए, गूगल क्लाउड ने ओपन नॉलेज फॉर्मेट (OKF) विनिर्देश प्रकाशित किया। यह एक स्वतंत्र मानक है जो टेक्स्ट फ़ाइलों की डायरेक्टरी को एक सिमेंटिक नॉलेज ग्राफ़ में बदल देता है जिसे एआई एजेंट पुनरावर्ती रूप से नेविगेट कर सकते हैं।

यहाँ इसके कार्यान्वयन पर मेरा व्यावहारिक दृष्टिकोण दिया गया है।

वास्तविक कार्यान्वयन: इस पोर्टफोलियो में OKF

केवल अवधारणा को समझाने के बजाय, मैंने इस पोर्टफोलियो के पूरे दस्तावेज़ीकरण में OKF लागू किया है। आप इस रिपॉजिटरी के /knowledge/ निर्देशिका में वास्तविक ज्ञान आधार का पता लगा सकते हैं।

OKF उस काम को औपचारिक रूप देता है जो कई प्लेटफ़ॉर्म टीमें पहले से ही कर रही थीं: आंतरिक दस्तावेज़ों को YAML फ्रंटमैटर के साथ सादे मार्कडाउन फ़ाइलों के एक स्वच्छ निर्देशिका ट्री के रूप में संरचित करना।

मालिकाना ग्राफ डेटाबेस या जटिल वेक्टर इंडेक्सिंग पाइपलाइनों को पेश करने के बजाय, OKF दो वेब मानकों पर निर्भर करता है:

1. फ़ाइल-स्तरीय मेटाडेटा के लिए YAML फ्रंटमैटर (यह घोषित करना कि फ़ाइल क्या है)।
2. फ़ाइलों के बीच संबंधों को घोषित करने के लिए मानक मार्कडाउन लिंक (एजेंट को अगले नोड पर इंगित करना)।

फ़ाइलों को सीधे टेक्स्ट के अंदर लिंक करके, आप अपनी दस्तावेज़ीकरण निर्देशिका को एक ज्ञान ग्राफ़ में बदल देते हैं। फ़ाइल का विश्लेषण करने वाला कोई भी LLM एजेंट इन लिंक्स का अनुसरण उसी तरह कर सकता है जैसे एक वेब क्रॉलर HTML एंकरों को पार करता है।

इस पोर्टफोलियो में वास्तविक कार्यान्वयन

यह पोर्टफोलियो /knowledge/ निर्देशिका में OKF को लागू करता है। यहाँ वास्तविक संरचना है:

/knowledge/
  ├── index.md                    <-- Entry point with type: "index"
  ├── architecture/
  │   └── directory-layout.md     <-- Architecture documentation
  ├── guidelines/
  │   ├── journal-publishing.md   <-- Blog publishing guidelines
  │   ├── cover-art.md            <-- Cover art guidelines
  │   └── ...                     <-- Additional guidelines

प्रत्येक फ़ाइल एक उचित OKF फ्रंटमैटर के साथ शुरू होती है। यहाँ /knowledge/index.md से वास्तविक YAML हेडर है:

---
type: "index"
title: "dds.com Codebase Knowledge Base"
description: "Entry point for Google OKF-compliant repository knowledge graph describing layout and journal workflows."
timestamp: "2026-07-06T13:10:00Z"
tags: ["OKF", "documentation", "architecture", "guidelines"]
---

सामग्री में दस्तावेज़ों के बीच स्पष्ट संबंध शामिल हैं। उदाहरण के लिए, journal-publishing.md में, आप पाएंगे:

For information on creating cover art for your posts, see the [Cover Art Guidelines](./cover-art.md). For an overview of the entire codebase architecture, refer to the [Directory Layout](../architecture/directory-layout.md).

यह एक नेविगेटेबल ग्राफ़ बनाता है जिसे मनुष्य और एआई एजेंट दोनों प्रभावी ढंग से पार कर सकते हैं।

एजेंट इस वास्तविक ग्राफ़ को कैसे पार करते हैं

पारंपरिक RAG कीवर्ड या सिमेंटिक वेक्टर की खोज करता है, शीर्ष 5 टुकड़ों को पुनः प्राप्त करता है और उन्हें प्रॉम्प्ट में डंप कर देता है।

OKF एक पारगमन RAG रणनीति को सक्षम बनाता है:

1. प्रवेश बिंदु चयन: एजेंट प्रारंभिक प्रासंगिक दस्तावेज़ (जैसे, journal-publishing.md) खोजने के लिए एक हल्का वेक्टर सर्च या कीवर्ड क्वेरी चलाता है।
2. पुनरावर्ती पार्सिंग: एजेंट दस्तावेज़ को पार्स करता है, फ़ाइल प्रकार की पहचान करने के लिए YAML हेडर पढ़ता है, और सभी सापेक्ष लिंक्स को निकालता है।
3. संदर्भ संयोजन: कार्य के आधार पर, एजेंट एक संपूर्ण संदर्भ बनाने के लिए लिंक की गई फ़ाइलों को पुनरावर्ती रूप से लोड करता है।

उदाहरण के लिए, यदि किसी एजेंट को यह समझने की आवश्यकता है कि इस पोर्टफोलियो में ब्लॉग पोस्ट को कैसे मान्य किया जाता है, तो वह:

1. journal-publishing.md से शुरू कर सकता है (खोज के माध्यम से पाया गया)
2. कोडबेस संरचना को समझने के लिए ../architecture/directory-layout.md के लिंक का अनुसरण कर सकता है
3. वास्तुकला दस्तावेज़ में सत्यापन स्क्रिप्ट की खोज कर सकता है
4. कार्यान्वयन विवरण के लिए blog-validation-tools.md जैसे संबंधित दिशानिर्देश लोड कर सकता है

यह संदर्भ विंडो ओवरफ़्लो को समाप्त करता है क्योंकि एजेंट केवल उन फ़ाइलों को खींचता है जो स्पष्ट रूप से प्रासंगिक हैं, पूरी तरह से सामान्य खोज शोर को दरकिनार करते हैं।

स्वचालित सत्यापन

यह सुनिश्चित करने के लिए कि OKF संरचना बरकरार रहे, मैंने स्वचालित सत्यापन लागू किया है:

• एक स्क्रिप्ट जांचती है कि सभी मार्कडाउन फ़ाइलों में उचित फ्रंटमैटर है
• आवश्यक फ़ील्ड (type, title, description, timestamp) को मान्य करता है
• यह सुनिश्चित करता है कि इंडेक्स फ़ाइल type: "index" के साथ मौजूद है
• बिना सापेक्ष लिंक वाली फ़ाइलों (संभावित रूप से डिस्कनेक्ट किए गए नोड्स) के बारे में चेतावनी देता है

यह सत्यापन निर्माण प्रक्रिया के दौरान स्वचालित रूप से चलता है, जिससे टूटे हुए या विकृत दस्तावेज़ीकरण को तैनात होने से रोका जा सके।

वास्तविक परिणाम: क्या OKF इसके लायक है?

इस वास्तविक कोडबेस में OKF लागू करने के बाद, वास्तविक अनुभव के आधार पर मेरा ईमानदार मूल्यांकन इस प्रकार है:

जीत:

• शून्य विक्रेता लॉक-इन: यह सिर्फ मार्कडाउन है। आप इसे VS Code में देख सकते हैं, GitHub पर होस्ट कर सकते हैं, या किसी भी LLM प्रदाता के साथ अनुक्रमित कर सकते हैं।
• गिट-संगत संस्करणन: दस्तावेज़ अपडेट मानक पुल अनुरोधों और मर्ज समीक्षाओं के माध्यम से जाते हैं।
• एजेंट स्वतंत्रता: एजेंटों को कस्टम डेटाबेस ड्राइवरों की आवश्यकता नहीं होती है; उन्हें केवल एक मार्कडाउन पार्सर की आवश्यकता होती है।
• डेवलपर अनुभव: इंजीनियर्स दस्तावेज़ों को उसी तरह नेविगेट कर सकते हैं जैसे वे कोड नेविगेट करते हैं - स्पष्ट लिंक का पालन करके।

संबोधित की गई चुनौतियाँ:

• लिंक रॉट: हमारा स्वचालित सत्यापन निर्माण प्रक्रिया के दौरान टूटे हुए लिंक्स को पकड़ता है।
• रखरखाव ओवरहेड: सत्यापन स्क्रिप्ट यह सुनिश्चित करती हैं कि नया दस्तावेज़ीकरण स्वचालित रूप से OKF सम्मेलनों का पालन करता है।

व्यावहारिक रूप से, OKF ने इस पोर्टफोलियो के दस्तावेज़ीकरण को मनुष्यों और एआई एजेंटों दोनों के लिए अधिक नेविगेटेबल बना दिया है। जब मैं कोडबेस संरचना के बारे में प्रश्न पूछता हूँ, तो एजेंट अब यह अनुमान लगाने के बजाय कि कौन से दस्तावेज़ प्रासंगिक हो सकते हैं, संपूर्ण संदर्भ बनाने के लिए स्पष्ट लिंक्स का पालन कर सकते हैं।

OKF संदर्भ संयोजन के लिए एक व्यावहारिक दृष्टिकोण है। यदि आप मतिभ्रम या अपूर्ण एजेंट संदर्भ से जूझ रहे हैं, तो अपने रिपॉजिटरी के /docs या /knowledge निर्देशिका को OKF से मेल खाने के लिए संरचित करना एक कम लागत वाला, उच्च-रिटर्न वाला वास्तुकला निर्णय है।