> A RAG-index frissen tartása: elavulási keret, változáskövetés, CDC Postgresből Debeziummal, törlések, jogosultságok, blue/green csere és költség.
>
> Web page: https://balazscsorba.com/hu/blog/incremental-indexing-cdc · Language: Magyar · Also available in: [English](https://balazscsorba.com/blog/incremental-indexing-cdc.md) · [Deutsch](https://balazscsorba.com/de/blog/incremental-indexing-cdc.md)
> Author: Balázs Csorba · Published: 2026-09-25 · Updated: 2026-10-17 · Keywords: incremental indexing for RAG, change data capture RAG, Debezium Postgres logical decoding, re-embedding cost, blue/green index swap vector database, index staleness monitoring, delete propagation vector index, permission changes RAG index, Qdrant aliases, high water mark change detection

[Blog](https://balazscsorba.com/hu/blog)/Retrieval és keresés

# A RAG-index frissen tartása: növekményes indexelés, CDC és blue/green újrabeágyazás

A RAG-index frissen tartása: elavulási keret, változáskövetés, CDC Postgresből Debeziummal, törlések, jogosultságok, blue/green csere és költség.

[Balázs Csorba](https://balazscsorba.com/hu/about)·2026\. szeptember 25.·frissítve 2026\. október 17.·8 perc olvasás

-   RAG
-   Change data capture
-   PostgreSQL
-   Vector databases
-   Data freshness

![Egy adatbázis változásokat továbbít egy szekrénybe, mellette egy második szekrény és egy kapcsoló.](https://balazscsorba.com/images/blog/incremental-indexing-cdc/cover.webp?v=5761ce5458)

## A lényeg röviden

-   Adjon minden forrásnak percekben megadott elavulási keretet, és ehhez mérje a késést; az „előbb-utóbb konzisztens” nem tesztelhető követelmény.
-   Sok forráshoz elég a vízszintjel és a tartalom-hash; a Postgresből logikai dekódolással és Debeziummal végzett CDC azokhoz a forrásokhoz való, ahol percek számítanak, a replikációs slotjait pedig felügyelni kell.
-   A törlések és a jogosultságváltozások azok a változások, amelyeket az indexelők elmulasztanak: az Azure AI Search dokumentációja szerint az indexelők nem követik a törléseket, a GDPR szerinti törlésnek pedig indokolatlan késedelem nélkül kell megtörténnie.
-   A modellváltás miatti újrabeágyazás egy alias mögötti új gyűjteménybe való, egyetlen API-hívással átkapcsolva és visszalépéshez megtartva; pgvectorban párhuzamosan építse az indexeket.
-   A token az olcsó rész: 100 millió token újrabeágyazása millió tokenenként 0,02 dolláron kb. 2 dollár; a valódi költség a fejlesztés, a visszatöltési idő és a helyesség.

Ezen az oldalon

1.  [Mit jelent a friss: elavulási keret](https://balazscsorba.com/#staleness-budget)
2.  [Változáskövetés vízszintjelekkel és hash-ekkel](https://balazscsorba.com/#dirty-tracking)
3.  [Változásrögzítés Postgresből](https://balazscsorba.com/#cdc-from-postgres)
4.  [Törlések és jogosultságváltozások](https://balazscsorba.com/#deletes-and-permissions)
5.  [Teljes újraindexelés és blue/green csere](https://balazscsorba.com/#reindex-and-blue-green-swaps)
6.  [Az újrabeágyazás költsége](https://balazscsorba.com/#cost-of-re-embedding)
7.  [Mikor túlzás a CDC](https://balazscsorba.com/#when-not-to-use-cdc)
8.  [Ellenőrzőlista egy naprakész indexhez](https://balazscsorba.com/#checklist)
9.  [Források](https://balazscsorba.com/#sources)

Cikk meghallgatása

0:000:00

A **növekményes indexelés RAG-hoz** az a réteg, amely az első bejárás után is igaznak tartja az indexet: az új dokumentumokat feldarabolja és beágyazza, a módosultakat lecseréli, a törölteket eltávolítja, a jogosultságváltozások pedig eljutnak az indexbe, mielőtt valaki olyan dokumentumot látna, amelyet nem lenne szabad. A legtöbb RAG-prototípus kihagyja, mert az első bemutató egy statikus mappát használ. Az éles korpuszok egész nap változnak, és egy asszisztens, amely a múlt heti árlistát vagy egy visszavont szabályzatot idéz, rosszabb annál, amelyik bevallja, hogy nem tudja.

Ez a cikk az elavulási keretről, a vízszintjelekkel és hash-ekkel végzett változáskövetésről, a Postgresből végzett változásrögzítésről (CDC), a törlésekről és jogosultságváltozásokról, a blue/green cserével végzett teljes újraindexelésről, az újrabeágyazás költségéről, és arról szól, mikor túlzás a CDC. A darabolást, a visszakeresést és az újrarangsorolást a [RAG-folyamatok: darabolás, hibrid keresés és újrarangsorolás](https://balazscsorba.com/hu/blog/rag-pipeline-chunking-hybrid-search-reranking) tárgyalja; a verziók és árak 2026 októberi állapotot tükröznek.

## Mit jelent a friss: elavulási keret

A friss forrásonként mért számot jelent, nem érzést. Írja le minden forrásra, hány perc alatt kell egy változásnak eljutnia az indexbe: talán öt a készletszintekhez, egy óra a termékleírásokhoz, egy nap az archivált kézikönyvekhez, és azonnal a visszavont hozzáférésekhez. Ezeket a számokat semmilyen szabvány nem írja elő; abból következnek, mibe kerül egy rossz válasz. Ezután mérje a tényleges késést a forrásbeli véglegesítéstől az indexbe írásig, és riasszon, ha átlépi a keretet.

A keretből az is kiderül, milyen mechanizmus kell. A napi keretet egy éjszakai söprés teljesíti; az ötperces kerethez gyakori bejárás vagy események kellenek; a jogosultságokra vonatkozó másodperces keret általában azt jelenti, hogy a hozzáférést lekérdezéskor és az indexben is ellenőrizni kell. Az index felosztása segít. Spryker- és Pimcore-alapú katalógusokban az ár és a készlet egész nap változik, a hosszú leírások ritkán, így az illékony skalármezők metaadatként frissíthetők anélkül, hogy a mellettük lévő szöveget újra be kellene ágyazni.

## Változáskövetés vízszintjelekkel és hash-ekkel

A legtöbb forráshoz nem kell adatbázisnapló, csak megbízható módja annak, hogy kiderüljön, mi változott az utolsó futás óta. A vízszintjel a klasszikus minta: jegyezze meg a legnagyobb feldolgozott `updated_at` értéket, és legközelebb az e fölötti sorokat kérje le. Az Azure AI Search újrahasznosítható változásészlelési szabályként nevezi meg, ütemezett indexelői pedig 5 percenként és 24 óránként között futhatnak ([Azure AI Search](https://learn.microsoft.com/en-us/azure/search/search-howto-schedule-indexers)). Használjon monoton növekvő oszlopot, tartson kis átfedési ablakot, és tegye idempotenssé az írásokat, mert az órák és a hosszú tranzakciók régebbi időbélyeggel véglegesülő sorokat hoznak létre.

A tartalom-hash kiegészíti a vízszintjelet. A beágyazandó szöveget hash-elje, ne az egész sort, és hagyja ki az újrabeágyazást, ha a hash nem változott; így egy árfrissítés csak a metaadatot érinti. Ugyanez az ötlet kisebb léptékben fájlokra és repókra is működik, ahol fájlonként egy hash dönti el, mit kell újradarabolni, ahogy a [RAG kódon](https://balazscsorba.com/hu/blog/code-rag-repository-indexing) leírja. Mindkettő gyenge pontja a törlés: egy már nem létező sor sosem jelenik meg a módosult sorokra irányuló lekérdezésben.

A söpréshez az elcsúszás elleni védelem is kell. Hetente egyszer vesse össze a forrásazonosítók teljes listáját az indexben lévő azonosítókkal: ami az indexben van, de a forrásban nincs, az elmulasztott törlés, ami a forrásban van, de az indexben nincs, az elmulasztott beszúrás. Ez az összevetés olcsó, minden más mechanizmus hibáit elkapja, és az eredménye egy szám, amely a késés mellé ugyanarra a műszerfalra kerülhet.

## Változásrögzítés Postgresből

A változásrögzítés a táblák lekérdezgetése helyett az adatbázis write-ahead naplójából olvassa a véglegesített változásokat, így a beszúrások, módosítások és törlések egyaránt másodperceken belül eseményként érkeznek. Postgresben a mechanizmus a logikai dekódolás, „az adatbázis tábláin végzett összes tartós változás koherens, könnyen érthető formátumba történő kinyerése”, amely replikációs slotokra és egy kimeneti bővítményre épül ([PostgreSQL](https://www.postgresql.org/docs/current/logicaldecoding-explanation.html)). Egy publikáció határozza meg, mely táblák tartoznak bele ([CREATE PUBLICATION](https://www.postgresql.org/docs/current/sql-createpublication.html)), a sémaváltozásokat viszont nem replikálja, így a DDL külön feladat ([korlátozások](https://www.postgresql.org/docs/current/logical-replication-restrictions.html)).

![Eseményút a friss indexhez Öt lépés balról jobbra: egy változás véglegesül a Postgresben; a logikai dekódolás egy replikációs sloton keresztül elérhetővé teszi; a Debezium beszúrási, módosítási vagy törlési eseményt készít belőle; egy átalakító kiszűri a releváns mezőket, újradarabolja és beágyazza a módosult szöveget; az index pedig frissíti vagy törli az érintett darabokat. Egy updated_at szerinti ütemezett söprés elkapja, amit az eseményút elmulasztott, egy riasztás pedig a replikációs slot késését figyeli.](https://balazscsorba.com/images/blog/incremental-indexing-cdc/diagram-11.webp?v=00ff24f199)

Az eseményút másodpercek alatt szállítja a változásokat; egy lassabb söprés és egy késésriasztás gondoskodik róla, hogy semmi ne maradjon sokáig hibás.

A feldolgozás szokásos módja a Debezium. A PostgreSQL-csatlakozójához `wal_level=logical` és elegendő WAL-küldő és replikációs slot kell, a dokumentációja pedig egyenesen fogalmaz a kockázatról: a replikációs slotok kiesés alatt is megtartanak minden WAL-t, amelyre a Debeziumnak szüksége van, ezért felügyelni kell őket, hogy elkerülje a lemez megtelését és a katalógus felfúvódását ([Debezium](https://debezium.io/documentation/reference/stable/connectors/postgresql.html)). A módosítási események csak `REPLICA IDENTITY FULL` mellett tartalmazzák az előző oszlopértékeket; egy heartbeat-intervallum akkor is mozgásban tartja a slotot, ha a rögzített táblák csendesek, egy jelzőtábla pedig teljes újraindexelés helyett célzott visszatöltést indít.

```
-- Postgres side of CDC: scope, slot health and lag
ALTER TABLE products REPLICA IDENTITY FULL;            -- update events carry old values too
CREATE PUBLICATION rag_sources FOR TABLE products, product_texts, document_acl;

-- WAL retained by each slot: alert long before the disk fills
SELECT slot_name, active, wal_status,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn)) AS behind
FROM pg_replication_slots;
```

A Postgres elérhetővé teszi a késésriasztáshoz szükséges számokat: a `pg_replication_slots` minden slotnál mutatja a megerősített pozíciót és a WAL-állapotot, a `max_slot_wal_keep_size` pedig korlátozza, mennyi WAL-t tarthat meg egy slot, mielőtt érvénytelenné válik ([PostgreSQL](https://www.postgresql.org/docs/current/view-pg-replication-slots.html)). A jelenlegi WAL-pozíció és a slot megerősített pozíciója közötti különbségre riasszon, jóval mielőtt eléri ezt a korlátot. A rendszerek között amúgy is áramló rendelési és katalógusadatokra ugyanazok az outbox- és idempotenciaminták érvényesek, lásd [rendelésszinkron a webshop és az ERP között](https://balazscsorba.com/hu/blog/b2b-order-sync-erp).

## Törlések és jogosultságváltozások

A törlések és a jogosultságváltozások azok a változások, amelyeket az indexelők a leggyakrabban elmulasztanak, és éppen ennek a kettőnek vannak jogi következményei. Az Azure AI Search egyértelműen fogalmaz: az indexelő nem követi az objektumok törlését az adatforrásokban, ezért logikai törlési stratégia kell, és a szabályt a legelső indexelő futástól alkalmazni kell, különben a törölt dokumentumok az indexben maradnak ([Azure AI Search](https://learn.microsoft.com/en-us/azure/search/search-howto-index-changed-deleted-blobs)). A GDPR 17. cikke szerint a személyes adatokat indokolatlan késedelem nélkül törölni kell, ha a törlés esedékes ([GDPR](https://gdpr-info.eu/art-17-gdpr/)), és az ilyen adatok darabjait tartalmazó vektorindex is ide tartozik.

Mindkettőt kezelje kifejezetten. Minden darabon tárolja a forrás- és dokumentumazonosítót, hogy egy törlés egyetlen hívással eltávolíthassa egy dokumentum összes darabját; ahol van, dolgozza fel a CDC törlési eseményeit; és futtasson rendszeres egyeztetést, amely eltávolítja azokat a darabokat, amelyek forrása már nem létezik. A hozzáférés-szabályozáshoz a jogosultsági állapotot tartsa az indexben a szöveg és a vektorok mellett, a jogosultságváltozásokat pedig önálló eseményként továbbítsa. Az Azure AI Search ma már az indexben tárolja az ACL-metaadatokat, és 2026-ban a SharePoint-indexelőjéhez futásonkénti növekményes ACL-szinkront adott hozzá ([Azure AI Search](https://learn.microsoft.com/en-us/azure/search/whats-new)).

**A törölt dokumentum addig megválaszolható, amíg a darabjait nem törli**

Ha egy dokumentumot eltávolít a forrásrendszerből, azzal nem tűnik el a vektorindexből, az előtte lévő gyorsítótárból vagy bármely válasznaplóból. Tesztelje a törlést végig: töröljön egy ismert dokumentumot, majd tegyen fel az asszisztensnek olyan kérdést, amelyre csak az a dokumentum válaszolhat, és ellenőrizze, hogy a hivatkozás eltűnt.

## Teljes újraindexelés és blue/green csere

Néhány változás nem alkalmazható növekményesen: egy új beágyazó modell, új darabolási stratégia vagy új indexkonfiguráció azt jelenti, hogy minden vektor megváltozik. Ezt kezelje migrációként, blue/green cserével. A Qdrant pontosan erre az esetre dokumentálja az aliasokat, a vektorverziók közötti váltásra „a neurális háló új verziójára való frissítéskor”, az aliasmódosításokat egyetlen műveleti kérésként küldve ([Qdrant](https://qdrant.tech/documentation/concepts/collections/)); az Elasticsearch aliasai ugyanezt a célt szolgálják, és leállás nélküli újraindexelés módjaként dokumentáltak ([Elastic](https://www.elastic.co/docs/manage-data/data-store/aliases)).

![A blue/green újrabeágyazás idővonala Négy fázis balról jobbra egy idővonalon. Építés: az új modellel létrejön a v2 gyűjtemény, miközben a v1 kiszolgálja a teljes forgalmat. Visszatöltés: a v2 feltöltődik a forrásból, az új változások mindkettőbe íródnak. Átkapcsolás: egyetlen aliashívás a v1-ről a v2-re irányítja az alkalmazást. Megtartás: a v1 visszalépéshez csak olvashatóként megmarad, majd törlődik. Alatta a pgvector-változat: az új index párhuzamos létrehozása, majd váltás az alkalmazás konfigurációjában.](https://balazscsorba.com/images/blog/incremental-indexing-cdc/diagram-21.webp?v=438e1a5486)

A modellváltás migráció: építse mellé, töltse fel, egyetlen hívással kapcsoljon át, és tartsa meg a régi indexet, amíg az új nem bizonyított.

A sorrend mindenhol ugyanaz: építse fel az új gyűjteményt az új modellel, miközben a régi kiszolgál, töltse fel a forrásból, a visszatöltés alatt az új változásokat írja mindkettőbe, kapcsolja át az aliast, és a régi gyűjteményt tartsa meg csak olvashatóként, amíg az új élesben át nem megy a visszakeresési kiértékelésén. A dokumentáció az aliashívást írja le, nem a terhelés alatti tranzakciós garanciáit, ezért az átkapcsolást előbb egy tesztkörnyezeti másolaton próbálja ki. pgvectorban ennek megfelelője egy új oszlop vagy tábla, egy `CREATE INDEX CONCURRENTLY` paranccsal épített index, hogy az írások ne blokkolódjanak, és váltás az alkalmazás konfigurációjában ([pgvector](https://github.com/pgvector/pgvector)).

A pgvector két gyakorlati megjegyzést tesz: az indexépítés jóval gyorsabb, ha a HNSW-gráf befér a `maintenance_work_mem` keretbe, és az `m = 16`, valamint az `ef_construction = 64` alapértékek észszerű kezdést jelentenek az új indexhez. A célmodell kiválasztása külön döntés, ezt a [beágyazó modell kiválasztásáról](https://balazscsorba.com/hu/blog/embedding-model-selection-2026) szóló cikk tárgyalja.

## Az újrabeágyazás költsége

A token az olcsó rész. 2026 októberében az OpenAI a `text-embedding-3-small` modellt millió tokenenként 0,02, a `text-embedding-3-large` modellt 0,13 dollárért kínálja ([OpenAI](https://platform.openai.com/docs/pricing)), a Voyage a `voyage-4-lite`\-ot 0,02, a `voyage-4`\-et 0,06 dollárért millió tokenenként, kötegelt kedvezménnyel ([Voyage](https://docs.voyageai.com/docs/pricing)). Egy 100 millió tokenes korpusz újrabeágyazása így nagyjából 2–13 dollár API-díj. Ez listaárakkal végzett számítás, nem árajánlat, és minden máshoz képest csekély.

A valódi költségek máshol vannak: órákig tartó visszatöltés sebességkorlátok mellett, egy kettős írási ablak, amelynek helyesnek kell lennie, többlettárhely, amíg két index létezik, és egy visszakeresési kiértékelés az új modellel az átkapcsolás előtt. A saját Nuxt-oldalamon, ahol LLM-funkciókat futtatok egy kis korpuszon, mindent újra beágyazni triviális, és éppen ezért nem a tokenszámla az ok a CDC megépítésére; hanem a frissesség, a törlések és a jogosultságok.

Teljes újrabeágyazás előtt egy rövidítést érdemes megvizsgálni. Egyes szolgáltatók olyan modellcsaládokat írnak le, amelyek tagjai közös beágyazási teret használnak, ami lehetővé tenné, hogy először a lekérdezési oldalt frissítse; mielőtt erre támaszkodna, ellenőrizze az ilyen állítást a szolgáltató saját dokumentációjában és a kiértékelő készletével, mert az összeférhetetlen modellek vektorainak keverése észrevétlenül rontja a visszakeresést.

## Mikor túlzás a CDC

A CDC túlzás, ha az elavulási keret órák vagy egy nap, ha a forrás egy SaaS-rendszer adatbázis-hozzáférés nélkül, vagy ha a csapatban senki sem fogja figyelni a replikációs slotokat. Egy éjszakai vagy óránkénti söprés vízszintjelekkel, tartalom-hash-ekkel és törlési egyeztetéssel egyszerűbb, könnyebben átlátható, és a legtöbb dokumentumgyűjteményhez elég. SaaS-forrásoknál a webhookok jelentik az eseményutat: ellenőrizzen egy titkot, 10 másodpercen belül válaszoljon, ellenőrizze az esemény típusát, kérje újra az elmaradt kézbesítéseket, és a kézbesítési azonosító alapján deduplikáljon, ahogy a GitHub útmutatója leírja ([GitHub](https://docs.github.com/en/webhooks/using-webhooks/best-practices-for-using-webhooks)).

Mechanizmus

Jellemző elavulás

Észleli a törlést

Észleli a jogosultságváltozást

Üzemeltetési teher

Éjszakai teljes újraindexelés

akár egy nap

igen, újraépítéssel

igen, újraépítéssel

alacsony, de nagy méretnél drága

updated\_at söprés

perctől óráig

nem, egyeztetés kell

csak ha az ACL-sorokon van időbélyeg

alacsony

Tartalom-hash összevetés

futásonként

igen, ha a teljes listát összeveti

nem

alacsony

CDC logikai dekódolással

másodpercek

igen, törlési események

igen, ha az ACL-táblák publikáltak

magas: slotok, késés, séma

Bejövő webhookok

másodpercek

ha a forrás küldi

ha a forrás küldi

közepes: újrapróbálás, dedup

## Ellenőrzőlista egy naprakész indexhez

1.  Forrásonként határozzon meg elavulási keretet, és ehhez mérje a késést.
2.  Minden darabon tárolja a forrásazonosítót, a dokumentumazonosítót, a tartalom-hash-t és a jogosultságokat.
3.  Csak akkor ágyazzon be újra, ha a beágyazott szöveg változott; egyébként a metaadatot frissítse.
4.  A törléseket és jogosultságváltozásokat kifejezetten továbbítsa, és a törlést végig tesztelje.
5.  CDC esetén riasszon a replikációs slotok késésére és a megtartott WAL-ra.
6.  Tartson rendszeres söprést, amely elkapja, amit az események elmulasztottak.
7.  A modellváltást alias mögötti blue/green migrációként végezze, visszalépési lehetőséggel.

Ha a RAG-rendszerének helyesnek kell maradnia, miközben a mögöttes adatok egész nap változnak, nézze meg a [MI-mérnöki munkámat](https://balazscsorba.com/hu/expertise/ai-engineer). Ugyanennek a problémának a termékadat-oldalát [a Pimcore ERP delta szinkron](https://balazscsorba.com/hu/blog/pimcore-erp-delta-sync) tárgyalja.

## Források

1.  [PostgreSQL docs: logical decoding concepts](https://www.postgresql.org/docs/current/logicaldecoding-explanation.html)
2.  [Debezium docs: PostgreSQL connector](https://debezium.io/documentation/reference/stable/connectors/postgresql.html)
3.  [PostgreSQL docs: CREATE PUBLICATION](https://www.postgresql.org/docs/current/sql-createpublication.html)
4.  [PostgreSQL docs: pg\_replication\_slots](https://www.postgresql.org/docs/current/view-pg-replication-slots.html)
5.  [Azure AI Search: changed and deleted blobs](https://learn.microsoft.com/en-us/azure/search/search-howto-index-changed-deleted-blobs)
6.  [Azure AI Search: scheduling indexers](https://learn.microsoft.com/en-us/azure/search/search-howto-schedule-indexers)
7.  [Qdrant docs: collections and aliases](https://qdrant.tech/documentation/concepts/collections/)
8.  [Elastic docs: aliases](https://www.elastic.co/docs/manage-data/data-store/aliases)
9.  [pgvector on GitHub](https://github.com/pgvector/pgvector)
10.  [GDPR Article 17](https://gdpr-info.eu/art-17-gdpr/)
11.  [OpenAI API pricing](https://platform.openai.com/docs/pricing)
12.  [Voyage AI docs: pricing](https://docs.voyageai.com/docs/pricing)

## Gyakori kérdések

Hogyan tartsam naprakészen a RAG-indexet?

Kövesse, mely forrásrekordok változtak, vízszintjellel, tartalom-hash-sel vagy változásrögzítéssel (CDC), csak ezeket darabolja és ágyazza be újra, a törléseket és jogosultságváltozásokat kifejezetten továbbítsa, és futtasson rendszeres söprést, amely elkapja, amit az eseményút elmulasztott. A késést forrásonkénti elavulási kerethez mérje.

Mi a változásrögzítés (CDC) a RAG-ban?

A változások olvasása az adatbázis naplójából a táblák lekérdezgetése helyett. Postgresben a logikai dekódolás elérhetővé teszi a véglegesített beszúrásokat, módosításokat és törléseket, a Debezium pedig ezekből eseményeket készít, amelyeket egy indexelő másodperceken belül feldolgozhat. Replikációs slotok kellenek hozzá, amelyek a feldolgozásig megtartják a WAL-t, és felügyelni kell őket.

Hogyan jutnak el a törlések a vektorindexbe?

Csak ha elküldi őket. Sok indexelő nem követi a forrásbeli törléseket, ezért használjon CDC-ből származó törlési eseményeket, az indexelő által olvasott logikai törlésjelzőt, vagy rendszeres egyeztetést, amely eltávolítja azokat a darabokat, amelyek forrásazonosítója már nem létezik. A személyes adatokat a GDPR szerint indokolatlan késedelem nélkül törölni kell.

Hogyan ágyazzak be újra új modellel leállás nélkül?

Építsen új gyűjteményt az új modellel, miközben a régi kiszolgál, töltse fel, az új változásokat írja mindkettőbe, majd egyetlen hívással kapcsoljon át egy aliast az új gyűjteményre, a régit pedig tartsa meg csak olvashatóként a visszalépéshez. pgvectorban párhuzamosan hozza létre az új indexet, és konfigurációban váltson.

Mennyibe kerül egy korpusz újrabeágyazása?

2026 októberében millió tokenenként 0,02–0,13 dolláros beágyazási API-árakkal 100 millió token újrabeágyazása nagyjából 2–13 dollár. A valódi költség a visszatöltési idő, a sebességkorlátok, az átkapcsolás fejlesztése és a keresési minőség újraellenőrzése az új modellel.

Írta: Csorba Balázs

Senior fullstack és AI mérnök Stájerországban – több mint 10 év Vue, Nuxt, Node.js és PHP, ma AI-ügynököknek építek eszközöket.

[AI fejlesztés és MCP szerverek →](https://balazscsorba.com/hu/expertise/ai-engineer)[Rólam →](https://balazscsorba.com/hu/about)

## További cikkek

-   [Embedding-modell választása 2026-ban: ranglisták, költségek és összehasonlító teszt a saját adatokon](https://balazscsorba.com/hu/blog/embedding-model-selection-2026)
-   [Kontextuális visszakeresés és késleltetett chunkolás: a RAG-chunkok visszakapják a kontextusukat](https://balazscsorba.com/hu/blog/contextual-retrieval-late-chunking)
-   [Hozzáférés-kezelés RAG-hoz: jogosultságtudatos visszakeresés dokumentumszivárgás nélkül](https://balazscsorba.com/hu/blog/rag-access-control-permissions)
-   [RAG termékkatalógusra: PIM-adatokból megbízható válaszok](https://balazscsorba.com/hu/blog/rag-product-catalog-pim-data)

## Pont erre van szükséged?

Írj a projektedről vagy a pozícióról – szívesen hallok felőled.

[Lépj velem kapcsolatba](mailto:contact@balazscsorba.com) [Kapcsolódjunk LinkedInen](https://www.linkedin.com/in/balazs-csorba)