Körülbelül három hónappal ezelőtt elindult a Papers with Code újbóli megújítása, amelynek célja az open AI-kutatás hozzáférhetővé és könnyen feldolgozhatóvá tétele: hogy a felhasználók gyorsan megtalálják egy cikkhez kapcsolódó artefaktumokat, a különböző AI-domének SOTA-eredményeit, megosszák az érdekes kutatásokat, és egymás munkájára építve gyorsítsák a fejlődést. A keresőmotor kritikus része ennek a törekvésnek, mivel emberek és automaták számára egyaránt lehetővé kell tennie a releváns és kapcsolódó munkák gyors megtalálását — akár a weboldalon, akár a pwc search CLI-n vagy az ügynökök által használt Skill-en keresztül.
Miért kell más a tudományos keresésnek?
A kutatási cikkek keresése különbözik a hagyományos kulcsszavas kereséstől: a rendszernek meg kell találnia pontos címeket vagy arXiv-azonosítókat, de ugyanakkor képesnek kell lennie arra is, hogy olyan fogalmi lekérdezéseket kezeljen, mint például „small language models for code generation”, még ha a szókapcsolat maga nem is szerepel a cikkben. Emellett kezelnie kell navigációs kéréseket („the original BERT paper”), hiányos címeket vagy elírásokat, és gyorsnak kell maradnia még akkor is, ha egy modell szolgáltatás hideginduláson megy keresztül vagy átmenetileg nem elérhető.
A megoldás: hibrid keresés
A Papers with Code egy hibrid keresőrendszert épített, amely ötvözi a PostgreSQL teljes szöveges keresésének lexikális pontosságát és a pgvector-alapú denzitás (dense embedding) szerinti szemantikus keresését. A két ág rangjait a reciprocal rank fusion (RRF) algoritmussal egyesítik, ami általában jobb eredményt ad, mint pusztán kulcsszavas vagy pusztán vektoros megközelítések. Fontos kiegészítés, hogy rerankerek (cross-encoderek) további javulást hozhatnak, de növelik a késleltetést és az erőforrásigényt.
Használt Hugging Face szolgáltatások
Három Hugging Face szolgáltatás játszik központi szerepet a pipeline-ban:
- Hugging Face Jobs: burstolható GPU számítás batch-embeddezéshez.
- Hugging Face Storage Buckets: tartós köztes tároló a databázs, a Jobs és az importáló folyamat között.
- Hugging Face Inference Endpoints: hitelesített, alacsony késleltetésű lekérdezés-embeddezés a valós idejű kereséshez.
A rendszer jelenleg több mint 110,000 aktuális cikk embeddingjét tartja karban, forrást az arXiv és a Daily Papers szolgáltatások adnak.
Tervezési alapelv: offline korpuszépítés kontra online keresés
A csapat szándékosan kettéválasztotta a költségigényes, átbocsátás-orientált munkát és a késleltetés-érzékeny online kérésutat. A nagy volumenű batch munka Jobs-on fut, a tartós artefaktumok egy Bucket-ben tárolódnak, míg a kérdés beérkezésekor csak a lekérdezés-embeddezés történik az Inference Endpointon. Ha az Endpoint hideg, időtúllépésbe ütközik vagy hibázik, a keresés azonnal visszaesik a teljes szöveges (lexikális) lekérdezésre — így a rendszer mind gyors, mind robusztus marad.
Szigorú embedding-szerződés
Az embedding-pipeline hibái gyakran finom, nehezen észrevehető problémákban jelentkeznek (modellrevíziók változása, promptok összekeveredése, vektorok eltérő troncálása stb.). Ezt elkerülendő a Papers with Code a beágyazás formátumát verzionált API-ként kezeli. Minden cikket az alábbi módon kódolnak: normalizált cím + "\n\n" + normalizált absztrakt. Minden vektorgenerálásnál tárolják a modell repozitóriumát és pontos revízióját, a kimeneti dimenziót, az input-formátum verzióját, hogy query- vagy dokumentum-embedhez készült-e, a normalizálási módszert és a forrásszöveg hash-ét.
A produkciós generáláshoz Qwen/Qwen3-Embedding-0.6B modellt (pinned revision) használnak, 256-dimenziós L2-normalizált vektorokkal. A Qwen3 modellek két hasznos funkciót kínálnak: dinamikus embedding-méret (Matryoshka Representation Learning, röviden MRL), amivel minőség/gyorsaság/tárolás kompromisszum szabályozható; valamint külön promptok dokumentumokra és lekérdezésekre. A Papers with Code a 256 dimenziót választotta a keresés gyorsítása érdekében.
Hogyan működnek a Jobs a korpuszépítésben
A teljes korpusz beágyazása klasszikus batch-munka: rövid, GPU-intenzív futtatásokat igényel nagy átbocsátással. A munkafolyamat így épül fel:
- Egy repeatable-read PostgreSQL snapshotból exportálják az aktuális cikkeket; az exporter soronként streamel és JSONL darabokat ír, manifesttel és SHA-256 ellenőrzőösszeggel.
- A futás könyvtárát (immutable run directory) szinkronizálják egy privát Storage Bucket-be és hf-mount segítségével a Job-ba csatolják.
- A Job (például egy l4x1, NVIDIA L4 GPU, 24 GB VRAM) ellenőrzi a manifestet, betölti a modell pontos revízióját, a szövegeket hossz szerint rendezi a padding csökkentésére, batch-ekben hívja az encode_document-et, automatikusan csökkenti a batch méretet memóriahiány esetén, troncálja a Matryoshka reprezentációt 256 dimenzióra, normalizál, és float16 Parquet-szeleteket ír atomikusan. Szintén naplózza a throughputot, csomagverziókat, hardvert, peak VRAM-ot és checksums-okat.
A 5,000 cikkes pilotban a Qwen Job ~75 cikket kódolt másodpercenként 1024 dimenzión egy L4 GPU-n. Ugyanaz a pass determinisztikusan materializálható volt 512 és 256 dimenzióra is, így a storage és visszakeresési kompromisszumok összehasonlíthatók voltak további inferencia költségek nélkül.
Buckets mint kapcsolódó komponens
A Storage Buckets S3-szerű, módosítható objektumtárolók a Hub-on, amelyek közvetlenül csatolhatók Job-okhoz. A Papers with Code számára a Bucket a három rendszer (produkciós adatbázis, epheméral Jobs, importer) közötti határ: immutábilis run-prefixeket tartalmaz (runs/<run-id>/ input/output szerkezettel), és alkalmazási szinten garantálják, hogy egy run-id nem írható felül.
Előnyei:
- Reprodukálhatóság: visszakövethető a snapshot, modellrevízió és artefaktok.
- Biztonságos újrapróbálás: a Jobs folytathatja a már készített daraboknál.
- Olcsó kísérletezés: több modell/dimenzió újrafelhasználhat egy input snapshotot.
- Kontrollált rollout és egyszerű rollback: az új generáció importálása nem azonnal aktiválódik, csak miután ellenőrizték a lefedettséget.
Csak az importer lefutása és az összes ellenőrzés (sémák, checksums, dimenziók, normalizálás, egyedi paper ID-k, tartalom-hash) után töltik be a vektorokat PostgreSQL-be, majd külön HNSW indexet építenek és atomikusan aktiválják, ha minden jogos paper le van fedve.
Inference Endpoints a lekérdezés útvonalán
A dokumentumok batch beágyazása megoldja a cikk-oldali vektorokat; a lekérdezést valós időben kell beágyazni ugyanazzal a modell-szerződéssel. A lekérdezés-embeddek egy hitelesített Inference Endpointon (Text Embeddings Inference) futnak, amely a query-promptot használva 256-dimenziós normalizált vektort ad vissza.
A lekérdezésügyfél szigorú szabályokat alkalmaz:
- 1 másodperces gyártási timeout;
- nem-blokkoló konkurencia limit;
- válasz dimenzió/finitség/norm ellenőrzés;
- rövid cache a lekérdezés és embedding generáció szerint;
- áramkörmegszakító (circuit breaker) ismételt hibák esetén;
- naplókban nincs nyers lekérdezésszöveg, csak normalizált ujjlenyomat.
Ha az Endpoint hidegstartol, időtúllép vagy hibás vektort ad, a rendszer azonnal átugorja a szemantikus ágat és a lexikális találatokat adja vissza — így a felhasználó nem váratlan késleltetést tapasztal.
A HNSW index gyors lekérdezést biztosít; a 5,000-cikkes pilotban a 256-dimenziós Qwen index 0.9955 Recall@20-t ért el az exact kereséshez képest, 1.31 ms p50 és 2.21 ms p95 HNSW lookup késleltetéssel. A 256-dimenziós táblázat és index körülbelül 27%-át használta a 1024-dimenziós verzió tárolásának, miközben az ANN-recall lényegében megmaradt.
Hibrid egyesítés: RRF
Minden lekérdezésnél a lexikális ág PostgreSQL teljes szöveges kereséssel legfeljebb 50 jelöltet hoz, a szemantikus ág pgvector-ból szintén legfeljebb 50 jelöltet. Ezeket a rangsorokat súlyozott reciprocal rank fusion-nel (RRF) kombinálják:
- Jelenleg egyenlő ág-súlyokat használnak és k=60 rank-constans értéket.
A gyakorlatban a dense retrieval javítja a konceptuális lekérdezések recall-ját, míg a full-text továbbra is jobb az azonosítókon, pontos terminusokon és ritka neveken. Az alkalmazás továbbra is biztosít determinisztikus viselkedést: pontos címek és arXiv ID-k mindig előrébb maradnak; a method taxonomy kezeli a navigációs kereséseket; hiányos címeknél és kisebb elírásoknál konzervatív trigram-jelölteket használ; és kétes találatoknál inkább tartózkodik a hamis találatok erőltetésétől.
Megjegyzés: a hibrid nem mindig a legjobb kezdés — érdemes először kulcsszavas, olcsó baseline-nal indulni, és csak ha az javítást hoz, hozzáadni a szemantikus vagy hibrid réteget. További fejlesztésként rerankert is lehet alkalmazni (például Qwen3-Reranker-rel).
Egy Endpoint, két update-útvonal
Az inicializáló nagy korpuszt Jobs-szal embeddelik, de a Papers with Code katalógusa folyamatosan változik: új cikkek érkeznek, absztraktok módosulnak, új arXiv-verziók válnak aktuálissá. Egy GPU Job indítása kis mennyiségű változtatásra túl drága és lassú lenne. Ehelyett óránként futó inkrementális folyamat választja ki a hiányzó vagy tartalomváltozott cikkeket, és legfeljebb 500 cikket küld a TEI Endpointnak dokumentum-prompttal, batch-ekben (16-os batch). Minden beírás előtt a forrás sort zárolják és a tartalom-hash újraellenőrzik; ha a cikk változott a közben, a vektort elvetik és a következő futás felveszi.
Tehát a munkamegosztás:
- Jobs: teljes újraegyensúlyozások, új modellgenerációk, nagy backfill-ek.
- Inference Endpoints: interaktív lekérdezés-embeddek és kis inkrementális dokumentum-frissítések.
- Buckets: nagy build-artefaktok tárolása, futtatások folytathatósága és auditálhatósága.
Az óránkénti útvonal segít abban, hogy az aktív index közel maradjon az élő katalógushoz anélkül, hogy az online endpointot korlátlan batch-feldolgozóvá tennénk.
Kapcsolódó cikkek és egyéb szolgáltatások
Ugyanezek a dokumentum-embeddek szolgálják ki a „related papers” ajánlásokat minden cikkoldalon. Mivel a forráscikkhez már létezik tárolt vektor, a kapcsolódó cikkek előhívása lekérésszinten általában nem igényel modellt — egyetlen nearest-neighbor lekérdezés az aktív generáción. Ha egy vektor ideiglenesen hiányzik, a rendszer korábbi arXiv-verziót vagy feladat-/idézet-alapú fallbacket használhat.
Tapasztalatok és tanulságok
- Szétválasztani a throughput-optimalizált munkát a késleltetés-érzékeny munkától: Jobs és Inference Endpoints különböző infrastrukturális igényekre optimalizálnak.
- A tárolás legyen explicit szerződés a compute és a produkció között: a Bucket-ek és checksummed artefaktok jól definiált átadási pontot biztosítanak.
- Pin-eljünk többet, mint csak a modell nevét: revízió, dimenzió, prompt, normalizálás és input formatter mind befolyásolják a visszakeresést.
- Tervezni kell cold startokra: scale-to-zero költségelőnyt ad, de a terméknek gyors fallback-et kell biztosítania — náluk a lexikális keresés ez a fallback.
- A kisebb vektorok lehetnek rendszerfunkciók: a Matryoshka megközelítés lehetővé teszi a minőség/memória/index/latencia értékelését. Pilotjukban a 256 dimenzió megőrizte az ANN recall-t, miközben jelentősen csökkentette a tárolási igényt a 1024-dimenziós verzióhoz képest.
- Az aktiválás legyen rutinszerű: az új generációk importálása mellett a jelenlegi megmarad, teljes lefedettséget ellenőriznek, majd atomikusan aktiválják — a rollback konfigurációs változás, nem vészhelyzeti újraszámolás.
Kipróbálás
A kereső kipróbálható a https://paperswithcode.co oldalon, illetve a chat felület a https://paperswithcode.co/chat címen elérhető. A csapat várja a visszajelzéseket.
