ডকুমেন্টেশন

বৈজ্ঞানিক বুদ্ধিমত্তা স্তর

তথ্য তত্ত্ব, গ্রাফ তত্ত্ব এবং পরিসংখ্যানিক বলবিদ্যার উপর ভিত্তি করে ছয়টি কম্প্রেশন অ্যালগরিদম - সবকিছু স্বয়ংক্রিয়ভাবে lean-ctx-এর ভিতরে চলে।

lean-ctx প্যাটার্ন ম্যাচিং-এর বাইরে যায়। তথ্য তত্ত্ব, গ্রাফ তত্ত্ব এবং পরিসংখ্যানিক বলবিদ্যার ছয়টি অ্যালগরিদম একসাথে কাজ করে কী রাখতে হবে, কী বাদ দিতে হবে এবং কোথায় রাখতে হবে তা নির্ধারণ করতে - সব স্বয়ংক্রিয়ভাবে, সব স্থানীয়ভাবে, শূন্য কনফিগারেশন।

এই অ্যালগরিদমগুলো স্বায়ত্তশাসিত বুদ্ধিমত্তা স্তরকে শক্তি দেয়। এগুলো প্রতিটি ctx_read, ctx_preload, এবং ctx_overview কলের সময় সক্রিয় হয় - আপনি কখনো এগুলো সরাসরি আহ্বান করেন না।

স্তরগুলো কীভাবে পারস্পরিক ক্রিয়া করে

অ্যালগরিদমনির্ধারণ করেভিত্তি
Spectral Relevanceকোন ফাইলগুলো গুরুত্বপূর্ণনির্ভরতা গ্রাফ + PageRank
Boltzmann Allocationপ্রতি ফাইলে কতগুলো tokenকাজের নির্দিষ্টতা + প্রাসঙ্গিকতা স্কোর
Predictive Surpriseকোন লাইনগুলো রাখতে হবেBPE token-এর ক্রস-এন্ট্রপি
MMR Deduplicationকোন লাইনগুলো অপ্রয়োজনীয়Bigram Jaccard সাদৃশ্য
Semantic Chunkingআউটপুট কীভাবে সাজাতে হবেAST সীমানা + মনোযোগ প্রবাহ
BPE Optimizationচূড়ান্ত টেক্সট কীভাবে এনকোড করতে হবেToken-স্তরের কম্প্রেশন নিয়ম

প্রেডিক্টিভ সারপ্রাইজ স্কোরিং

ঐতিহ্যবাহী কম্প্রেশন ফিল্টারগুলো কাঁচা অক্ষরে Shannon এন্ট্রপি ব্যবহার করে, যা aaaa এবং import-কে সমানভাবে পূর্বানুমানযোগ্য মনে করে। Predictive Surprise পরিবর্তে BPE token ফ্রিকোয়েন্সির বিপরীতে ক্রস-এন্ট্রপি পরিমাপ করে - LLM-এর টোকেনাইজারের কাছে প্রতিটি লাইন কতটা অপ্রত্যাশিত।

কীভাবে কাজ করে

  1. প্রতিটি লাইন o200k_base (GPT-4o / Claude টোকেনাইজার) ব্যবহার করে টোকেনাইজ করা হয়।
  2. প্রতিটি token-এর জন্য, একটি Zipfian প্রায়র র‍্যাঙ্কের উপর ভিত্তি করে প্রত্যাশিত ফ্রিকোয়েন্সি অনুমান করে।
  3. ক্রস-এন্ট্রপি গণনা করা হয়: সাধারণ token-যুক্ত লাইনগুলো (বয়লারপ্লেট) কম স্কোর পায়; বিরল token-যুক্ত লাইনগুলো (জটিল লজিক) উচ্চ স্কোর পায়।
  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

কেন এটি গুরুত্বপূর্ণ

Predictive Surprise অক্ষর-স্তরের এন্ট্রপির চেয়ে 15–30% বেশি বয়লারপ্লেট সরিয়ে দেয় জটিল লজিক সংরক্ষণ করে। এটি সরাসরি মডেল করে LLM কী "তথ্যপূর্ণ" মনে করে কারণ এটি একই BPE শব্দভাণ্ডার ব্যবহার করে।


স্পেকট্রাল রিলেভেন্স প্রোপাগেশন

আপনি যখন 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 প্রাসঙ্গিক ফাইলগুলো নির্বাচন করার পর, প্রতিটি ফাইলের জন্য একটি token বাজেট প্রয়োজন। সরল পদ্ধতিতে সমান বাজেট দেওয়া হয় বা প্রাসঙ্গিকতা অনুযায়ী সাজানো হয়। Boltzmann Allocation সর্বোত্তমভাবে token বিতরণ করতে পরিসংখ্যানিক বলবিদ্যা ব্যবহার করে।

কীভাবে কাজ করে

  1. প্রতিটি ফাইলের Spectral Relevance থেকে একটি প্রাসঙ্গিকতা স্কোর Ei আছে।
  2. কাজ থেকে একটি তাপমাত্রা প্যারামিটার β নির্ণয় করা হয়: নির্দিষ্ট কাজ ("login.ts-এ auth বাগ ঠিক করুন") কম তাপমাত্রা তৈরি করে (শীর্ষ ফাইলে তীক্ষ্ণ বরাদ্দ); ব্যাপক কাজ ("কোডবেস রিফ্যাক্টর করুন") উচ্চ তাপমাত্রা তৈরি করে (সমান বিতরণ)।
  3. Token বাজেট Boltzmann বিতরণ অনুসরণ করে: budgeti = total × (eβ·Ei / Σ eβ·Ej)
  4. সর্বনিম্ন এবং সর্বোচ্চ বাজেট প্রয়োগ করা হয় (প্রতি ফাইলে 128–4096 token), এবং বরাদ্দকৃত বাজেটের উপর ভিত্তি করে কম্প্রেশন মোড (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.

AspectLegacy (Boltzmann)Current (RRF)
Signal handlingMixed units in one formula (0.4×recency + 0.3×frequency + 0.3×size)Each signal ranked independently, then fused
Weight tuningRequires manual weight calibration (arbitrary 0.4/0.3/0.3)No weights - only K=60 (standard IR parameter)
Edge casesLarge files dominate due to log-scaling of sizeFair treatment - each signal contributes equally via rank

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-গুলো "মধ্যভাগে হারিয়ে যাওয়া" সমস্যায় ভোগে: কনটেক্সটের শুরু এবং শেষের তথ্য মধ্যবর্তী বিষয়বস্তুর চেয়ে বেশি মনোযোগ পায়। সেমান্টিক চাংকিং তথ্য ক্ষতি কমাতে আউটপুট পুনর্গঠন করে।

কীভাবে কাজ করে

  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. প্রতিটি লাইনের জন্য, পূর্বে নির্বাচিত সমস্ত লাইনের ("কভারেজ সেট") বিপরীতে bigram Jaccard সাদৃশ্য গণনা করুন।
  2. MMR স্কোর প্রাসঙ্গিকতা এবং অপ্রয়োজনীয়তার মধ্যে ভারসাম্য রাখে: MMR(l) = λ × relevance(l) - (1 - λ) × max_similarity(l, selected)
  3. MMR < 0 স্কোরযুক্ত লাইনগুলো দমন করা হয় - এগুলো তথ্যের চেয়ে বেশি অপ্রয়োজনীয়তা যোগ করে। λ প্যারামিটার ডিফল্ট 0.7 (বৈচিত্র্যের চেয়ে প্রাসঙ্গিকতাকে অগ্রাধিকার দেয়)।

প্রভাব

একটি সাধারণ মাল্টি-ফাইল প্রিলোডে, MMR 10–25% অপ্রয়োজনীয় বিষয়বস্তু সরিয়ে দেয় - প্রধানত শেয়ার্ড ইমপোর্ট এবং পুনরাবৃত্ত ইউটিলিটি প্যাটার্ন।


BPE-সারিবদ্ধ Token অপ্টিমাইজেশন

সমস্ত বিষয়বস্তু নির্বাচন এবং সাজানোর পর, একটি চূড়ান্ত পাস LLM-এর BPE টোকেনাইজার-এর জন্য কাঁচা টেক্সট অপ্টিমাইজ করে। ছোট ফরম্যাটিং পরিবর্তনগুলো অর্থ পরিবর্তন না করেই token সংখ্যা উল্লেখযোগ্যভাবে কমাতে পারে।

অপ্টিমাইজেশন নিয়ম

আগেপরেToken সাশ্রয়
function fn প্রতি উপস্থিতিতে 1 token
-> ->2 → 1 token
=> => 2 → 1 token
{ }{}2 → 1 token
(4 স্পেস) (2 স্পেস)~50% ইন্ডেন্টেশন সাশ্রয়
'static 'static লাইফটাইমনিরাপদ হলে বাদ দেওয়া হয়প্রতি উপস্থিতিতে 2 token

কীভাবে কাজ করে

প্রতিটি নিয়ম হলো একটি সাধারণ স্ট্রিং প্রতিস্থাপন যা অন্যান্য সমস্ত কম্প্রেশন ধাপের পরে লাইন-বাই-লাইন প্রয়োগ করা হয়। নিয়মগুলো BPE token সীমানা বিশ্লেষণ থেকে প্রাপ্ত - এগুলো সেই প্যাটার্নগুলোকে লক্ষ্য করে যেখানে টোকেনাইজার অর্থগতভাবে সমতুল্য টেক্সটের জন্য অপ্রয়োজনীয়ভাবে বেশি token তৈরি করে।

প্রভাব

BPE অপ্টিমাইজেশন সাধারণত ইতিমধ্যে কম্প্রেসড আউটপুটে অতিরিক্ত 3–8% token সাশ্রয় করে। সাশ্রয়গুলো ফাইল জুড়ে যৌগিক হয় এবং ভার্বোস ভাষাগুলোতে (TypeScript, Java, C#) সবচেয়ে উল্লেখযোগ্য।


প্রভাব যাচাই করা

সমস্ত ছয়টি অ্যালগরিদমের সম্মিলিত প্রভাব পরিমাপ করতে আপনার প্রকল্পে lean-ctx benchmark run চালান। বেঞ্চমার্ক রিপোর্ট প্রতি-ফাইল token সাশ্রয়, সংরক্ষণ স্কোর (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-এ শ্রেণীবদ্ধ করে - টাস্ক টাইপ, কনফিডেন্স, লক্ষ্য ফাইল, স্কোপ, ভাষা ইঙ্গিত, জরুরিতা এবং অ্যাকশন ক্রিয়া সহ একটি স্লট-ভিত্তিক প্রতিনিধিত্ব।

৯টি টাস্ক টাইপ চিহ্নিত করা হয়: 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)

কনটেক্সট পাইপলাইন আর্কিটেকচার

কনটেক্সট পাইপলাইন ছয়টি স্বতন্ত্র লেয়ারের মধ্য দিয়ে তথ্য প্রসেস করে: InputIntentRelevanceCompressionTranslationDelivery

কীভাবে কাজ করে

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).

LayerNameWhat it does
1DictionaryCommon token substitutions and abbreviations (functionfn, returnret)
2ResidualWhitespace normalization, blank-line collapse, boilerplate removal
3ScoringInformation-theoretic ranking — keeps high-surprise blocks, prunes low-entropy filler
4PipelineCEP v1 protocol: delta-only output, structured notation (+/-/~), token budgets

কনটেক্সট লেজার ও চাপ ব্যবস্থাপনা

ContextLedger AI-কে পাঠানো প্রতিটি ফাইল ট্র্যাক করে: পাথ, কমপ্রেশন মোড, মূল টোকেন, পাঠানো টোকেন এবং টাইমস্ট্যাম্প।

কীভাবে কাজ করে

তিনটি চাপ স্তর: None (৭০% এর কম ব্যবহার), Compress (৭০–৯০%) এবং Evict (৯০% এর বেশি)।

উদাহরণ

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.


আরো দেখুন