MI-hivatkozási tanulmány: hivatkozik-e az MI a(z) GitHub oldalra?

A GitHub szigorú értelemben vett elsődleges forrás: oldalait maguk a szoftvert építő emberek írják. A README elmagyarázza, mit csinál a projekt, a kiadási oldal leírja, mi változott az egyes verziókban, a hibakövető pedig megmutatja, mely hibák ismertek és javították-e őket. Az AI-modellek ezeket az oldalakat bizonyítékként kezelik, amikor egy eszközt írnak le.

A válaszokban négyfajta GitHub-oldal szokott felbukkanni:

• Tárolók főoldalai, amelyek README-je a nyílt forráskódú projekt hivatalos leírásaként működik.
• Kiadások és változásnaplók, olyan kérdéseknél, mint a „mi a legújabb verzió” vagy a „mikor került be ez a funkció”.
• Hibajegyek és viták, akkor idézve, ha valaki egy hibáról, korlátról vagy megkerülő megoldásról kérdez.
• A GitHub Advisory Database biztonsági figyelmeztetései, amelyek a nyílt forráskódú csomagok ismert sebezhetőségeit dokumentálják.

A szervezeti profilok is számítanak. Az a cég, amely SDK-it, bővítményeit vagy integrációit egy nyilvános GitHub-szervezetben tartja, az AI-modelleknek ellenőrizhető nyomot ad arra, hogy a terméke létezik és karbantartott.

A hivatkozások technikai szándékok köré csoportosulnak. Tipikus kérdések: „nyílt forráskódú alternatíva a Jirához”, „hogyan telepítsem a Stripe CLI-t”, „karbantartják-e még ezt az npm-csomagot”, „a legjobb saját szerverre telepíthető jelszókezelő” vagy „hogyan javítsam a Log4j-sebezhetőséget”. Mindegyik esetben a tároló a legközvetlenebb bizonyíték, amit egy asszisztens felmutathat.

A mindennapi üzletekre vonatkozó kérdések ritkán jutnak el a GitHubig. Senkinek sincs szüksége tárolóra ahhoz, hogy megtalálja a „megbízható vízvezeték-szerelőt Lyonban” vagy a „legjobb könyvelőirodát egy startupnak”. Ennek következtében a GitHub-hivatkozások a szoftverkiadókra, a kiberbiztonsági szállítókra és az IT-szolgáltató cégekre vonatkozó kérdésekre összpontosulnak, más szektorokban pedig elenyészők maradnak.

A nyelvnek is szerepe van. A GitHubon található dokumentáció túlnyomórészt angolul íródik, ezért az angol nyelvű válaszok sokkal természetesebben jutnak el hozzá, mint a francia, német vagy spanyol nyelvűek, amelyek inkább fordított oktatóanyagokra vagy helyi médiára hivatkoznak.

A különbség nagy része abban rejlik, hogyan keresi meg az egyes modellek az információt. A Gemini sok válaszát a Google Keresésre alapozza, ahol a tárolók jól szerepelnek a projektnevekre keresve, így a GitHub-link a válasszal együtt megjelenhet. A ChatGPT a tanítás során megtanultakat a ChatGPT-keresés élő találataival ötvözi, és tárolóra mutató linket főleg akkor csatol, ha a kérdés egy konkrét projektet nevez meg.

A Perplexity minden kérdésnél webes keresést végez és felsorolja a forrásait, összehasonlító kérdéseknél azonban gyakran inkább szakmai cikkekre és gyártói oldalakra támaszkodik, mint nyers tárolókra. A Grok az X-ről származó bejegyzéseket is hozzáad, ahol a fejlesztők bejelentik a kiadásokat és hibákról beszélgetnek. A Claude alapértelmezetten ritkábban hivatkozik forrásokra, és hajlamos a projektet saját szavaival leírni, hacsak nincs bekapcsolva a webes keresés.

A GitHub befolyásának egy része nem látszik a hivatkozásszámokban. A GitHubon tárolt nyilvános kód és dokumentáció sok nagy modell tanítóadatába kerül, így egy asszisztens úgy is elmagyarázhat egy könyvtár működését, hogy nem nevezi meg az oldalt, ahonnan tanulta.

Itt a hivatkozás azt jelenti, hogy a válasz forrásként a github.com egy oldalát adta meg: egy tárolót, egy hibajegyet, egy figyelmeztetést vagy a GitHub dokumentációját. Az olyan tanács, mint a „tárold a kódodat a GitHubon”, link nélkül a szolgáltatás ajánlása, egy másfajta jel, amelyet ez az arány nem mér.

A GitHub Pages-szel készült oldalak github.io-címen vagy saját domainen élnek, ezért érdemes őket önálló weboldalakként olvasni. Egy márka számára az értékes eset az, ha saját tárolója megjelenik a kategóriájáról szóló válaszban: olyan műszaki hivatkozás, amelyet az asszisztens ellenőrizni tud, ami a marketingoldalaknak ritkán sikerül.