Ang Claude Model ni Anthropic ay nakakaranas ng teknikal na hamon sa code generation at reliability ng agent

Bumababa ang maraming teknikal na hamon na kinakaharap ni Anthropic sa mga modelo ng Claude. Ang code generation ay nawawalan ng kalayaan dahil sa mga pagtatakda sa pag-embed ng watermark; ang adaptive thinking mechanism ng Sonnet 5 ay nagpapahintulot sa isang parehong modelo na i-adyus ang iba’t ibang antas ng komputasyonal na pagsisikap, na nagpapalabo sa hangganan ng kakayahan ng produkto; ang 1M context ay tila sapat, ngunit sa mahabang Agent session, ang modelo ay talagang nakakagamit lamang ng humigit-kumulang 20%-30% nito, at pagkatapos ay nagsisimula na magkaron ng kalituhan at pagkakalimot; habang ang pag-compress ng context, mahirap masabing alin sa mga impormasyon ay patuloy na epektibo, at ang pansamantalang hipotesis ay maaaring maging maliit na katotohanan; pagkatapos ng aktibong pagbabago ng Agent sa kapaligiran, ang modelo ay nagsisimula na analisahin ang mga bagong pagkakamali na itinayo nito, kaysa sa orihinal na problema. Ipinapakita ng artikulo na ang reliability ng mahabang Agent ay lalo na nakadepende sa kalinawan ng estado, pagkakatotoo ng mga aksyon, at kakayahang i-rollback ang mga pagkakamali, kaysa sa simpleng single-step performance ng modelo.

May-akda ng artikulo, pinagkukunan: Leiphone

Mas masamang mangyari kaysa sa pagbaba ng model score ay ang pag-update ng model habang ang mga user ay nagsisimulang mag-isip na lalong hindi na ito magagamit.

Ang Anthropic ay may kaunting amoy nito noong huling panahon.

Sa mga araw na ito, may isang post sa X na nag-iskina ng ilang karaniwang pagkakamali ni Claude: ang mga teksto at code ay nagsisimulang magkaroon ng machine-readable tags, ang praktikal na karanasan ng Sonnet 5 ay hindi sumasabay sa ingay ng model upgrade, ang Fable 5 ay mas mahal pero mahirap makita kung paano ito mas malakas kaysa sa Opus 5; at may isang mas nakakalungkot na feedback na ang context ng Fable 5 ay ginagamit lang sa halos 20%–30%, at mula doon ay bumababa ang performance.

Walang malinaw na ugnayan ang mga bagay na ito, isa ay parang isyu sa mekanismo ng paggawa, isa ay parang isyu sa kakayahan ng modelo, isa ay parang isyu sa pagtatakda ng presyo, at isa pa ay parang may problema sa mahabang konteksto.

Ngunit sa pananaw ng kasalukuyang teknikal na stack ni Claude, ang mga ito ay nakakapit sa 5 tiyak na punto: paano ginagawa ng modelo ang pagbuo, gaano karaming kalkulasyon ang handang gawin sa pag-iisip, bakit nagiging mas mahirap i-hierarchy ang iba’t ibang modelo, bakit nawawala ang malawak na konteksto bago pa ito lubos na gamitin, at bakit madalas bumaba ang kakayahan sa mga eksperimento kapag isinama sa totoong mga gawain ng Agent.

Kaya ang recent issue ni Anthropic ay maaaring hindi simpleng “model degradation”. Mas tila pagkatapos na maging mas malakas si Claude, nagsimula na mag-antagonize ang generation, computation, context, at runtime ng Agent.

01

Ang mga marka na mababasa ng machine ay isinilid sa karaniwang teksto, at ang teknikal na hamon ay ang pag-iwan ng matatag na signal habang pinapababa ang pagbabago sa kalidad ng pagbuo. Kapag nasa code na, ang problema ay naging mas mahirap dahil iba ang distribution ng token sa natural na wika at sa code.

Papel: https://arxiv.org/pdf/2301.10226

Madalas na mayroong maraming kandidatong may malapit na kahulugan sa natural na wika. Maaaring palitan ang mga salita o baguhin ang pagkakasunod-sunod ng pangungusap para sa parehong kahulugan, at mayroong tiyak na redundancy sa pagbuo ng modelo sa maraming posisyon. Isang karaniwang paraan sa watermarking ng teksto ay ang paggamit ng redundancy na ito, sa pamamagitan ng pagbabago ng kaunting probability sa pagpili sa pagitan ng mga tatanggapin na token, at pagkolekta nito sa sapat na haba upang makalikha ng statistical pattern.

Ang code ay may malaking bilang ng mga posisyon na mababang entropiya. Pagkatapos ng pagdeklara ng mga variable, ang mga susunod na pagtawag ay halos kailangang gamitin ang parehong pangalan; ang mga field ng JSON, mga kuwento, at mga bracket ay may mahigpit na estruktural na pagkakabukod; ang mga parameter ng function ay kailangang sumunod sa interface; sa mga path, regex, SQL, at Shell command, ang isang pagbabago sa isang token ay maaaring diretso na baguhin ang pag-uugali.

Batay sa distribution ng probabilidad, ang mga posisyon na ito ay karaniwang napakatindi. Ang tamang token ay nagsasagawa ng mataas na probabilidad, habang ang iba pang mga kandidato ay hindi lamang iba pang paraan ng pagpapahayag, kundi maaaring mali. Kaya, ang pangunahing limitasyon na kinakaharap ng code watermark ay ang kapasidad ng pag-encode.

Kung mayroon lamang isang makatwirang output sa isang posisyon, maliliit ang espasyo nito para sa karagdagang signal; kung ang sistema ay naglalagay ng mga marka lamang sa mga mataas na entropiya na posisyon, magkakaroon ito ng problema sa maikling code, mataas na proporsyon ng structured token, at kulang na mga posisyon na maaaring gamitin.

Kaya may direktang kompromiso sa pagitan ng deteksiyon ng lakas, kalidad ng pagbuo, at kakayahang labanan ang pagbabago: masyadong mahina ang signal para ma-detect, masyadong malakas ang pagpapahigpit na maaaring maapektuhan ang tamang pagbuo, at habang nais pang panatilihin ang kakayahang ma-detect pagkatapos ng pag-format at lokal na pagbabago, kailangan ng mas mataas na redundancy ng signal.

Hindi inilabas ng Anthropic kung paano eksaktong binago ng Claude ang text tokenization, kaya hindi maaaring direktang isasakanya ang pagbabago sa kalidad ng Claude Code sa isang partikular na watermark algorithm.

Ang matitiyak dito ay isa pang pagbabago: ang paggawa ng code ay nagtatanggol na ng mas maraming pagkakabound. Bukod sa semantiko at tamang pagpapatupad, maaaring kailanganin nito na sundin ang mga protokolo ng tool, structured format, mga patakaran sa kaligtasan, at mga marka ng pinagmulan, habang ang kalayaan ng code mismo na makakasailalim sa mga karagdagang pagkakabound ay mas maliit kaysa sa natural na wika.

02

Ang pagbabago na dulot ng adaptive thinking ni Sonnet 5 ay hindi lamang nagpapahintulot sa model na mag-isip nang kaunting panahon.

Noong nakakausap ang Sonnet, Opus, Fable, madaling i-interpret bilang ilang fixed capability points. Ngayon, kasama ang effort, maaaring makarating ang parehong model sa iba’t ibang test-time compute intervals, at hindi na maaaring kumatawan nang buo ng isang request kung gaano karaming capability ang ginamit.

Mga link na pang-referensya: https://platform.claude.com/docs/en/build-with-claude/effort

Lalong nakikita ang pagbabagong ito sa loob ng Coding Agent. Kapag hinaharap ni Claude ang isang bug, kailangan niya hindi lang mag-generate ng solusyon sa pagbabago, kundi dapat din siyang magdesisyon kung anong mga file ang babasahin, anong call chain ang iisusunod, ilang posibleng hipotesis ang pipigilin, kung pipirmihin ang pagpapatakbo ng mga pagsubok, kung pipagpatuloy ang pagsusuri sa mga dependency, at kailan ituturing na sapat na ang ebidensya.

Ang mga aksyon na ito ay maaaring ituring na isang search tree. Mas mababang pagkakalagay ng computation ay nangangahulugan ng mas maagang pagpaputol ng mga sangay at mas mabilis na pagbuo ng pagpapasya; mas mataas na pagkakalagay ay nagpapahintulot sa model na patuloy na maghanap at mag-verify, na nagbabawas sa posibilidad ng pagpapatupad ng aksyon nang direkta kapag kulang ang ebidensya.

Mga link na pang-referensya: https://platform.claude.com/docs/en/build-with-claude/effort

Kaya effort ay hindi nagregula ng simpleng haba ng thinking, kundi kung gaano kalawak ang saklaw ng paghahanap na pinapayagan sa isang Agent task. Direktang nagbabago ito ng paghahati-hati ng modelo ni Anthropic.

Kung ang isang karaniwang coding task ay hindi na mahirap para sa Opus, pagkatapos ng pagtaas ng effort, malamang na mabilis na makapasok ang Opus sa performance plateau. Kahit may mas malakas na base model, ang Fable ay walang maraming natitirang hamon na maaaring i-convert sa malinaw na pagkakaiba sa user experience.

Ang user ay kailangang magbayad ng pagkakaiba sa presyo mula sa simula ng request. Kaya ang Fable ay mas madaling ipakita ang halaga nito sa pamamagitan ng mga gawain tulad ng mga hindi pamilyar na codebase, marami-stage na pagpaplano, paggamit ng iba’t ibang tool, habang nagpapatuloy nang malayang pagpapatupad, at mga gawain na kailangang muling maibalik pagkatapos magkaroon ng error.

Mga link na pang-referensya: https://www.anthropic.com/news/claude-opus-5

Ito ay nangangahulugan na ang mga bagay na ibinibenta ng mas mataas na antas na modelo ay nagbabago. Hindi na ito ibinibenta ang “mas malakas na sagot sa round na ito” lamang, kundi ang karagdagang kumpiyansa sa mas kumplikadong trajektoriya.

Ang problema ay ang ganitong kahusayan ay kailangang may sapat na haba ng gawain upang mabuo, at kapag pinahaba ang gawain, ang kakayahan ng modelo ay hindi na ang tanging desisyon, kundi ang kontekstwal na estado ay nagsisimula na maging sentro.

03

Nakikita ang 1M context, madaling isipin na ito ay isang malaking memorya ng trabaho, kaya naman mukhang lubos na hindi natural kapag gumagamit lang ng 200K o 300K token si Claude at nagsisimula nang mawala, paulit-ulit, o magkaroon ng kalituhan sa estado.

Ngunit ang context window ay sinusukat ang kapasidad, hindi ang pagkakasunod-sunod ng estado. Ang mahabang sesyon ng Agent ay hindi isang static na dokumento, kundi isang patuloy na idinadagdag na kasaysayan ng pagpapatupad.

Mga link na pang-referensya: https://platform.claude.com/docs/en/build-with-claude/context-windows

Maaaring baguhin ang isang file nang maraming beses; ang isang bug ay unang itinuturing na isyu sa cache, ngunit natuklasan na galing sa concurrency; maaaring mabigo ang isang pagsubok, sumunod ay umabot sa tagumpay, at muling mabigo dahil sa bagong pagbabago. Ang mga lumang nilalaman ay hindi aalisin nang awtomatiko habang nagbabago ang estado, at ang mga bagong nilalaman ay idinadagdag lamang sa dulo.

Ang problema dito ay hindi na lamang tungkol sa retrieval. Dapat ngang hanapin ng modelo ang mga impormasyon na may kinalaman sa kasalukuyang gawain, at kailangan din nito na matukoy kung ang mga impormasyong iyon ay patuloy pa ring epektibo.

Ang mga lumang bersyon ng mga punsiyon at mga bagong bersyon ng mga punsiyon ay napakalaking pagkakatulad, at ang mga lumang log ng pagsubok at mga bagong log ng pagsubok ay naglalaman ng maraming parehong token; ang mga napatunayang pagsusuri ay maaari ring magkaroon ng malaking kaugnayan sa semantiko sa kasalukuyang problema. Ang paghahanap ng mga nilalaman na ito ay hindi mahirap para sa Attention, ang hirap ay ang pagtukoy sa kanilang relasyon ng pagkakasakop.

Ang database ay maaaring panatilihin ang current state gamit ang version number, update time, transaction, at explicit fields, habang ang natural language context ay karaniwang walang ganitong istruktura. Mas malapit ito sa append-only log, kung saan kailangan ng model na muling buuin ang kasalukuyang kalagayan ng mundo mula sa pagkakasunod-sunod ng mga pangyayari.

Mga link na pang-referensya: https://platform.claude.com/docs/en/build-with-claude/context-windows

Kaya hindi direktang tumutugma ang kumplikadong kalikasan ng mahabang konteksto sa proporsyon ng paggamit ng token. Ang isang static na dokumento na may 250K token ay maaaring mas madaling tratuhin kaysa sa 250K token na kasaysayan ng Agent, dahil ang huli ay naglalaman ng maraming binago na mga bagay, pahinga na pagpapasya, mga resulta ng kasangkapan, at naging walang kwentang estado.

Ang pag-iisip ng kasaysayan ay magdudulot pa ng karagdagang kumplikasyon. Ang mga naka-save sa usapan ay hindi lang “ano ang nangyari”, kundi maaaring maglaman din ng “bakit ganun ang pagpapasya noong panahong iyon”. Kung ang maagang pag-iisip ay batay sa isang hipotesis na matapos ay nasira, ang pag-iisip na iyon ay maaari pa ring magpatuloy na makilahok sa mga susunod na pagpapasya dahil sa mataas na kaugnayan nito sa kasalukuyang problema.

Kaya ang tunay na limitasyon ng 1M context ay hindi lamang kung gaano karaming impormasyon ang maaaring ilagay, kundi kung paano pa rin nakakapag-restores ang modelo sa kasalukuyang bersyon habang lumalala ang bilang ng mga nakaraang bersyon ng isang parehong objekto.

04

Habang patuloy na lumalaki ang context, ang compaction ay tila isang natural na paraan: i-compact ang lumang kasaysayan, tapos magpatuloy sa pagpapatupad. Ngunit ang compaction sa mga skenaryo ng Agent ay iba sa karaniwang pagbuod.

Kapag iniiwanan ang isang halimbawa sa pagsusummary ng artikulo, ang epekto ay karaniwang ang kawalan ng kumpletong impormasyon; kapag ina-compress ang trahektorya ng Agent at iniiwanan ang isang patuloy na epektibong limitasyon, maaaring magbago nang direkta ang susunod na landas ng pagsasagawa.

Mga link na pang-referensya: https://platform.claude.com/cookbook/tool-use-context-engineering-context-engineering-tools

Dahil ang compaction ay dapat lutasin ang hindi “sino ang mahalaga,” kundi “sino ang kasalukuyang may bisa.” Maaaring magkaroon ng isang kasaysayan na may mga natapos na gawain, mga desisyon na binalewala, kasalukuyang may bisa na mga limitasyon sa interface, nabigo o naging obsolete na mga resulta ng pagsubok, at pansamantalang workaround. Kailangan ng compressor na muling ayusin ang mga panahon na ito upang mabuo ang isang representasyon na maaaring gamitin sa susunod na pagkakataon.

Kung ang “kasalukuyang inaasahan na ang problema ay galing sa cache” ay pinapadali bilang “ang problema ay galing sa cache,” ang pansamantalang aksiyon ay naging katotohanan; kung ang isang naitalang solusyon ay patuloy na sumasali sa buod, maaaring muli pang sundin ng mga susunod na Agent ang lumang landas; kung ang isang mahalagang limitasyon ay hindi sumasali sa buod, maaaring hindi na ito makikita ng model sa hinaharap.

Kaya ang pangunahing tukoy ng compaction ay hindi ang compression rate, kundi ang state fidelity. Ito rin ang dahilan kung bakit mahalaga ang Git, pagsubok, task files, memory, at structured handoff sa mga tagal na Agent.

Hindi ito simpleng pagdaragdag ng impormasyon na makikita ng modelo, kundi paglipat ng ilang estado na kailangang magpatuloy sa haba ng panahon mula sa kasaysayang natural na wika patungo sa panlabas na sistema. Ang Git ay nagtatakda ng kasalukuyang bersyon ng code, ang pagsubok ay nagbibigay ng makikita at ma-verify na resulta, ang mga file ng gawain ay nagsasalaysay ng kalagayan ng pagkumpleto, at ang structured state ay naghihiwalay sa kasalukuyang konklusyon at mga nakaraang pagsubok.

Ang konteksto ay maaaring manatili na may mayamang kasaysayan, ngunit hindi dapat magdala ng buong responsibilidad sa pagpapamahala ng estado sa matagal.

Mga link na pang-referensya: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

05

Ang mga nakaraang ilang tanong ay maaari pa ring maunawaan bilang kung paano ang modelo ay nagtratrabaho sa input. Lumalampas pa ang Agent, dahil ito ay aktibong nagbabago sa kapaligiran.

Sa ordinaryong usapan, ang pagkakamali ng modelong isang beses ay nananatili sa output text. Ang Agent ay maaaring baguhin ang code, patakbuhin ang mga utos, i-install ang mga dependency, i-ayos ang configuration, at basahin ang mga bagong resulta na nagmumula sa mga aksyong ito.

Kaya hindi na lang ito pagkakamali sa paghuhusga, kundi maging pagbabago sa kaligiran. Ipalagay na kinuha ni Claude ang isang bug bilang isang problema sa cache, kaya binago niya ang logika ng cache, ang mekanismo ng pag-uulit, at ilang mga punto ng pagtawag. Pagkatapos ay lumabas ang isang serye ng mga bagong anomaliya sa pagsubok.

Ang mga anomaliya na ito ay totoo, ngunit hindi ito natural na nagmula sa orihinal na bug, kundi gawa ng nakaraang pagbabago. Ito ay magdudulot sa Agent ng isang partikular na mode ng pagkabigo: ang modelo ay nagsisimulang analisahin ang sariling nilikhang distribusyon ng data.

Mga link na pang-referensya: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

Kung makakakilala ito ng “nagmula sa mga bagong error pagkatapos ng nakaraang pagbabago,” maaari itong i-rollback at i-recheck ang orihinal na aksiyon; kung hindi nabuo ang kaugnayang ito, maaari itong patuloy na ituring ang mga bagong error bilang mga independiyenteng problema at i-patch ang bawat isa.

Sa kasalukuyan, bawat hakbang na lokal ay maaaring may batayan, ngunit ang buong trahektorya ng gawain ay nagsilbi nang palayo sa orihinal na tanong. Kaya ang kumpiyansa ng mahabang Agent ay hindi maaaring batay lamang sa pagkakatama sa bawat hakbang. Mas mahalaga ang kakayahan ng sistema na masuri, i-attribute, at muling mabawi kapag nagkakaroon ng pagkakamali sa loob ng kapaligiran.

Ang git diff ay maaaring sabihin sa model kung anong mga pagbabago ang nangyari kaagad, ang mga pagsubok ay maaaring patunayan kung ang isang pag-uugali ay nasira o hindi, ang checkpoint at rollback ay maaaring limitahan ang pagkalat ng pagkakamali, habang ang independent evaluator ay maaaring magbigay ng karagdagang pagsusuri sa labas ng sariling paliwanag ng model.

Ang layunin ng mga komponenteng ito ay sa pangkabuuang pagbibigay ng kakayahang mag-correction sa sarili sa Agent.

Mga link na pang-referensya: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

06

Maraming benchmark ang tumatalakay sa sumusunod: Kaya ba ng modelo na matapos ang gawain sa isang naka-initialize na kaligiran? Ang totoong Agent ay may karagdagang hirap: ang kaligiran ay patuloy na nagbabago batay sa sariling aksyon ng modelo. Kaya, kahit na dalawang modelo ay may malapit na rate ng pagkakatapos, ang kanilang totoong karanasan ay maaaring lubos na magkaiba.

Isang modelo ay maaaring maging napakatumpak sa unang bahagi, ngunit kung mali na, patuloy na gagawa ng mga pagpapabuti sa maling landas; samantalang ang isang iba pang modelo ay hindi laging mas malakas sa bawat hakbang, ngunit mas mabilis itong makikita kung ang isang pagbabago ay nagdulot ng bagong problema, at pagkatapos ay magrereverse at pipili muli ng landas.

Mahirap ibigay ang pagkakaiba sa pagitan ng dalawang pag-uugali batay lamang sa katapusan. Kung patuloy na papalawakin ang mga gawain ng Agent, mas makabuluhang mga indikador ay ang dami ng mahahalagang estado na nakapagpanatili pagkatapos ng compaction, kung maaaring makahanap ng mga hakbang na nagdulot ng error pagkatapos ng maliwang pagbabago, kung patuloy bang nagkakaroon ng pagkakatugma ang loob na estado ng gawain sa totoong kapaligiran habang dumadami ang pagtawag sa mga kasangkapan, at kung gaano karaming gastos ang kailangan upang mabawi kapag nangyari ang paglihis.

Hindi ito sinusukat kung gaano katalino ang isang response, kundi kung maaari bang panatilihin ang kontrol sa isang trajectory.

Sa kabuuan, ang ilang uri ng problema na inilabas ng Anthropic ay nasa iba't ibang antas. Pagkatapos makalap ang mga problema na ito, ang teknikal na hangganan ni Claude ay nagsisimulang magbago.

Kahit na dati ay mas nagsisilbing tanong kung ang modelo ay kayang sagutin ang isang partikular na tanong, ngayon ay mas mahirap ang isang bagay: kung paano pa rin makakapanatili ang sistema ng isang kredible na kasalukuyang mundo pagkatapos ng ilang oras ng pagpapatakbo, ilang dosenang pagtawag sa mga kasangkapan, ilang pag-compress ng estado, at maraming pagbabago sa code.

Patuloy na lumalago ang kakayahan ng modelo, at tanging nagpapataas ng bawat hakbang na paghuhusga. Ang kakayahan ng matagal na Agent na magtrabaho nang tama ay patuloy na nakasalalay sa isang iba pang set ng kakayahan: kung malinaw ang estado, kung maaaring i-verify ang mga aksyon, at kung maaaring i-rollback ang mga pagkakamali.