Kódolótársak testreszabása szervezetek számára | Amazon webszolgáltatások

A kódoló társaknak szánt generatív AI-modellek többnyire nyilvánosan elérhető forráskódon és természetes nyelvű szövegeken alapulnak. Míg a betanító korpusz nagy mérete lehetővé teszi, hogy a modellek kódot generáljanak az általánosan használt funkciókhoz, ezek a modellek nem ismerik a privát tárolókban található kódot és a kapcsolódó kódolási stílusokat, amelyeket a velük való fejlesztés során kényszerítenek ki. Következésképpen a generált javaslatok átírást igényelhetnek, mielőtt alkalmasak lennének egy belső adattárba való beépítésre.

Kiküszöbölhetjük ezt a hiányosságot, és minimalizálhatjuk a további kézi szerkesztést, ha beágyazzuk a privát adattárakból származó kódtudást egy nyilvános kódra oktatott nyelvi modellbe. Ezért fejlesztettünk ki egy testreszabási lehetőséget Amazon Code Whisperer. Ebben a bejegyzésben két lehetséges módot mutatunk be a kódolási kísérők testreszabására a kibővített visszakeresés és a finomhangolás segítségével.

A CodeWhisperer testreszabási képességével az a célunk, hogy lehetővé tegyük a szervezetek számára a CodeWhisperer modell testreszabását privát adattárak és könyvtáraik segítségével, hogy szervezet-specifikus kódjavaslatokat hozzanak létre, amelyek időt takarítanak meg, követik a szervezeti stílust és konvenciókat, és elkerülik a hibákat és a biztonsági réseket. Ez előnyös a vállalati szoftverfejlesztés számára, és segít leküzdeni a következő kihívásokat:

1. Ritka dokumentáció vagy információ a belső könyvtárakhoz és API-khoz, amelyek arra kényszerítik a fejlesztőket, hogy időt töltsenek a korábban megírt kód vizsgálatával a használat megismétlése érdekében.
2. A vállalatspecifikus kódolási gyakorlatok, stílusok és minták tudatosságának és következetességének hiánya.
3. Elavult kód és API-k véletlenszerű használata a fejlesztők részéről.

Ha belső kódtárakat használ további képzésekhez, amelyek már átestek a kódellenőrzésen, a nyelvi modell felszínre hozhatja a belső API-k és kódblokkok használatát, amelyek kiküszöbölik az előző problémalistát. Mivel a referenciakódot már felülvizsgálták, és megfelel az ügyfél magas mércéjének, a hibák vagy biztonsági rések bevezetésének valószínűsége is minimális. A testreszabáshoz használt forrásfájlok gondos kiválasztásával pedig a szervezetek csökkenthetik az elavult kódok használatát.

Tervezési kihívások

A kódjavaslatok testreszabása egy szervezet privát adattárai alapján számos érdekes tervezési kihívással jár. A nagy nyelvi modellek (LLM) telepítése a kódjavaslatok felületére fix költségekkel jár a rendelkezésre állás és a generált tokenek számán alapuló következtetés miatt változó költségekkel. Ezért rendkívül költséges lehet minden ügyfél számára külön testreszabás és azok külön-külön történő elhelyezése, ami további fix költségeket jelent. Másrészt, ha ugyanazon a rendszeren egyszerre több testreszabást végez, több bérlős infrastruktúrára van szükség ahhoz, hogy minden egyes ügyfél számára elkülönítsék a saját kódot. Ezen túlmenően a testreszabási képességnek olyan gombokat kell felszínre hoznia, amelyek lehetővé teszik a megfelelő betanítási részhalmaz kiválasztását a belső tárolóból különböző mérőszámok használatával (például kevesebb hiba előzményével rendelkező fájlok vagy a közelmúltban a tárolóba véglegesített kód). A kód ezen mérőszámok alapján történő kiválasztásával a testreszabás betanítható jobb minőségű kóddal, amely javíthatja a kódjavaslatok minőségét. Végül, még a folyamatosan fejlődő kódtárak mellett is, a testreszabással kapcsolatos költségeknek minimálisnak kell lenniük ahhoz, hogy a vállalatok költségmegtakarítást érjenek el a megnövekedett fejlesztői termelékenység révén.

A testreszabás kiépítésének alapvetõ megközelítése lehet a modell elõtanítása egyetlen képzési korpuszon, amely a (nyilvános) elõképzési adatkészletbõl és a (magán) vállalati kódból áll. Noha ez a megközelítés a gyakorlatban működik, (redundáns) egyéni előképzést igényel a nyilvános adatkészlet felhasználásával minden vállalatnál. Ezenkívül redundáns üzembe helyezési költségekre van szükség, amelyek egy személyre szabott modell tárolásával kapcsolatosak minden egyes ügyfél számára, amely csak az ügyféltől származó ügyfélkéréseket szolgálja ki. A nyilvános és privát kód képzésének szétválasztásával és a testreszabás több bérlős rendszeren történő telepítésével ezek a redundáns költségek elkerülhetők.

Hogyan testreszabható

Magas szinten kétféle testreszabási technika létezik: a visszakeresés-bővített generálás (RAG) és a finomhangolás (FT).

• Visszakereséssel bővített generáció: A RAG megkeresi az egyező kódrészleteket egy adott kódrészlethez hasonló tárolóban (például olyan kódot, amely közvetlenül megelőzi a kurzort az IDE-ben), és ezekkel az egyező kódrészletekkel kiegészíti az LLM lekérdezéséhez használt promptot. Ez gazdagítja a felszólítást, hogy segítse a modellt relevánsabb kód generálására ösztönözni. A szakirodalomban van néhány ilyen irányú technikát. Lát Retrieval-Augmented Generation tudásintenzív NLP-feladatokhoz, BIRODALOM, kNN-LM és a RETRO.

• Finomhangolás: Az FT vesz egy előre betanított LLM-et, és továbbtanítja egy meghatározott, kisebb kódbázison (az előképzési adatkészlethez képest), hogy a megfelelő tárhelyhez igazítsa. A finomhangolás ezen képzés alapján állítja be az LLM súlyait, így jobban igazodik a szervezet egyedi igényeihez.

Mind a RAG, mind a finomhangolás hatékony eszközök az LLM-alapú testreszabás teljesítményének fokozására. A RAG gyorsan tud alkalmazkodni a magánkönyvtárakhoz vagy API-khoz, alacsonyabb képzési bonyolultsággal és költséggel. A lekért kódrészletek promptba történő keresése és kiegészítése azonban növeli a várakozási időt a futásidőben. Ehelyett a finomhangolás nem igényli a kontextus kiegészítését, mivel a modellt már betanították a privát könyvtárakra és API-kra. Ez azonban magasabb képzési költségekhez és a modell kiszolgálásának bonyolultságához vezet, ha több egyedi modellt kell támogatni több vállalati ügyfélnél. Amint azt később tárgyaljuk, ezek az aggályok a megközelítés további optimalizálásával orvosolhatók.

Visszakeresés kiterjesztett generáció

A RAG néhány lépést tartalmaz:

Indexelés

Ha az adminisztrátor bemenetként egy privát adattárat ad meg, akkor a forráskódfájlok darabokra bontásával index jön létre. Egyszerűen fogalmazva, a darabolás a kódrészleteket emészthető darabokká változtatja, amelyek valószínűleg a leginkább informatívak a modell számára, és a kontextus alapján könnyen visszakereshetők. A darab mérete és a fájlból való kibontás módja olyan tervezési döntések, amelyek befolyásolják a végeredményt. Például a darabok feloszthatók kódsorok vagy szintaktikai blokkok alapján stb.

Rendszergazda munkafolyamat

Kontextus szerinti keresés

Keressen indexelt kódrészletek készletében a kurzor feletti néhány kódsor alapján, és kérje le a megfelelő kódrészleteket. Ez a visszakeresés különböző algoritmusok használatával történhet. Ezek a lehetőségek a következőket tartalmazhatják:

• Szavacska (BM25) - Szavakból álló visszakereső funkció, amely a lekérdezési kifejezések gyakorisága és a kódrészletek hossza alapján rangsorolja a kódrészletek készletét.

BM25 alapú visszakeresés

A következő ábra a BM25 működését szemlélteti. A BM25 használatához először egy fordított indexet kell létrehozni. Ez egy olyan adatstruktúra, amely különböző kifejezéseket társít azokhoz a kódrészletekhez, amelyekben ezek a kifejezések előfordulnak. A keresés során a lekérdezésben szereplő kifejezések alapján keresünk kódrészleteket, és a gyakoriság alapján pontozzuk őket.

Szemantikai visszakeresés

A BM25 a lexikális egyeztetésre összpontosít. Ezért az „add” helyett a „delete” előfordulhat, hogy a lekérdezésben szereplő kifejezések alapján nem változtatja meg a BM25 pontszámot, de a lekért funkcionalitás az ellenkezője lehet a szükségesnek. Ezzel szemben a szemantikai visszakeresés a kódrészlet funkcionalitására összpontosít, annak ellenére, hogy a változó- és API-nevek eltérőek lehetnek. Jellemzően a BM25 és a szemantikai lekérdezések kombinációja jól működik együtt a jobb eredmények érdekében.

Kiterjesztett következtetés

Amikor a fejlesztők kódot írnak, a meglévő programjukat használják egy lekérdezés megfogalmazására, amelyet elküldenek a visszakeresési indexnek. Miután lekértünk több kódrészletet a fent tárgyalt technikák valamelyikével, az eredeti prompt elé fűzzük őket. Itt számos tervezési lehetőség közül választhat, beleértve a lekérendő töredékek számát, a kódrészletek relatív elhelyezését a promptban és a kódrészlet méretét. A végső tervezési választást elsősorban az empirikus megfigyelés vezérli, amely a mögöttes nyelvi modellel különböző megközelítéseket vizsgál, és kulcsszerepet játszik a megközelítés pontosságának meghatározásában. A visszaadott darabok tartalmát és az eredeti kódot egyesítik, és elküldik a modellnek, hogy testreszabott kódjavaslatokat kapjanak.

Fejlesztői munkafolyamat

Finomhangolás:

Finomhangolás nyelvi modell készül transzfer tanulás amelyben egy előre betanított modell súlyait új adatokra tanítják. A cél az, hogy egy nagy korpuszon már betanított modellből megőrizzük a megfelelő tudást, és az új korpuszból – esetünkben egy új kódbázisból – finomítsunk, helyettesítsünk vagy új ismereteket adjunk hozzá. Egyszerűen egy új kódbázison való betanítás vezet katasztrofális felejtés. Például a nyelvi modell lehet „elfelejti” a biztonsággal kapcsolatos tudását vagy a vállalati kódbázisban eddig ritkán használt API-k. Különféle technikák vannak, mint pl élmény visszajátszás, GEMés PP-TF amelyeket ennek a kihívásnak a kezelésére alkalmaznak.

Finomhangolás

A finomhangolásnak két módja van. Az egyik megközelítés a további adatok felhasználása a modell finomhangolására vonatkozó prompt kiegészítése nélkül. Egy másik megközelítés a prompt kiegészítése a finomhangolás során a vonatkozó kódjavaslatok lekérésével. Ez segít javítani a modell azon képességét, hogy jobb javaslatokat adjon a lekért kódrészletek jelenlétében. A modellt a betanítás után kiértékeljük a példasoron. Ezt követően a testreszabott modellt telepítik, és használják a kódjavaslatok generálására.

Annak ellenére, hogy a dedikált LLM-ek használata előnyökkel jár a kód generálására a magántárolókban, a költségek túl magasak lehetnek a kis- és közepes méretű szervezetek számára. Ennek az az oka, hogy dedikált számítási erőforrásokra van szükség, még akkor is, ha ezek a csapatok méretéből adódóan alul vannak kihasználva. A költséghatékonyság elérésének egyik módja több modell kiszolgálása ugyanazon a számítógépen (például SageMaker több bérlés). A nyelvi modellek azonban egy vagy több dedikált GPU-t igényelnek több zónában a késleltetési és átviteli korlátok kezelésére. Ezért a teljes modelltárhely több bérlése minden GPU-n megvalósíthatatlan.

Kiküszöbölhetjük ezt a problémát, ha több ügyfelet szolgálunk ki ugyanazon a számítástechnikán, a kicsi használatával adapterek az LLM-nek. Paraméter-hatékony finomhangolási (PEFT) technikák, mint pl azonnali hangolás, előtag hangolásaés alacsony rangú adaptáció (LoRA) a képzési költségek csökkentésére használják a pontosság elvesztése nélkül. A LoRA különösen nagy sikereket ért el a teljes modell finomhangolásánál hasonló (vagy jobb) pontosság elérésében. Az alapötlet egy alacsony rangú mátrix tervezése, amelyet azután hozzáadunk a mátrixokhoz a modell megcélzott rétegeinek eredeti mátrixsúlyával. Általában ezeket az adaptereket az eredeti modellsúlyokkal egyesítik a kiszolgáláshoz. Ez az eredeti neurális hálózat méretéhez és architektúrájához vezet. Az adaptereket külön tartva ugyanazt az alapmodellt több modelladapterrel is ki tudjuk szolgálni. Ez visszahozza a méretgazdaságosságot kis- és közepes ügyfeleink számára.

Alacsony szintű adaptáció (LoRA)

A testreszabás hatékonyságának mérése

Kiértékelési mérőszámokra van szükségünk a testreszabott megoldás hatékonyságának felméréséhez. Az offline értékelési mérőszámok védőkorlátként szolgálnak az alapértelmezett modellhez képest alacsonyabb szintű szállítási testreszabások ellen. Ha a megadott tárhelyen belüli tárolt adatkészletből adatkészleteket épít fel, a testreszabási megközelítés alkalmazható erre az adatkészletre a hatékonyság mérésére. A meglévő forráskód és a testreszabott kódjavaslat összehasonlítása számszerűsíti a testreszabás hasznosságát. Az ehhez a számszerűsítéshez használt általános mérőszámok közé tartoznak például a mérőszámok hasonlóság szerkesztése, pontos egyezés, és CodeBLEU.

A hasznosság mérhető úgy is, hogy számszerűsíti, hogy a testreszabás milyen gyakran hívja meg a belső API-kat, és összehasonlítja azt a már meglévő forrásban lévő meghívással. Természetesen mindkét szempont helyessége fontos a sikeres befejezéshez. Testreszabási megközelítésünkhöz egy személyre szabott mérőszámot terveztünk, amelyet testreszabási minőségi indexként (CQI) ismerünk, amely egyetlen felhasználóbarát mérőszám 1 és 10 között van. A CQI mérőszám megmutatja a testreszabott modell javaslatainak hasznosságát a kódhoz képest. javaslatokat általános nyilvános modellel.

Összegzésként

Az Amazon CodeWhisperer testreszabási képességét az ebben a blogbejegyzésben tárgyalt vezető technikai technikák keveréke alapján építettük ki, és a Persistent Systems által a fejlesztők termelékenységéről végzett felhasználói tanulmányokkal értékeltük ki. Ebben a két, az AWS megbízásából készült tanulmányban a fejlesztőket arra kérték, hogy hozzanak létre egy olyan orvosi szoftveralkalmazást Java nyelven, amelyhez belső könyvtáraik használatára volt szükség. Az első vizsgálatban azoknak a fejlesztőknek, akik nem fértek hozzá a CodeWhispererhez, (átlagosan) ~8.2 órát vett igénybe a feladat végrehajtása, míg a CodeWhisperert használóknak (testreszabás nélkül) 62 százalékkal gyorsabban (átlagosan) ~3.1 óra alatt végezték el a feladatot.

A másik, más fejlesztői csoportokkal végzett vizsgálatban a saját kódbázisukkal testreszabott CodeWhisperert használó fejlesztők átlagosan 2.5 óra alatt végezték el a feladatot, 28 százalékkal gyorsabban, mint azok, akik testreszabás nélkül használták a CodeWhisperert, és ~3.5 alatt végezték el a feladatot. átlagosan óra. Meggyőződésünk, hogy az olyan eszközök, mint a CodeWhisperer, amelyek az Ön kódbázisához vannak szabva, kulcsszerepet játszanak a fejlesztői produktivitás további növelésében, ezért javasoljuk, hogy futtassák be. További információért és a kezdéshez látogassa meg a Amazon CodeWhisperer oldal.

---

A szerzőkről

Qing Sun az AWS AI Labs vezető alkalmazott tudósa, és az AWS CodeWhispereren, egy generatív mesterséges intelligencia-alapú kódolási asszisztensen dolgozik. Kutatási területe a természetes nyelvi feldolgozás, az AI4Code és a generatív mesterséges intelligencia. Korábban számos NLP-alapú szolgáltatáson dolgozott, például a Comprehend Medicalon, az Amazon Health AI orvosi diagnosztikai rendszerén és a Meta AI gépi fordítási rendszerén. 2017-ben doktorált a Virginia Tech-en.

Arash Farahani az Amazon CodeWhisperer alkalmazott tudósa. Jelenlegi érdeklődési köre a generatív mesterséges intelligencia, a keresés és a személyre szabás. Arash szenvedélyesen épít olyan megoldásokat, amelyek megoldják a fejlesztők problémáit. Számos funkción dolgozott a CodeWhispereren belül, és bevezette az NLP-megoldásokat különböző belső munkafolyamatokba, amelyek minden Amazon-fejlesztőt érintenek. 2017-ben szerzett PhD fokozatot az Illinoisi Egyetemen, Urbana-Champaignben.

Xiaofei Ma az AWS AI Labs alkalmazott tudományos menedzsere. 2016-ban csatlakozott az Amazonhoz, mint alkalmazott tudós a SCOT szervezeten belül, majd 2018-ban az AWS AI Labshoz, és az Amazon Kendrán dolgozott. Xiaofei számos szolgáltatás tudományos menedzsereként szolgált, köztük a Kendra, a Contact Lens, legutóbb pedig a CodeWhisperer és a CodeGuru Security. Kutatási érdeklődése az AI4Code és a Natural Language Processing területéhez fűződik. 2010-ben doktorált a Maryland Egyetemen, College Parkban.

Murali Krishna Ramanathan az AWS AI Labs vezető alkalmazott tudósa, és társvezetője az AWS CodeWhisperer, egy generatív AI-alapú kódolótárs. Szenvedélyesen fejleszti a szoftvereszközöket és munkafolyamatokat, amelyek elősegítik a fejlesztői termelékenység javítását. Korábban megépítette a Piranhát, egy automatizált átalakítási eszközt, amellyel törölheti a kódot az elavult funkciójelzők és az Uber mérnökei által vezetett kódminőségi kezdeményezések miatt. A Google kari díja (2015), az ACM SIGSOFT Distinguished Paper Award (ISSTA 2016) és a Maurice Halstead-díj (Purdue 2006) kitüntetettje. 2008-ban szerzett PhD fokozatot számítástechnikából a Purdue Egyetemen.

Ramesh Nallapati az AWS AI Labs vezető alkalmazott tudósa, és társvezetője a CodeWhisperer, egy generatív mesterséges intelligencia-alapú kódolótárs, valamint a Titan Large Language Models az AWS-nél. Érdeklődési köre elsősorban a természetes nyelvi feldolgozás és a generatív mesterséges intelligencia területe. A múltban a Ramesh tudományos vezető szerepet töltött be számos NLP-alapú AWS-termék, például a Kendra, a Quicksight Q és a Kontaktlencse szállításában. Kutatói pozíciókat töltött be a Stanfordnál, a CMU-nál és az IBM Researchnél, és Ph.D fokozatot szerzett. Számítástechnika szakon a Massachusetts Amherst Egyetemen 2006-ban.

• SEO által támogatott tartalom és PR terjesztés. Erősödjön még ma.
• PlatoData.Network Vertical Generative Ai. Erősítse meg magát. Hozzáférés itt.
• PlatoAiStream. Web3 Intelligence. Felerősített tudás. Hozzáférés itt.
• PlatoESG. Carbon, CleanTech, Energia, Környezet, Nap, Hulladékgazdálkodás. Hozzáférés itt.
• PlatoHealth. Biotechnológiai és klinikai vizsgálatok intelligencia. Hozzáférés itt.
• Forrás: https://aws.amazon.com/blogs/machine-learning/customizing-coding-companions-for-organizations/