‏جت‌برینز چطور جستجوی معنایی کد رو برای ایجنت‌ها ساخت

تیم جت‌برینز تو این مقاله، که قسمت اول یه سریه، از ساخت Air Context می‌گه. Air Context یه سیستم RAG برای کده، یعنی کد رو جوری ایندکس می‌کنه که ایجنت بتونه با یه سوال معمولی تکه‌های مرتبط رو پیدا کنه. مشکل grep اینه که باید دقیقاً بدونی دنبال چه متنی هستی. ایجنتی که دنبال جای refresh شدن توکن‌هاست، نمی‌تونه امیدوار باشه کلمه refresh تو کد اومده باشه.

قدم اول chunkingـه، یعنی شکستن فایل‌ها به تیکه‌های کوچیک‌تر. کل فایل خیلی بزرگه و هر خط تنها هم بی‌معنیه. تیکه کردن با تعداد خط ثابت هم مثلاً import رو با وسط یه تابع قاطی می‌کنه. جت‌برینز با پارسرهای خودش برای ۹ زبان (Kotlin، Java، Python، JavaScript، TypeScript، C#، PHP، Go و Rust) کد رو به گره‌های نحوی (syntax node) می‌شکنه و بزرگ‌ترین واحدی که جا بشه رو نگه می‌داره. داک‌کامنت و annotation کنار تعریف می‌مونه و چیزهای بی‌معنی مثل @Override حذف می‌شه. بقیه زبان‌ها با همون روش خط‌به‌خط ایندکس می‌شن.

بعد نوبت vectorizationـه، یعنی یه مدل embedding هر تیکه رو به یه لیست چندهزارتایی عدد تبدیل می‌کنه که متن‌های هم‌معنی کنار هم بیفتن. هر بردار با float سی‌ودو بیتی حدود ۱۶ کیلوبایت جا می‌گیره و چند میلیون تیکه می‌شه ده‌ها گیگ. دو راه برای کم کردنش هست: بُعدهای کمتر، یا دقت کمتر برای هر بُعد. با بودجه ۵۱۲ بایت، ۴۰۹۶ بُعد یک‌بیتی خیلی بهتر از ۱۲۸ بُعد سی‌ودو بیتی جواب می‌ده.

به گفته نویسنده‌ها، هر بُعد مثل یه سوال بله/نه درباره متنه و پوشش همه سوال‌ها از دقت جواب‌ها مهم‌تره. پس هر عدد مثبت یا صفر می‌شه ۱ و هر عدد منفی می‌شه ۰. حجم ۳۲ برابر کم می‌شه و مقایسه به‌جای cosine similarity با Hamming distance انجام می‌شه، یعنی شمردن جاهایی که دوتا بردار با هم فرق دارن. این کار با XOR و شمردن بیت‌ها حدود صدتا دستور CPU خرج داره، نه هزاران ضرب.

این روش چند درصد از recall رو کم می‌کنه، ولی تیم می‌گه برای ایجنت مهم اینه که فایل‌های درست بین دوازده نتیجه اول باشن، نه ترتیب دقیقشون. یه هزینه پنهان هم داره: امتیاز شباهت همه نتیجه‌ها تو یه بازه باریک جمع می‌شه، چون حتی دوتا بردار بی‌ربط نصف بیت‌هاشون اتفاقی یکیه. برای همین جایی که باید تصمیم بگیرن یه نتیجه اصلاً مرتبطه یا نه، از float شونزده بیتی استفاده می‌کنن.

هر تیکه همراه مسیر فایلش embed می‌شه، ولی تو monorepo بزرگ IntelliJ IDEA با بیشتر از یه میلیون فایل، مسیرها گاهی از خود کد طولانی‌ترن. پس وسط مسیر با … کوتاه می‌شه و اول و آخرش می‌مونه. از نظر امنیت هم سورس مشتری ذخیره نمی‌شه و سرور فقط مختصات (مسیر و بازه بایت) رو برمی‌گردونه. embeddingها هم با یه مدل open-weight روی GPUهای خود جت‌برینز ساخته می‌شن و به هیچ شرکت دیگه‌ای نمی‌رن.

نکات کلیدی:

• chunking ساختارمند فعلاً برای ۹ زبان پشتیبانی می‌شه و بقیه زبان‌ها خط‌به‌خط تیکه می‌شن.
• کوانتیزاسیون یک‌بیتی حجم بردارها رو ۳۲ برابر کم می‌کنه.
• با بودجه ۵۱۲ بایت، ۴۰۹۶ بُعد یک‌بیتی از ۱۲۸ بُعد سی‌ودو بیتی بهتر عمل می‌کنه.
• بردارهای باینری برای رتبه‌بندی خوبن ولی برای آستانه‌گذاری نه، که اونجا float شونزده بیتی استفاده می‌شه.
• Air Context سورس کد رو ذخیره نمی‌کنه و فقط مسیر و بازه بایت رو نگه می‌داره.