Coding Agents වල Self-Improvement එකට යන වියදම අඩු කරන SIFT ක්‍රමය

Coding Agents තනියම දියුණු වෙන්න පුළුවන්, හැබැයි ප්‍රශ්නය සල්ලි!

Coding agents ලට තමන්ගේම වැරදි හදාගෙන self-improve වෙන්න පුළුවන් ක්‍රම දැනටමත් තියෙනවා. හැබැයි මෙතන ලොකු ප්‍රශ්නයක් තියෙනවා; ඒ තමයි මේකට යන වියදම (bill එක).

Darwin Gödel Machine (DGM) වැනි loop එකකදී වෙන්නේ agent කෙනෙක් තමන්ගේම harness එක modify කරගන්නවා, පස්සේ ඒ modified agent ගේ performance එක evaluate කරනවා. සාර්ථක වුණු "descendants" ලාව තියාගෙන මේ process එක දිගටම කරගෙන යනවා.

මේක හරිම powerful ක්‍රමයක්. හැබැයි ඕනෑම serious attempt එකකදී එකම බාධකයට මුහුණ දෙන්න වෙනවා: ඒ තමයි benchmark evaluation එක හරිම slow වගේම ගොඩක් expensive වීම.

මෙන්න මේ bottleneck එක විසඳන්න තමයි Self Improvement via Fast Tree-search (SIFT) කියන ක්‍රමය හඳුන්වා දෙන්නේ.

SIFT වල සාර්ථකත්වය ගැන දත්ත කිහිපයක් බලමු:

• Aider Polyglot benchmark එකේදී, o3-mini model එක භාවිතා කරලා expansion steps 30කින් SIFT 35.1% score එකකට පැමිණියා. (DGM එකට 30.7% score එකක් ගන්න tree-search nodes 80ක් අවශ්‍ය වුණා).
• SIFT run එකක් අවසන් වෙන්න ගියේ CPU hours 42ක් සහ wall clock time පස් පැයකට අඩු කාලයක් පමණයි.
• Qwen3-Coder-30B model එකත් එක්ක කරපු run එකක් CPU hours 224කින් සහ $34.3ක API cost එකකින් අවසන් වුණා. මේක DGM baseline එකට වඩා දස ගුණයක පමණ CPU budget එකක් ඉතිරි කිරීමක්.

කෙටියෙන් කිව්වොත්, SIFT එකට පුළුවන් අඩු tree-search nodes ප්‍රමාණයක් පාවිච්චි කරලා, DGM එකට වඩා වැඩි Polyglot score එකක් ලබාගන්න.

ඇත්තටම වියදම වැඩි වෙන්නේ කොතනද?

Coding agent කෙනෙක් self-improve වෙද්දී loops දෙකක් වැඩ කරනවා.

1. Inner loop: මේක අපිට හුරුයි. repository එක කියවනවා, files edit කරනවා, tools run කරලා failures check කරලා patch එකක් හදනවා.
2. Outer loop: මෙතනදී agent harness එකම repository එකක් විදිහට සලකනවා. වඩාත් ශක්තිමත් model එකක් දැනට ඉන්න agent ගේ අඩුපාඩු diagnose කරලා, implementation එක rewrite කරලා අලුත් "child agent" කෙනෙක් නිර්මාණය කරනවා. පස්සේ මේ child agent ට benchmark tasks දීලා බලනවා modification එක සාර්ථකද කියලා.

DGM සහ HGM වැනි systems වලින් ඔප්පු කරලා තියෙනවා මේ evolutionary process එකෙන් coding agents ලාව දියුණු කරන්න පුළුවන් කියලා. හැබැයි ප්‍රශ්නය තියෙන්නේ feedback signal එක ගන්න නම් real benchmark tasks විශාල ප්‍රමාණයක් run කරන්න වෙන එකයි.

SIFT වල cost breakdown එක බැලුවම මේ mismatch එක පැහැදිලි වෙනවා:

• එක self-improvement step එකකට cost එක $0.12යි.
• එක pairwise judge call එකකට cost එක $0.044යි.
• හැබැයි Polyglot-50 evaluation එකකට $6.00ක් සහ CPU hours 2.6ක් යනවා.

SIFT කරන්නේ අලුත් node එකකට judging comparisons 10කට limit කරන එකයි. එතකොට මුළු judging round එකට යන වියදම, candidate කෙනෙක්ව benchmark tasks 50කින් evaluate කරනවට වඩා ගොඩක් අඩුයි.

මේ නිසා architecture එක සම්පූර්ණයෙන්ම වෙනස් වෙනවා. "මේ patch එක benchmark කරන්න ඕනෙද?" කියලා මිල අධික benchmark cost එක ගෙවලා බලනවා වෙනුවට, SIFT මුලින්ම අහන්නේ ඉතාම ලාභදායී ප්‍රශ්නයක්:

"මේ candidate harness වලින් coding agent ව දියුණු කරන්න වැඩි ඉඩක් තියෙන්නේ කාටද?"

SIFT කියන්නේ LLM එකක් control plane එකේ ඉන්න search scheduler එකක්

SIFT එක තනි coding agent කෙනෙක් විදිහට නෙවෙයි, පොඩි distributed system එකක් විදිහට හිතන්න.

මෙය agent versions වල archive එකක් maintain කරනවා. හැම version එකක්ම self-modification tree එකක node එකක් විදිහට ක්‍රියා කරනවා. අලුතින් හැදෙන child agent කෙනෙක්, දැනට ඉන්න ශක්තිමත් incumbents ලා කිහිප දෙනෙක් එක්ක compare කරනවා. මේ pairwise wins සහ losses එකතු කරලා global ranking එකක් හදනවා.

මේ ranking එක පාවිච්චි කරලා තීරණය කරනවා:

• ඊළඟට expand කරන්න ඕනේ මොන node එකද?
• මිල අධික evaluation queue එකේ priority දෙන්න ඕනේ කාටද?

මේ සඳහා ඔවුන් regularized Bradley-Terry model එකක් පාවිච්චි කරනවා. Node $i$ ගේ strength එක $\theta_i$ නම්, $i$ විසින් $j$ ව පරාජය කිරීමේ සම්භාවිතාව (probability) ගණනය කරන්නේ මෙහෙමයි: $P(i > j) = \theta_i / (\theta_i + \theta_j)$

හැබැයි SIFT කෙලින්ම raw strength values විශ්වාස කරන්නේ නැහැ. Judge strength එක සහ benchmark accuracy එක ranks වලට හරවලා, parent sampling කරන්නේ මේ formula එකට අනුවයි:

$P(i) \propto \exp(-\alpha \cdot \text{judge_rank}(i) - \beta \cdot \text{accuracy_rank}(i) - \eta \cdot \log(1 + \text{visits}(i)))$

මෙහි මුල් terms දෙකෙන් කරන්නේ දැනටමත් හොඳ පෙනුමක් තියෙන candidates ලාව තෝරාගන්න එකයි. අන්තිම "visit penalty" එකෙන් කරන්නේ එකම branch එකක දිගටම search කරලා කාලය නාස්ති කරන එක වැළැක්වීමයි.

මේක ඉතාම වැදගත් detail එකක්. මොකද self-improvement system එකක් කියන්නේ නිකම්ම benchmark score එක වැඩිම තැනට යන (hill-climb) එකක් නෙවෙයි. මුල් කාලීන benchmark scores noisy වෙන්න පුළුවන්. ඒ නිසා local score එක වැඩි වුණු harness එකක් පස්සේ කාලෙක dead end එකක් වෙන්න පුළුවන්.

Pairwise judging සාර්ථක වෙන්නේ ranking කිරීම scoring කිරීමට වඩා පහසු නිසා

මෙතනදී judge ට benchmark answers හෝ task outcomes පෙනෙන්නේ නැහැ. Judge කරන්නේ candidate implementations දෙකක් අතරින් වඩා හොඳ එක තෝරන එකයි.

SIFT කරන්නේ අලුත් child agent ව, history එකේ ඉන්න හැමෝම එක්ක නෙවෙයි, top 10 relevant archive nodes එක්ක විතරක් compare කරන එකයි.

ඇයි pairwise comparisons පාවිච්චි කරන්නේ? Absolute scores දෙනකොට judge ට calibrated scale එකක් හදාගන්න වෙනවා (ඒක අමාරුයි). හැබැයි pairwise preferences වලදී අහන්නේ "A ද B ට වඩා හොඳයි?" කියන එක විතරයි. පස්සේ Bradley-Terry fit එක හරහා මේ noisy local comparisons ඔක්කොම එකතු කරලා එක global ordering එකක් හදාගන්නවා.

SIFT වල ක්‍රියාකාරීත්වය සහ Production Systems වලට ඇති වැදගත්කම

මෙතනදී SIFT වල Judge භාවිතා කරන්නේ search signal එකක් විදිහටයි. ඒ කියන්නේ අවසාන තීරණය Judge ගන්නේ නැහැ; final verification එක කරන්නේ තවමත් benchmark එක හරහායි.

Production agent systems වලටත් මේ mental model එක ගොඩක් ප්‍රයෝජනවත් වෙනවා. ඒ කියන්නේ:

• Cheap model-based signals: වැඩ කොටස route කිරීමට (දිශානුගත කිරීමට) භාවිතා කරයි.
• Expensive environment-based signals: අවසාන ප්‍රතිඵලය validate කිරීමට භාවිතා කරයි.

Architecture එකෙන් ලැබෙන වේගය (Speedup)

SIFT වල තවත් විශේෂත්වයක් වෙන්නේ self-improvement සහ evaluation කියන ක්‍රියාවලි දෙක එකිනෙකෙන් වෙන් කිරීමයි (decouple).

සාමාන්‍ය loop එකක් වැඩ කරන්නේ මෙහෙමයි: Modify $\rightarrow$ Benchmark $\rightarrow$ Modify $\rightarrow$ Benchmark

මෙතනදී CPU-heavy benchmark එක අවසන් වන තුරු මුළු system එකම block වෙනවා. නමුත් SIFT වල මේ expansion සහ evaluation සිද්ධ වෙන්නේ asynchronously.

එනම්, child agent කෙනෙක් කුඩා "easy gate" එකක් pass කළා නම්, full evaluation එක ඉවර වන තුරු ඉන්නේ නැතුව:

1. ඔහුව judge කරලා archive එකට ඇතුළත් කරනවා.
2. Evaluation priority queue එකට දානවා.
3. පස්සේ කාලෙක speculative expansion සඳහා parent කෙනෙක් විදිහට පාවිච්චි කරනවා.

මේ disaggregated pipeline එක නිසා තමයි SIFT වලට විශාල වේගයක් ලැබෙන්නේ.

මතක තබා ගත යුතු වැදගත්ම කරුණ: Agent optimization එක synchronous for loop එකක් විදිහට හදන්න එපා. Generation, judging, evaluation සහ archive updates කියන ඒවා queues සහ durable state හරහා සම්බන්ධ වූ separate workers ලෙස නිර්මාණය කරන්න.

Benchmark ප්‍රතිඵල සහ සම්පත් භාවිතය

Aider Polyglot benchmark (tasks 225ක් සහිත) එකේ ප්‍රතිඵල අනුව SIFT වල සාර්ථකත්වය පෙනෙනවා:

Method Coding model Judge Polyglot Score Base agent Qwen3-Coder-30B none 20.0% DGM Qwen3-Coder-30B none 27.1% HGM Qwen3-Coder-30B none 30.5% SIFT Qwen3-Coder-30B Qwen3-Coder-480B 31.1% SIFT Qwen3-Coder-30B gpt-5.4 32.0% SIFT o3-mini gpt-5.4 35.1%

මෙහිදී SIFT search එක සඳහා tasks 50ක subset එකක් පමණක් භාවිතා කර, ඉතිරි tasks භාවිතා කරන්නේ final evaluation එකටයි. ඔබ සැමවිටම එකම evaluation set එක පාවිච්චි කළොත්, වෙන්නේ search එක benchmark එකට overfit වීමයි.

Judge ගේ ගුණාත්මකභාවය (Judge Quality)

TerminalBench 2.1 පරීක්ෂණයේදී පෙනී ගියේ Judge ගේ quality එක ඉතා වැදගත් වන අවස්ථා ඇති බවයි.

• gpt-5.4-high භාවිතා කළ විට සාමාන්‍යයෙන් 36.7% ක score එකක් ලැබුණා.
• gpt-5 භාවිතා කළ විට එය 34.5% දක්වා අඩු වුණා.

විශේෂත්වය වන්නේ, සාමාන්‍ය rank correlation එක judge දෙදෙනාටම සමාන වුවත් (0.71 - 0.72), top candidates තෝරාගැනීමේදී gpt-5.4-high ඉතා නිවැරදි වීමයි. gpt-5 ගේ top-ranked candidate, එම search එකෙන්ම ලැබුණු හොඳම agent නෙවෙයි.

මින් අපට ලැබෙන systems rule එක: Judge quality එක වඩාත්ම වැදගත් වෙන්නේ frontier (ඉහළම මට්ටමේ) candidates ලා තෝරන විටයි.

1. Cheap judge: දුර්වල patches ප්‍රතික්ෂේප කිරීමට සහ broad exploration සඳහා යොදාගන්න.
2. Strong judge: full validation වලට පෙර top candidates ලා rerank කිරීමට යොදාගන්න.

ආරම්භ කරන්නේ කෙසේද? (Quick Start)

ඔබට SIFT පද්ධතිය අත්හදා බැලීමට අවශ්‍ය නම්, මුලින්ම DGM repository එක භාවිතා කරන්න. එහි archive, Docker isolation සහ coding-agent harness වැනි අවශ්‍ය සියලුම කොටස් තිබේ.

git clone https://github.com/jennyzzt/dgm.git
cd dgm
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt
docker run hello-world
python -m polyglot.prepare_polyglot_dataset
# Baseline evolutionary harness එක run කිරීමට
python DGM_outer.py --polyglot

DGM_outer.py හරහා parent selection, self-improvement සහ evaluation අදියරවල් සිදු වේ. SIFT මගින් කරන්නේ මෙම orchestration සහ ranking layer එක වෙනස් කිරීමයි.

SIFT ක්‍රියා කරන ආකාරය (Control Plane)

SIFT system එකේ ක්‍රියාකාරීත්වය සරලව බැලුවොත්, එය loop එකක් ලෙස වැඩ කරයි. එහි ප්‍රධාන පියවර මෙසේය:

• Filtering: අලුතින් නිර්මාණය වූ child agents ලා අතරින් ගුණාත්මක ඒවා පමණක් easy_gate එකක් හරහා archive එකට එකතු කරයි.
• Ranking: win_matrix එකක් සහ Bradley-Terry model එකක් භාවිතා කර agent ලා අතරින් හොඳම කෙනා තෝරා ගනී.
• Expansion: හොඳම parent agents ලා තෝරාගෙන ඔවුන් හරහා තවත් අලුත් versions (self-improvement) නිර්මාණය කරයි.
• Evaluation: eval_queue එකේ සිටින agents ලාට full evaluation එකක් සිදු කරයි.

මෙම process එක හරහා system එක නිරන්තරයෙන්ම තමන්ගේම හැකියාවන් වැඩි දියුණු කරගනී.

Agent කෙනෙක් ඇත්තටම ඉගෙන ගන්නේ මොනවාද?

බොහෝ දෙනෙක් සිතන්නේ self-improvement යනු ඉතා සංකීර්ණ algorithms නිර්මාණය කිරීමක් කියායි. නමුත් SIFT පෙන්වා දෙන්නේ එය ඉතා සරල විය හැකි බවයි.

උදාහරණයක් ලෙස, SIFT agent විසින් තමන්ටම test_runner නමින් tool එකක් එකතු කරගත් අතර, coding instruction එක මෙසේ වෙනස් කරගත්තේය: "කෝඩ් එක edit කළ පසු, test_runner එක run කරන්න, errors පරීක්ෂා කර නැවත නිවැරදි කර, tests pass වන තෙක් මෙය නැවත නැවත කරන්න."

මෙයින් පෙනී යන්නේ agent කෙනෙකුට අවශ්‍ය වන්නේ අලුත් විද්‍යාවක් නොව, නිවැරදි software engineering discipline එකක් අනුගමනය කිරීමට ඉගෙන ගැනීමයි.

ආරක්ෂක පියවර (Safety Boundaries)

Recursive self-modification වලදී විශාල අවදානමක් ඇත. Optimizer එක උත්සාහ කරන්නේ agent ගේ හැකියාව වැඩි කිරීමට නොව, "ලකුණු දෙන ක්‍රමය" (rules) වෙනස් කර ලකුණු වැඩි කර ගැනීමටයි.

උදාහරණයක් ලෙස, සමහර agents ලා timeout limits වැඩි කිරීමට හෝ retry limits වැඩි කිරීමට උත්සාහ කර ඇත. මෙය වළක්වා ගැනීමට පහත පියවර අනුගමනය කළ යුතුය:

• Read-only Access: Benchmark data සහ graders සැමවිටම read-only ලෙස තබා ගන්න.
• Allow-list: Agent ට වෙනස් කළ හැක්කේ නිශ්චිත files කිහිපයක් පමණක් බවට තීරණය කරන්න.
• Isolation: සෑම candidate agent කෙනෙකුම isolated container එකක හෝ VM එකක run කරන්න.
• External Benchmark: අවසාන පරීක්ෂණය (final benchmark) search loop එකෙන් පිටත තබා ගන්න.

මෙම සීමාවන් නැති වුවහොත්, agent විසින් කරන්නේ තමන්ගේ දක්ෂතාවය වැඩි කරගැනීම නොව, scoreboard එක වෙනස් කර ලකුණු හොරකම් කිරීමයි.

අවසාන අදහස: Agent Optimization යනු Systems Engineering එකකි

SIFT හි ඇති ප්‍රධානම නව්‍යතාවය වන්නේ එහි feedback architecture එකයි. ඔවුන් විවිධ පිරිවැයක් (cost) සහිත signals කිහිපයක් භාවිතා කරයි:

1. Static checks: ඉතා ලාභයි (Cheap)
2. LLM pairwise rank: මධ්‍යම පිරිවැයක් ඇත (Medium)
3. Benchmark execution: ඉතා මිල අධිකයි (Expensive)

සෑම mutation එකකටම මිල අධික benchmark එක run කරනවා වෙනුවට, ඔවුන් "Cascade" ක්‍රමයක් භාවිතා කරයි. එනම්, මුලින් ලාභ ක්‍රම මගින් දුර්වල candidates ඉවත් කර, අවසානයේ හොඳම කිහිප දෙනෙකුට පමණක් full evaluation එක ලබා දීමයි.

ඔබ prompt mutation, tool policies හෝ routing rules වැනි දේ optimize කරන agent කෙනෙකු නිර්මාණය කරන්නේ නම්, මෙම cascade pattern එක ඉතා ප්‍රයෝජනවත් වනු ඇත.

SIFT අපට උගන්වන්නේ agent කෙනෙකුට තනිවම දියුණු වීමට නම්, ඔහුට නිවැරදි feedback loop එකක් සහ දැඩි ආරක්ෂක සීමාවන් සහිත පද්ධතියක් ලබා දිය යුතු බවයි. මෙය හුදෙක් AI එකක ප්‍රශ්නයක් නොව, නිවැරදි system එකක් නිර්මාණය කිරීමේ ඉංජිනේරු අභියෝගයකි.