uutiset

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Koneen sydänraportti

Toimittaja: Du Wei, Zenan

Suurten mallien turvallisuudessa voidaan sanoa olevan "paljon parantamisen varaa".

Tekoälyguru Andrej Karpathy on täällä taas popularisoimassa tiedetietoa. Tällä kertaa teemana on ".Erikoistunnisteiden käyttäminen SQL-injektion kaltaisten hyökkäysten suorittamiseen LLM:ää vastaan」。

Ns. SQL-injektiohyökkäys on verkkohyökkäystekniikka. Hyökkääjä huijaa taustatietokantaa suorittamaan haitallisia SQL-käskyjä lisäämällä ne sovelluksen syöttökenttiin. Tämäntyyppinen hyökkäys yleensä hyödyntää sovelluksen virheellistä käyttäjän syötteiden käsittelyä, kuten syötteiden suodattamatta tai pakottamista, jolloin hyökkääjä voi käyttää, muokata tai jopa poistaa tietokannan tietoja.

Ihmisten kasvavan tietoturvatietoisuuden vuoksi SQL-injektiota ei pitäisi tällä hetkellä esiintyä useimmissa ohjelmistotuotteissa.

Mutta suurten mallien maailmassa kaikki on vielä lapsenkengissään. LLM-tunniste on vastuussa syöttömerkkijonon erityisten merkkien (kuten <|endoftext|> jne.) jäsentämisestä. Vaikka tämä saattaa tuntua kätevältä, se voi parhaimmillaan johtaa virhearvioihin ja pahimmillaan LLM-tietoturvahaavoittuvuuteen, joka vastaa SQL-injektiohyökkäystä.

Tässä on tärkeää huomata: käyttäjän syöttämät merkkijonot ovat epäluotettavia tietoja.

SQL-injektiossa voit käyttää "DROP TABLE" -hyökkäystä rikkoaksesi huonon koodin. Sama ongelma kohdataan LLM:ssä. Huono koodi jäsentää merkkijonon erikoistunnisteen todelliseksi erikoistunnisteeksi, mikä sekoittaa syöteesityksen, jolloin LLM ei pysty jakamaan chat-malleja.

Alla on esimerkki nykyisestä huggingface Llama 3 -tokenisaattorin oletusarvosta.

Kuten näet, kaksi epäintuitiivista tilannetta esiintyy samanaikaisesti:

• <|begin_of_text|> -tunnus (128000) lisätään sekvenssin etuosaan
• <|end_of_text|> -tunnus (128001) jäsennetään merkkijonosta ja erityinen merkki lisätään. Nyt teksti (mahdollisesti käyttäjältä) voidaan sekoittaa token-protokollaan ja aiheuttaa LLM:n epäonnistumisen jakelussa, mikä johtaa määrittelemättömään tulosteeseen.

Siksi Karpathy suosittelee aina käyttämään kahta ylimääräistä lippua tokenointitoimintoihin, poistamaan käytöstä add_special_tokens=False ja split_special_tokens=True ja lisäämään itse koodiin erikoismerkkejä. Hän ajatteli, että näiden kahden vaihtoehdon nimeäminen olisi hieman hämmentävää. Chat-mallissa voit käyttää myös chat-mallia apply_chat_template.

Toimimalla edellä, saat jotain oikeampaa nähdä. Esimerkiksi <|tekstin_loppu|> käsitellään nyt kuten mitä tahansa muuta merkkijonosarjaa ja jaetaan taustalla olevalla BPE-tunnisteella aivan kuten mikä tahansa muu merkkijono.

Karpathy uskoo, että koodaus- ja dekoodauskutsut eivät saa koskaan jäsentää merkkijonoja erityisten tokenien käsittelemiseksi, ja meidän on poistettava tämä toiminto kokonaan. Sen sijaan ne tulisi lisätä vain erikseen ja ohjelmallisesti erillisen koodipolun kautta. Tiktokenissa käytä aina encode_ordinarya huggingfacessa, on turvallisempaa käyttää yllä mainittua lippua. Ole ainakin tietoinen tästä ongelmasta ja pidä aina tunnuksesi näkyvissä ja testaa koodisi.

Karpathy uskoo, että nämä asiat ovat erittäin hienovaraisia ​​ja huonosti dokumentoituja, ja hän arvioi, että noin 50 %:ssa koodista on nyt yllämainittujen ongelmien aiheuttamia bugeja.

Jopa ChatGPT:llä, joka on käynyt läpi tiukat testit ennen tehtaalta lähtöä, on outoja ongelmia. Parhaimmillaan se vain poistaa tunnuksen, pahimmillaan se hämmentää LLM:ää määrittelemättömällä tavalla. Karpathy ei tiennyt mitä kulissien takana tapahtui, mutta ChatGPT ei voinut lähettää hänelle merkkijonoa <|endoftext|> toistuvasti. Joten kiinnitä tähän erityistä huomiota.

Heti kun Andrej Karpathyn artikkeli ilmestyi, se herätti heti keskustelua. Joku kysyi: Mihin toimiin LLM-kehittäjien on ryhdyttävä parantaakseen turvallisuutta?

Karpathyn mielestä se on helppo sanoa, merkitse vain merkkijonot aina "normaalilla" tavalla, eli utf8-tavusekvenssit. Tämä muistuttaa turvallisuuden "pienimmän etuoikeuden" periaatetta - olennaisesti rajoittamalla toiminnallisuus siihen, mikä on ehdottoman välttämätöntä, minimoit tahattomien seurausten mahdollisuuden.

Jotkut ihmiset sanoivat myös: "Olemme jo menossa tähän suuntaan." Lucas Beyer, VLM-mallin PaliGemma kirjoittaja ja Google DeepMind -tutkija, sanoi, että olemme parantaneet suojausmekanismia uudessa työkoodissa, mikä tulee olemaan hieman hankalaa, varsinkin kun tuetaan useita tokenizerejä, mutta kaiken kaikkiaan se on sen arvoista. Se myös tekee koodista selkeämmän.

Jotkut nettikäyttäjät kysyivät myös, mitä tapahtuu, jos koodi on oikea, mutta <|endoftext|> syötetään koulutuksen aikana?

Karpathy sanoi, että jos koodi on oikea, mitään ei tapahdu. Mutta ongelmana on, että suuri osa koodista ei ehkä ole oikein, mikä voi hiljaa tuhota suuren mallin maailmankuvan.

Mitä mieltä olet Karpathyn löytämistä uusista ongelmista?

Viitesisältö:

https://twitter.com/karpathy/status/1823418177197646104