वैज्ञानिक बुद्धिमत्ता परत

lean-ctx पैटर्न मिलान से आगे जाता है। सूचना सिद्धांत, ग्राफ़ सिद्धांत और सांख्यिकीय यांत्रिकी के छह एल्गोरिदम मिलकर तय करते हैं कि क्या रखना है, क्या हटाना है, और कहाँ रखना है - सब स्वचालित, सब स्थानीय, शून्य कॉन्फ़िगरेशन।

ये एल्गोरिदम स्वायत्त बुद्धिमत्ता परत को शक्ति प्रदान करते हैं। वे हर ctx_read, ctx_preload, और ctx_overview कॉल के दौरान सक्रिय होते हैं - आप उन्हें कभी सीधे नहीं बुलाते।

परतें कैसे इंटरैक्ट करती हैं

भविष्यसूचक आश्चर्य स्कोरिंग

पारंपरिक कम्प्रेशन फ़िल्टर कच्चे अक्षरों पर Shannon एन्ट्रॉपी का उपयोग करते हैं, जो aaaa और import को समान रूप से पूर्वानुमेय मानता है। भविष्यसूचक आश्चर्य इसके बजाय BPE टोकन आवृत्ति के विरुद्ध क्रॉस-एन्ट्रॉपी मापता है - प्रत्येक पंक्ति LLM के टोकनाइज़र के लिए कितनी आश्चर्यजनक है।

यह कैसे काम करता है

1. प्रत्येक पंक्ति को o200k_base (GPT-4o / Claude टोकनाइज़र) का उपयोग करके टोकनाइज़ किया जाता है।
2. प्रत्येक टोकन के लिए, एक Zipfian पूर्व अनुमान रैंक के आधार पर अपेक्षित आवृत्ति अनुमानित करता है।
3. क्रॉस-एन्ट्रॉपी की गणना की जाती है: सामान्य टोकन (बॉयलरप्लेट) वाली पंक्तियाँ कम स्कोर करती हैं; दुर्लभ टोकन (जटिल तर्क) वाली पंक्तियाँ उच्च स्कोर करती हैं।
4. आश्चर्य थ्रेशोल्ड से नीचे की पंक्तियाँ आक्रामक कम्प्रेशन के दौरान हटाने की उम्मीदवार हैं।

उदाहरण

// Low surprise (boilerplate) - candidate for removal:
return Ok(());                    // surprise: 0.12
use std::collections::HashMap;   // surprise: 0.18

// High surprise (unique logic) - always preserved:
let decay = (-alpha * dist as f64).exp();   // surprise: 0.89
scores[j] += heat[i] * decay / degree;      // surprise: 0.94

यह क्यों मायने रखता है

भविष्यसूचक आश्चर्य जटिल तर्क संरक्षित करते हुए अक्षर-स्तरीय एन्ट्रॉपी से 15–30% अधिक बॉयलरप्लेट हटाता है। यह सीधे मॉडल करता है कि LLM क्या "सूचनात्मक" मानता है क्योंकि यह समान BPE शब्दावली का उपयोग करता है।

Spectral प्रासंगिकता प्रसार

जब आप lean-ctx से किसी कार्य के लिए संदर्भ प्रीलोड करने को कहते हैं, तो इसे तय करना होता है कि कौन सी फ़ाइलें मायने रखती हैं। सरल कीवर्ड मिलान केवल ऐसी फ़ाइलें खोजता है जो आपके खोज शब्दों का उल्लेख करती हैं। Spectral Relevance ऐसी फ़ाइलें खोजता है जो प्रासंगिक फ़ाइलों से संरचनात्मक रूप से जुड़ी हैं - भले ही वे कोई कीवर्ड साझा न करें।

यह कैसे काम करता है

प्रोजेक्ट के डिपेंडेंसी ग्राफ़ पर दो ग्राफ़ एल्गोरिदम चलते हैं:

1. हीट डिफ़्यूज़न - कार्य विवरण से मेल खाने वाली सीड फ़ाइलों को प्रारंभिक "हीट" प्राप्त होती है। हीट घातांकीय क्षय के साथ इम्पोर्ट किनारों के साथ फैलती है, कोडबेस के माध्यम से सूचना प्रवाह का अनुकरण करती है।
2. PageRank केंद्रीयता - कई अन्य फ़ाइलों द्वारा इम्पोर्ट की जाने वाली फ़ाइलें उच्च केंद्रीयता स्कोर प्राप्त करती हैं। यह संरचनात्मक हब की पहचान करता है (जैसे, 20 मॉड्यूल द्वारा इम्पोर्ट किया गया db.ts)।

अंतिम प्रासंगिकता स्कोर दोनों को जोड़ता है: 0.7 × heat + 0.3 × pagerank। थ्रेशोल्ड से नीचे की फ़ाइलें प्रीलोडिंग से बाहर रखी जाती हैं।

उदाहरण

Task: "fix authentication bug"

Direct matches:       auth.ts, login.ts
Heat diffusion adds:  middleware.ts (imports auth.ts)
                      session.ts (imported by auth.ts)
PageRank promotes:    db.ts (imported by 18 files - structural hub)

Result: 5 files preloaded instead of 2, covering the full blast radius.

शून्य कॉन्फ़िगरेशन

डिपेंडेंसी ग्राफ़ पहले उपयोग पर load_or_build() के माध्यम से स्वचालित रूप से बनता है। कोई ctx_graph build आवश्यक नहीं - यह बस काम करता है।

Boltzmann कॉन्टेक्स्ट आवंटन

एक बार Spectral Relevance प्रासंगिक फ़ाइलें चुन लेता है, प्रत्येक फ़ाइल को टोकन बजट की आवश्यकता होती है। भोले दृष्टिकोण समान बजट देते हैं या प्रासंगिकता के अनुसार क्रमबद्ध करते हैं। Boltzmann Allocation टोकन को इष्टतम रूप से वितरित करने के लिए सांख्यिकीय यांत्रिकी का उपयोग करता है।

यह कैसे काम करता है

1. प्रत्येक फ़ाइल का Spectral Relevance से एक प्रासंगिकता स्कोर E_i है।
2. एक तापमान पैरामीटर β कार्य से प्राप्त होता है: विशिष्ट कार्य ("login.ts में auth बग ठीक करें") कम तापमान (शीर्ष फ़ाइलों को तीव्र आवंटन) उत्पन्न करते हैं; व्यापक कार्य ("कोडबेस रीफ़ैक्टर करें") उच्च तापमान (समान वितरण) उत्पन्न करते हैं।
3. टोकन बजट Boltzmann वितरण का अनुसरण करते हैं: budgeti = total × (eβ·Ei / Σ eβ·Ej)
4. न्यूनतम और अधिकतम बजट लागू किए जाते हैं (128–4096 टोकन प्रति फ़ाइल), और कम्प्रेशन मोड (full, map, signatures) आवंटित बजट के आधार पर चुना जाता है।

उदाहरण

Task: "fix the JWT validation in auth middleware"
Task specificity: 0.85 (specific) → β = 4.2

File            | Relevance | Budget | Mode
auth.ts         |      0.92 |  3,200 | full
middleware.ts   |      0.78 |  1,800 | full
session.ts      |      0.45 |    420 | map
db.ts           |      0.31 |    180 | signatures
routes.ts       |      0.22 |    128 | signatures
                                ─────
Total:                         5,728 tokens (within 8,000 budget)

Reciprocal Rank Fusion (RRF) Cache Eviction

lean-ctx uses Reciprocal Rank Fusion for cache eviction decisions, replacing the earlier Boltzmann-inspired weighted scoring. RRF handles incomparable signals (time in seconds, frequency as counts, size in tokens) without arbitrary weight tuning.

Formula: RRF(d) = Σ 1/(K + ranki(d)) - entries with the lowest fused score are evicted first. This produces monotonically correct ordering regardless of signal magnitude differences.

अटेंशन ब्रिज के साथ सिमेंटिक चंकिंग

LLM "मध्य में खोया" समस्या से पीड़ित हैं: संदर्भ की शुरुआत और अंत में जानकारी को मध्य सामग्री की तुलना में अधिक ध्यान मिलता है। Semantic Chunking सूचना हानि को न्यूनतम करने के लिए आउटपुट को पुनर्गठित करता है।

यह कैसे काम करता है

1. चंक डिटेक्शन - स्रोत पंक्तियों को AST सीमा अनुमानी विधि के आधार पर सिमेंटिक चंक (फ़ंक्शन, टाइप, इम्पोर्ट, लूज़ लॉजिक) में समूहीकृत किया जाता है।
2. प्रासंगिकता क्रम - वर्तमान कार्य से मेल खाने वाले चंक को शीर्ष (उच्च-अटेंशन स्थिति) पर प्रमोट किया जाता है। शेष चंक टाइप प्राथमिकता के अनुसार क्रमबद्ध किए जाते हैं।
3. अटेंशन ब्रिज - चंक के बीच, lean-ctx न्यूनतम ब्रिज मार्कर (---) डालता है ताकि LLM संरचनात्मक सीमाओं को पहचान सके।
4. टेल एंकर - सबसे उच्च-प्राथमिकता चंक की अंतिम 2–3 पंक्तियाँ आउटपुट के बिल्कुल अंत में दोहराई जाती हैं, महत्वपूर्ण जानकारी के लिए हालिया पूर्वाग्रह का लाभ उठाते हुए।

उदाहरण

// Without chunking (flat output):
import { db } from '../pages/docs/db';
import { hash } from '../pages/docs/crypto';
const MAX_RETRIES = 3;
export function createUser(...) { ... }
export function validateToken(...) { ... }    ← lost in the middle
export function deleteUser(...) { ... }

// With semantic chunking (task: "fix token validation"):
export function validateToken(...) { ... }    ← promoted to top
---
export function createUser(...) { ... }
export function deleteUser(...) { ... }
---
import { db } from '../pages/docs/db';
const MAX_RETRIES = 3;
---
// anchor: validateToken signature                ← tail anchor

MMR डीडुप्लिकेशन

जब एकाधिक फ़ाइलें संदर्भ में लोड की जाती हैं, उनमें अक्सर डुप्लिकेट इम्पोर्ट, साझा बॉयलरप्लेट या बहुत समान कोड पैटर्न होते हैं। Maximum Marginal Relevance (MMR) अद्वितीय जानकारी संरक्षित करते हुए इस अनावश्यकता को हटाता है।

यह कैसे काम करता है

1. प्रत्येक पंक्ति के लिए, सभी पहले चयनित पंक्तियों ("कवरेज सेट") के विरुद्ध बाइग्राम Jaccard समानता की गणना करें।
2. MMR स्कोर प्रासंगिकता और अनावश्यकता को संतुलित करता है: MMR(l) = λ × relevance(l) - (1 - λ) × max_similarity(l, selected)
3. MMR < 0 वाली पंक्तियों को दबाया जाता है - वे जानकारी से अधिक अनावश्यकता जोड़ती हैं। λ पैरामीटर 0.7 पर डिफ़ॉल्ट है (विविधता से अधिक प्रासंगिकता को प्राथमिकता)।

प्रभाव

एक सामान्य मल्टी-फ़ाइल प्रीलोड में, MMR 10–25% अनावश्यक सामग्री हटाता है - मुख्य रूप से साझा इम्पोर्ट और दोहराए गए यूटिलिटी पैटर्न।

BPE-संरेखित टोकन अनुकूलन

सभी सामग्री चयनित और क्रमबद्ध होने के बाद, एक अंतिम पास LLM के BPE टोकनाइज़र के लिए कच्चे पाठ को अनुकूलित करता है। छोटे फ़ॉर्मेटिंग परिवर्तन शब्दार्थ बदले बिना टोकन गणना को काफ़ी कम कर सकते हैं।

अनुकूलन नियम

यह कैसे काम करता है

प्रत्येक नियम अन्य सभी कम्प्रेशन चरणों के बाद पंक्ति-दर-पंक्ति लागू किया जाने वाला एक सरल स्ट्रिंग प्रतिस्थापन है। नियम BPE टोकन सीमा विश्लेषण से प्राप्त होते हैं - वे उन पैटर्न को लक्षित करते हैं जहाँ टोकनाइज़र शब्दार्थ रूप से समकक्ष पाठ के लिए अनावश्यक रूप से कई टोकन उत्पन्न करता है।

प्रभाव

BPE अनुकूलन आमतौर पर पहले से संपीड़ित आउटपुट पर 3–8% अतिरिक्त टोकन बचाता है। बचत फ़ाइलों में जमा होती है और वर्बोज़ भाषाओं (TypeScript, Java, C#) के लिए सबसे महत्वपूर्ण है।

प्रभाव सत्यापित करना

सभी छह एल्गोरिदम के संयुक्त प्रभाव को मापने के लिए अपने प्रोजेक्ट में lean-ctx benchmark run चलाएँ। बेंचमार्क रिपोर्ट प्रति-फ़ाइल टोकन बचत, संरक्षण स्कोर (AST, पहचानकर्ता, पंक्तियाँ) और समग्र कम्प्रेशन अनुपात दिखाती है।

$ lean-ctx benchmark run
──────────────────────────────────────────
BENCHMARK - /Users/you/project
──────────────────────────────────────────
Files:       143
Total:       285,401 → 42,810 tokens (85% reduction)
Avg/file:    1,997 → 300 tokens

Preservation:
  AST:         98.2%
  Identifiers: 97.4%
  Lines:       96.1%

Mode breakdown:
  full:        68% of files
  map:         22% of files
  signatures:   8% of files
  aggressive:   2% of files

संरचित इंटेंट पहचान

lean-ctx हर इंटरैक्शन को StructuredIntent में वर्गीकृत करता है - एक स्लॉट-आधारित प्रतिनिधित्व जिसमें टास्क टाइप, कॉन्फिडेंस, लक्ष्य फ़ाइलें, स्कोप, भाषा संकेत, तात्कालिकता और एक्शन वर्ब शामिल हैं। यह सभी बाद के निर्णयों को संचालित करता है।

9 टास्क टाइप पहचाने जाते हैं: Explore, Generate, FixBug, Refactor, Test, Review, Config, Deploy और Document।

IntentScope SingleFile से ProjectWide तक - यह निर्धारित करता है कि कॉन्टेक्स्ट कितने व्यापक रूप से एकत्र किया जाता है।

यह कैसे काम करता है

कंप्रेशन इंटेंट के अनुसार अनुकूलित होता है: FixBug टास्क त्रुटि पंक्तियों को प्राथमिकता देते हैं, Explore टास्क हल्की सफ़ाई का उपयोग करते हैं, और Generate टास्क सिग्नेचर और टाइप पर ध्यान केंद्रित करते हैं।

ctx_read का ऑटो-मोड सेलेक्टर सक्रिय टास्क टाइप का उपयोग करके निर्णय को परिष्कृत करता है।

उदाहरण

Query: "fix the NaN bug in entropy.rs"

StructuredIntent:
  task_type:    FixBug (confidence: 0.95)
  targets:      ["entropy.rs"]
  scope:        SingleFile
  language:     Rust
  urgency:      0.8
  action_verb:  "fix"

→ Compression: Information Bottleneck filter (error lines boosted)
→ Mode:        task (error-focused extraction)
→ Suggestions: tests/entropy_test.rs (deficit detection)

कॉन्टेक्स्ट पाइपलाइन आर्किटेक्चर

कॉन्टेक्स्ट पाइपलाइन छह अलग-अलग लेयर्स के माध्यम से जानकारी प्रोसेस करती है: Input → Intent → Relevance → Compression → Translation → Delivery।

यह कैसे काम करता है

Input → Intent → Relevance → Compression → Terse Engine → Delivery
  │        │          │            │              │              │
  │        │          │            │              │              └─ Final output to LLM
  │        │          │            │              └─ 4-layer terse pipeline (see below)
  │        │          │            └─ AST-aware compression per intent
  │        │          └─ Graph heat + relevance scoring
  │        └─ StructuredIntent classification
  └─ Raw file content / shell output

प्रति-लेयर मेट्रिक्स इनपुट टोकन, आउटपुट टोकन, कंप्रेशन रेट और प्रोसेसिंग समय ट्रैक करती हैं।

4-Layer Terse Engine

The terse engine applies four composable compression layers, controlled by compression_level (Off / Lite / Standard / Max). Each layer is independently verified by Lean4 proofs (TerseQuality, TerseEngine — part of 82 total theorems).

कॉन्टेक्स्ट लेजर और प्रेशर मैनेजमेंट

ContextLedger AI को भेजी गई हर फ़ाइल को ट्रैक करता है: पथ, कंप्रेशन मोड, मूल टोकन, भेजे गए टोकन और टाइमस्टैम्प।

यह कैसे काम करता है

तीन प्रेशर लेवल: None (70% से कम उपयोग), Compress (70–90%) और Evict (90% से अधिक)।

उदाहरण

Context Window: 128,000 tokens
Loaded: 89,600 tokens (70% utilization)
Pressure: None → safe

After loading 3 more files:
Loaded: 115,200 tokens (90% utilization)
Pressure: Compress → downgrade non-target files

Re-Injection Plan:
  utils.rs:    full → signatures  (save 2,400 tokens)
  helpers.rs:  full → map         (save 1,800 tokens)
  config.rs:   full → signatures  (save 1,200 tokens)
  Protected:   auth.rs, login.ts  (target files)

कॉन्टेक्स्ट डेफिसिट डिटेक्शन गायब जानकारी की पहचान करता है और प्रासंगिक फ़ाइलें सुझाता है।

स्मार्ट री-इंजेक्शन गैर-लक्ष्य फ़ाइलों को डाउनग्रेड करके कॉन्टेक्स्ट बजट मुक्त करने की योजना बनाता है।

मल्टी-एजेंट इंटेलिजेंस

जब कई AI एजेंट सहयोग करते हैं, तो lean-ctx संरचित हैंडऑफ़, रोल-आधारित कॉन्टेक्स्ट गहराई और एजेंट-पार ज्ञान साझाकरण प्रदान करता है।

यह कैसे काम करता है

HandoffPackage वर्तमान सेशन लेजर, संरचित इंटेंट और कॉन्टेक्स्ट स्नैपशॉट को एक हस्तांतरणीय इकाई में बंडल करता है।

सात एजेंट भूमिकाएँ पहचानी जाती हैं: Coder, Reviewer, Planner, Explorer, Debugger, Tester और Orchestrator।

उदाहरण

Agent "coder-1" (role: Coder):
  max_files_full: 8
  preferred_mode: full
  context_budget: 80%

Agent "reviewer-1" (role: Reviewer):
  max_files_full: 3
  preferred_mode: signatures
  context_budget: 60%

Shared Knowledge:
  K:discovery:auth_bug = "null check missing in line 42"
  K:decision:fix_approach = "add Option<T> wrapper"
  → reviewer-1 inherits these facts without re-reading files

एजेंट-पार ज्ञान साझाकरण एजेंटों को साझा स्क्रैचपैड के माध्यम से संरचित तथ्यों का आदान-प्रदान करने देता है।

Community Detection (Louvain)

The core::community module clusters files by their dependency graph using the Louvain algorithm. This groups tightly-coupled files into communities, enabling more intelligent context selection — files in the same community as your target are prioritized for preloading and receive higher relevance scores during task-driven reads.

Code Smell Detection

The ctx_smells tool detects long functions, deep nesting, and high cyclomatic complexity using the core::smells module. Detected smells are scored with graph-enriched weighting — files with high PageRank or many dependents receive amplified smell scores, surfacing maintenance hotspots that have the widest blast radius across the codebase.

यह भी देखें

• स्वायत्त बुद्धिमत्ता टूल्स - ये एल्गोरिदम जिन टूल्स का उपयोग करते हैं
• Tree-sitter इंजन - 18 भाषाओं के लिए AST पार्सिंग
• कॉन्फ़िगरेशन - थ्रेशोल्ड और स्वायत्तता सेटिंग्स ट्यून करना
• बेंचमार्क - अपनी बचत मापना