> Ajánlatkérések automatizálása LLM-mel: dokumentumfogadás, tételkinyerés, cikkszám-párosítás, szerződéses árazás és gyors ellenőrzési sor.
>
> Web page: https://balazscsorba.com/hu/blog/llm-rfq-quote-automation · Language: Magyar · Also available in: [English](https://balazscsorba.com/blog/llm-rfq-quote-automation.md) · [Deutsch](https://balazscsorba.com/de/blog/llm-rfq-quote-automation.md)
> Author: Balázs Csorba · Published: 2026-10-14 · Keywords: RFQ automation, automated quote generation, quote automation LLM, request for quote parsing, part number matching, B2B quote automation software, AI quote generation distribution, human in the loop document review, PDF RFQ extraction, semantic product matching

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

# Ajánlatkérések automatizálása LLM-mel: feldolgozás, cikkszám-párosítás, emberi ellenőrzés

Ajánlatkérések automatizálása LLM-mel: dokumentumfogadás, tételkinyerés, cikkszám-párosítás, szerződéses árazás és gyors ellenőrzési sor.

[Balázs Csorba](https://balazscsorba.com/hu/about)·2026\. október 14.·8 perc olvasás

-   RFQ
-   Quote automation
-   Document AI
-   Product matching
-   Human review

![Egy lap kilép a borítékból, és egy fogaskeréken át pecsétes dokumentum lesz.](https://balazscsorba.com/images/blog/llm-rfq-quote-automation/cover.webp?v=6b2d457fcb)

## A lényeg röviden

-   Az ajánlatkérés-automatizálás előkészítse az ajánlatot, ne küldje el: a folyamat egy beérkező dokumentumból bizonyítékkal ellátott javasolt tételeket készít, és ember hagyja jóvá, mielőtt bármi kimegy.
-   A cikkszámokat lépcsőzetesen párosítsa: először pontos azonosítók, aztán ügyfél-kereszthivatkozási tábla, végül szemantikus keresés, és szemantikus találat soha ne kapjon akkora bizalmat, mint egy pontos.
-   Árat soha nem a modell állít elő; a tételek ugyanazon a szerződéses és ERP úton kapnak árat, mint a webshopban, vagy „ár kérésre” jelölést kapnak.
-   A szigorú strukturált kimeneti módok a JSON Schemának csak egy részhalmazát támogatják, ezért a mértékegység-, mennyiség- és cikkszám-ellenőrzés a kinyerés után kódba tartozik.
-   Nincs publikált tanulmány, amely az ajánlatkérésre adott válaszidőt a nyerési aránnyal kötné össze; az üzleti indoklást a saját, ajánlatkérésenkénti munkapercekből és a publikált oldalankénti árakból építse fel.

Ezen az oldalon

1.  [Mit változtat valójában az ajánlatkérés-automatizálás?](https://balazscsorba.com/#what-rfq-automation-actually-changes)
2.  [A folyamat a postafióktól az ajánlattervezetig](https://balazscsorba.com/#the-pipeline-from-inbox-to-draft-offer)
3.  [Hogyan olvassuk be az ajánlatkérési dokumentumot?](https://balazscsorba.com/#reading-the-rfq-document)
4.  [Hogyan párosítjuk az ajánlatkérés tételeit a cikkekkel?](https://balazscsorba.com/#matching-lines-to-articles)
5.  [Honnan jönnek az árak?](https://balazscsorba.com/#pricing-the-draft-from-contracts-and-erp)
6.  [Hogyan működjön az ellenőrzési sor?](https://balazscsorba.com/#confidence-review-queues-and-failure-taxonomy)
7.  [Mennyit ér az ajánlatkérés-automatizálás?](https://balazscsorba.com/#what-it-is-worth)
8.  [Mikor nem éri meg az ajánlatkérés-automatizálás?](https://balazscsorba.com/#when-not-to-use-it)
9.  [Ellenőrzőlista egy ajánlatkérés-automatizálási pilothoz](https://balazscsorba.com/#rfq-automation-checklist)
10.  [Források](https://balazscsorba.com/#sources)

Cikk meghallgatása

0:000:00

Az **ajánlatkérés-automatizálás** nagy nyelvi modellekkel azt jelenti, hogy egy beérkező ajánlatkérésből, legyen az e-mail-szöveg, PDF, táblázat vagy portálexport, ajánlattervezet lesz: kinyert tételek, párosított cikkek, a szerződésekből származó árak és tételenkénti bizalmi szint, amely megmutatja az ellenőrnek, hová nézzen. Az ellenőr jóváhagy, és csak ezután hagyja el ajánlat a céget.

Ez a cikk szakaszról szakaszra végigveszi a folyamatot: hogyan olvassuk a rendezetlen ajánlatkérési dokumentumokat, hogyan párosítsuk a tételeket cikkekhez úgy, hogy ne bízzunk túlságosan a modellben, hogyan marad determinisztikus az árazás, hogyan tervezzük az ellenőrzési sort, és mit állíthat őszintén az üzleti indoklás. Az ajánlat mint verziózott munkafolyamat-objektum és maga az árazómotor külön témák; ez a cikk mindkettőre épít.

## Mit változtat valójában az ajánlatkérés-automatizálás?

Az előkészítést automatizálja, soha nem az ajánlatot. A tételek begépelése, a cikkszámok kikeresése és a szerződéses árak ellenőrzése viszi el a belső értékesítés idejét, és ezeket a lépéseket egy folyamat másodpercek alatt elvégzi. Hogy mit ajánlunk, arról továbbra is ember dönt.

A hibák költsége aszimmetrikus. Egy párosítatlan tétel, amelyet az ellenőr húsz másodperc alatt megold, normál működés. Egy rossz cikk rossz áron egy elküldött ajánlatban az egyetlen igazán fontos hiba, mert az ügyfél elfogadhatja. Mindent erre az aszimmetriára tervezzen. Legyen az is világos, mit nem old meg az automatizálás: a hiányzó szerződéses árak, a nem forgalmazott cikkek és a rossz ügyfél-törzsadatok a folyamat bevezetése után is problémák maradnak.

## A folyamat a postafióktól az ajánlattervezetig

A folyamatnak hat szakasza van, és mindegyik olyan eredményt állít elő, amelyet az ellenőr megnézhet: az eredeti dokumentum, pozíciókkal ellátott elemzett szöveg, a tételek típusos tömbje, tételenként egy találat a párosítási úttal, tételenként egy ár a forrásával, végül az ajánlattervezet tételenkénti bizalmi szinttel.

![Ajánlatkérés-automatizálási folyamat Hat szakasz balról jobbra: e-mail, PDF vagy táblázat fogadása; elemzés szöveggé és táblázatokká pozíciókkal; típusos tételek kinyerése; párosítás pontos azonosítókkal, kereszthivatkozásokkal és szemantikus kereséssel; árazás szerződésekből és az ERP-ből; végül emberi ellenőrzés, mielőtt az ajánlat kimegy.](https://balazscsorba.com/images/blog/llm-rfq-quote-automation/diagram-7.webp?v=1f376b6c11)

Az ajánlatkérési folyamat: minden szakasz olyan eredményt állít elő, amelyet az ellenőr megnézhet, és csak az utolsó, emberi szakasz küldhet ajánlatot.

A típusos tömbbe történő kinyerésnél segítenek a strukturált kimenetek, és itt ér véget a hasznuk is. A szigorú módok a JSON Schemának csak egy részhalmazát fogadják el. Az Azure OpenAI dokumentációja például minden mezőt kötelezőnek ír elő, `additionalProperties: false` beállítást kér, nem támogatja a `pattern`, `minimum` vagy `maxItems` kulcsszót, és 100 tulajdonságra, illetve öt beágyazási szintre korlátozza a sémát ([Microsoft Learn](https://learn.microsoft.com/en-us/azure/ai-foundry/openai/how-to/structured-outputs)). A mennyiségi tartományokat, a mértékegységeket és a cikkszámformátumokat ezért a kinyerés után kódban kell ellenőrizni, ahogy a [strukturált kimenetek JSON Schemával](https://balazscsorba.com/hu/blog/structured-outputs-json-schema-llm) című cikk leírja.

## Hogyan olvassuk be az ajánlatkérési dokumentumot?

Minden dokumentumot a típusa szerint irányítson, mert formátumonként más a legolcsóbb megbízható út. A valóságban vegyes anyag érkezik: e-mail-szövegbe másolt táblázatok, Excel-fájlok, egy régi táblázat beszkennelt PDF-jei, portálexportok és néha strukturált rendelési üzenet.

Útvonal

Tipikus bemenet

Költség (2026. okt.)

Tipikus hiba

Mikor használja

Csak OCR

tiszta szkennelés, egy tábla

Document AI OCR 1,50 USD/1000 oldal; Textract 0,0015 USD/oldal

összeolvadt oszlopok, szétesett sorok

csak szöveg kell

OCR táblázatokkal

szkennelt táblázatok

Textract táblák 0,015 USD/oldal

többoldalas tábla, elveszett fejléc

táblázatok dominálnak

Vision LLM keretekkel

vegyes elrendezés, jegyzetek

Mistral OCR 4.1 4 USD/1000 oldal, annotálva 5 USD

hihető, de kitalált értékek

ügyfelenként eltérő elrendezés

Natív szöveg

e-mail-szöveg, CSV, XLSX

nincs OCR-költség

félreolvasott egység, tizedesjel

mindig, elsőként

Strukturált rendelés

EDIFACT, Peppol

csak elemzés

kódlista-eltérés

az ügyfél tudja küldeni

A Peppol rendelési dokumentumai akkor is hasznos célformátumot adnak, ha senki nem küldi őket: kódlistáik megkülönböztetik a vevői, eladói és gyártói tételazonosítókat, a mértékegységekhez az UN/ECE 20. ajánlását, a pénznemekhez az ISO 4217-et használják ([Peppol BIS](https://docs.peppol.eu/poacc/upgrade-3/)). Minden útvonalat erre a formára normalizáljon. A táblázat árai a Google, az AWS és a Mistral árlistáiról származnak, 2026 októberi állapot szerint, és a modellek cserélődnek: a Mistral 2026. szeptember 29-én elavulttá nyilvánította az OCR 4.0-t, és egy nappal később kivezette ([Mistral](https://docs.mistral.ai/getting-started/models/models_overview/)), ezért a kinyerési réteg legyen cserélhető. Az általános elemzési kompromisszumokat a [PDF-feldolgozás RAG-hoz](https://balazscsorba.com/hu/blog/pdf-document-parsing-for-rag) című cikk tárgyalja.

A német nyelvű ajánlatkérések saját hosszú farkat hoznak: „Stk.” és „VE” mint mértékegység, „Lfd. Nr.” mint tételszám-oszlop, tizedesvessző és összetett főnevek a leírásokban. Ez normalizálási feladat, nem fordítási, és egy kicsi, tesztelt szabálykészletbe tartozik, nem a promptba.

## Hogyan párosítjuk az ajánlatkérés tételeit a cikkekkel?

Használjon lépcsőt: először pontos azonosítók, aztán ügyfél-kereszthivatkozási tábla, végül szemantikus keresés, és rögzítse, melyik út hozta az egyes találatokat. Az út dönti el, mennyi ellenőrzést igényel a tétel, ezért szemantikus találat soha nem kaphat akkora bizalmat, mint egy pontos.

![Cikkszám-párosítási lépcső Három párosítási út balról jobbra. A pontos azonosító találat automatikusan elfogadható. Ha nincs találat, az ügyfél-kereszthivatkozás következik, amely enyhe ellenőrzést igényel. Ha ez sem sikerül, a szemantikus vagy attribútumalapú keresés jelölteket javasol, amelyeket mindig bizonyítékpanellel kell ellenőrizni. A szemantikus úton végzett emberi javítás új kereszthivatkozási sort ír, így a jövőbeli tételek balra, az olcsóbb útra kerülnek.](https://balazscsorba.com/images/blog/llm-rfq-quote-automation/diagram-16.webp?v=a8a5eb85bb)

A párosítási lépcső: előbb az olcsó, pontos utak; a szemantikus úton végzett minden emberi javítás kereszthivatkozási sorrá válik, így idővel nő az enyhén ellenőrzött tételek aránya.

-   **Azonosítótípusonként normalizáljon.** A vevői, szállítói és gyártói cikkszám különböző azonosítótípus; a kis- és nagybetűket, szóközöket és elválasztókat típusonként normalizálja, és egy külön azonosítóindexben keressen, ne a webshop termékkeresőjében.
-   **Kezelje értékként a kereszthivatkozásokat.** Az a tábla, amely az ügyfél saját cikkszámát a saját cikkszámához rendeli, minden emberi javítással bővül, és idővel a drága útról az olcsóra tereli a tételeket.
-   **A szemantikus keresés javasol, nem dönt.** A hibrid lekérés újrarangsorolással, ahogy a [szemantikus termékkeresés B2B-ben](https://balazscsorba.com/hu/blog/semantic-product-search-b2b) című cikk leírja, jelöltlistát ad az ellenőrnek, nem választ.
-   **A csak leírásos katalógusokhoz attribútumok kellenek.** Ha egyik oldalon sincsenek stabil azonosítók, osztályozott jellemzők alapján párosítson, például ETIM szerint, amelynek legújabb modellverziója a 10.0, vagy ECLASS szerint, amely jelenleg a 16.0-s kiadásnál tart ([ETIM](https://www.etim-international.com/downloads/?_sft_downloadcategory=model-releases), [ECLASS](https://www.eclass.eu/)), és számítson alacsony automatikus elfogadási arányra.

```
// Match waterfall (sketch): exact identifiers first, semantic last, never the same confidence
type MatchPath = 'exact' | 'xref' | 'semantic'
type Match = { sku: string | null; path: MatchPath; review: 'optional' | 'light' | 'required'; evidence: unknown }

// normalize(id) applies per-type rules: case, spaces and separators for supplier numbers, etc.

async function matchLine(line: RfqLine, customer: string): Promise<Match> {
  for (const id of line.identifiers) {                      // buyer, supplier, manufacturer numbers
    const hit = await idIndex.get(id.type, normalize(id))      // dedicated identifier index, not the shop search
    if (hit) return { sku: hit.sku, path: 'exact', review: 'optional', evidence: id }
  }
  const xref = line.buyerPartNo && await crossRef.get(customer, line.buyerPartNo)
  if (xref) return { sku: xref.sku, path: 'xref', review: 'light', evidence: xref }

  const candidates = await hybridSearch(line.description, { rerank: true, k: 5 })
  return { sku: candidates[0]?.sku ?? null, path: 'semantic', review: 'required', evidence: candidates }
}
```

## Honnan jönnek az árak?

Ugyanazon az úton, amelyet a webshop is használ, soha nem a modellből. Minden párosított tételt az árazó szolgáltatás vagy az ERP áraz az ügyfél szerződéses áraival, sávjaival, pénznemével és érvényességével, a tervezet pedig minden ár forrását és időbélyegét tárolja.

Egy tételnek két legitim állapota van: árazott, forrással, vagy „ár kérésre”. A második normál üzleti állapot, és az ellenőrzési sorban is annak kell látszania. A határeseteket kifejezetten jelenítse meg: szerződéses árak, amelyek az ajánlat érvényességének vége előtt lejárnak, minimális rendelési mennyiségek és csomagolási egységek, amelyek módosítják a kért mennyiséget, nem szállítható cikkek, és olyan tételek, amelyek kereszthivatkozásra illeszkednek, de már nem eladható cikkre. A konfigurált termékek szabályproblémát jelentenek; adja át őket a konfigurátornak, ahogy a [headless termékkonfigurátorok B2B-ben](https://balazscsorba.com/hu/blog/headless-product-configurator-b2b) című cikk leírja.

## Hogyan működjön az ellenőrzési sor?

Az ellenőrzési sort kezelje magaként a termékként, mert a tételenkénti ellenőrzési percek a fő költség. A hibákat ossza két csoportba. Veszélyesek: rossz cikk, rossz ár, kitalált tétel. Ártalmatlanok: párosítatlan tétel, kétértelmű mértékegység, hiányzó szállítási dátum, elírás az ügyfél saját cikkszámában. A sor azért van, hogy az első csoportot lehetetlen legyen elküldeni, a másodikat pedig gyors legyen javítani.

-   **Bizalom jelekből, ne csak a modelltől.** Kombinálja a párosítási utat, az azonosító-ellenőrzést és a lekérési pontszámot. A modell szóban megadott bizalma rangsorolásra hasznos; Tian és társai szerint RLHF-modelleknél jobban kalibrált, mint a token-valószínűségek ([EMNLP 2023](https://arxiv.org/abs/2305.14975)), de ettől még nem olyan valószínűség, amelyre vakon küszöböt lehet tenni.
-   **Bizonyíték a tétel mellett.** Mutassa egymás mellett a dokumentum forráscelláját, a párosított cikket és az ár eredetét, hogy az ellenőrzés ellenőrzés legyen, ne keresés.
-   **Billentyűzet először, tételenként.** Minden tételt egy billentyűvel lehessen elfogadni, javítani vagy elutasítani; tömeges elfogadás csak pontos azonosítós tételeknél legyen.
-   **A javítások visszaíródnak.** A szemantikus úton végzett minden javítás kereszthivatkozási sor lesz az adott ügyfélnél.

**Az ellenőrzési sor legyen a sajátja**

A Google 2024. január 16-án elavultnak nyilvánította a Document AI Human in the Loop funkciót ([Google Cloud](https://cloud.google.com/document-ai/docs/deprecation)). Egy szállítói ellenőrzőkonzol eltűnhet, miközben a folyamata függ tőle. Egy kis saját sor tételenkénti műveletekkel és audit nyomvonallal néhány hét munka, és az Ön irányítása alatt marad.

Ugyanez az ötlet hajtja a `jev-decide` skillemet: minden elem kifejezett döntést kap bizalmi szinttel, és az alacsony bizalom emberhez kerül, nem pedig egy globális be-ki kapcsolóhoz. Az ellenőrzési sorhoz ráadásul írnék egy végponttól végpontig tartó Playwright MCP tesztet, amely betölt egy anonimizált korábbi ajánlatkérést, ellenőrzi a kinyert tételek számát és a párosításokat, és biztosítja, hogy kifejezett kattintás nélkül semmi ne menjen ki.

## Mennyit ér az ajánlatkérés-automatizálás?

Annyit ér, amennyi munkapercet megtakarít és amennyivel lerövidíti a válaszidőt, és mindkettőt a saját adatain kell mérni. Nem találtunk lektorált vagy más elsődleges tanulmányt, amely az ajánlatkérésre adott válaszidőt a nyerési aránnyal vetné össze, és ez a cikk nem is kölcsönöz ilyet.

A legközelebbi publikált bizonyíték értékesítési leadekről szól, nem ajánlatkérésekről. A Harvard Business Review 2241 amerikai céget vizsgált, és a 30 napon belül válaszolóknál 42 órás átlagos reakcióidőt talált; egy második, 1,25 millió leadet tartalmazó adatkészletben az egy órán belül kapcsolatba lépő cégek csaknem hétszer nagyobb eséllyel minősítették a leadet, mint az egy órával később jelentkezők, és több mint hatvanszor nagyobb eséllyel, mint a 24 óránál többet várók ([HBR, 2011. március](https://hbr.org/2011/03/the-short-life-of-online-sales-leads)). Ezek leadszintű, főleg B2C és tizenöt éves adatok, így az irányt támasztják alá, nem egy számot.

A költségoldal kiszámolható. A kinyerés oldalanként olcsó, a munkaidő nem. A bérkomponens viszonyítási pontja az amerikai rendelésfeldolgozók medián bére, amely az [O\*NET](https://www.onetonline.org/link/summary/43-4151.00) szerint 2025-ben óránként 22,20 dollár volt, vagyis rezsi nélkül percenként körülbelül 0,37 dollár. Használja a saját teljes költségét:

```
cost per RFQ = pages × OCR price per page
             + LLM tokens × token price
             + review minutes × loaded cost per minute

illustration, not a benchmark (as of October 2026):
  3 pages × $0.004 (Mistral OCR 4.1)           = $0.012
  review minutes × $0.37 (US order clerk median wage $22.20/h, unloaded)
  → staff time dominates; measure your own minutes before and after
```

Egy nagykereskedő értékesítési vezetőjének vagy operatív igazgatójának az igényt az „ajánlat átfutási idejének csökkentése” kifejezés írja le, a két fő mérőszám pedig a tételenkénti ellenőrzési perc és az ügyfélhez eljutó hibás párosítások aránya, amelyet az emberi kapu nullán tart.

## Mikor nem éri meg az ajánlatkérés-automatizálás?

Hagyja ki, ha kevés az ajánlatkérés, mert az ellenőrzési felület többe kerül, mint amennyit megtakarít; ha a katalógusnak egyáltalán nincsenek stabil azonosítói; ha a szerződéses árak semmilyen rendszerből nem érhetők el, mert a tervezet találgatás lenne; és minden olyan folyamatban, ahol egy hibás ajánlat ember közbeiktatása nélkül kötelező érvényű lenne.

## Ellenőrzőlista egy ajánlatkérés-automatizálási pilothoz

1.  Állítson össze 50–200 korábbi ajánlatkérésből álló referenciakészletet ismert helyes tételekkel, cikkekkel és árakkal.
2.  Mérje meg a pilot előtt az ajánlatkérésenkénti munkaperceket.
3.  Az elfogadást tételenként, párosítási út szerint bontva jelentse: pontos, kereszthivatkozás, szemantikus.
4.  A mértékegységeket, mennyiségeket és cikkszámformátumokat a kinyerés után kódban ellenőrizze.
5.  Csak a szerződéses és ERP úton árazzon; a többi tétel kapjon „ár kérésre” jelölést.
6.  Minden elküldött ajánlat legyen visszakövethető a dokumentum forrásrészéig és az árrekordig.
7.  A javításokat vezesse vissza a kereszthivatkozási táblába.
8.  Rögzítse a kinyerési modell verzióját, és minden csere után futtassa újra a referenciakészletet.

Több mint tízévnyi B2B kereskedelmi és PIM-munka után az a tapasztalatom, hogy a PIM-oldal többnyire tiszta, a beérkező ügyféldokumentumok viszont nem, ezért egy pilotban több időt fordítanék a fogadásra és az ellenőrzési sorra, mint a modellre. Néhány száz korábbi ajánlatkérésen futó, rögzített hatókörű pilot az őszinte út a számokhoz; ha ilyet tervezne, nézze meg a [B2B e-kereskedelmi munkámat](https://balazscsorba.com/hu/expertise/b2b-ecommerce-developer).

## Források

1.  [Harvard Business Review: The Short Life of Online Sales Leads (March 2011)](https://hbr.org/2011/03/the-short-life-of-online-sales-leads)
2.  [Mistral AI: OCR 4.1 model card](https://docs.mistral.ai/models/ocr-4-1)
3.  [Mistral AI: models overview and deprecations](https://docs.mistral.ai/getting-started/models/models_overview/)
4.  [Google Cloud: Document AI pricing](https://cloud.google.com/document-ai/pricing)
5.  [Google Cloud: Document AI deprecations](https://cloud.google.com/document-ai/docs/deprecation)
6.  [Amazon Textract pricing](https://aws.amazon.com/textract/pricing/)
7.  [Microsoft Learn: Azure OpenAI structured outputs](https://learn.microsoft.com/en-us/azure/ai-foundry/openai/how-to/structured-outputs)
8.  [Tian et al.: Just Ask for Calibration (EMNLP 2023)](https://arxiv.org/abs/2305.14975)
9.  [Peppol BIS Upgrade 3: ordering profiles and code lists](https://docs.peppol.eu/poacc/upgrade-3/)
10.  [ETIM International: model releases](https://www.etim-international.com/downloads/?_sft_downloadcategory=model-releases)
11.  [ECLASS: classification standard](https://www.eclass.eu/)
12.  [O\*NET OnLine: Order Clerks (43-4151.00)](https://www.onetonline.org/link/summary/43-4151.00)

## Gyakori kérdések

Mi az ajánlatkérés-automatizálás?

Az ajánlatkérés-automatizálás egy beérkező ajánlatkérésből, például e-mailből, PDF-ből vagy táblázatból ajánlattervezetet készít: kinyeri a kért tételeket, párosítja őket a saját cikkeivel, szerződésből vagy ERP-ből árazza őket, és minden tételt bizalmi szinttel és bizonyítékkal egy ellenőrhöz irányít. Az ajánlatot ember hagyja jóvá és küldi el.

Állíthat elő árat egy LLM az ajánlathoz?

Nem kellene. Az árnak ugyanabból a forrásból kell jönnie, mint a webshopban vagy az ERP-ben: az adott ügyfél szerződéses ára, sávjai és érvényessége. Ha nem oldható fel ár, a tétel „ár kérésre” jelölést kap, ami normál üzleti állapot, nem olyan hiba, amelyet a modellnek kellene kitöltenie.

Mennyire pontos az AI-alapú cikkszám-párosítás?

Ez a dokumentumban lévő azonosítóktól függ. A pontos szállítói, gyártói vagy ismert ügyfélcikkszámmal érkező tételek megbízhatóan párosíthatók és könnyen ellenőrizhetők. A csak leírással érkező tételekhez szemantikus vagy attribútumalapú párosítás kell, és ezeket mindig ellenőrizni kell. Az elfogadási arányt párosítási utanként külön mérje a saját korábbi ajánlatkérésein.

Mennyibe kerül egy ajánlatkérési dokumentum kinyerése?

2026 októberében az OCR olcsó a munkaidőhöz képest: a Mistral OCR 4.1 ára 4 dollár 1000 oldalanként, a Google Document AI OCR-é 1,50 dollár 1000 oldalanként, az Amazon Textract táblázatelemzése pedig 0,015 dollár oldalanként. Az ajánlatonkénti költséget a nyelvi modell tokenjei és főleg az ellenőrzési percek határozzák meg.

Használjak szállítói konzolt a kinyert dokumentumok emberi ellenőrzésére?

Óvatosan. A Google 2024 januárjában elavultnak nyilvánította a Document AI Human in the Loop funkciót. Egy kicsi, saját ellenőrzési sor tételenkénti elfogadással és javítással, a bizonyítékkal minden sor mellett, biztonságosabb, és a javítások visszakerülhetnek a kereszthivatkozási táblába.

Í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.

[B2B e-kereskedelem és PIM →](https://balazscsorba.com/hu/expertise/b2b-ecommerce-developer)[Rólam →](https://balazscsorba.com/hu/about)

## További cikkek

-   [Schema.org strukturált adatok B2B webshopokhoz: bejelentkezés mögötti árak, egységek és változatok](https://balazscsorba.com/hu/blog/schema-org-structured-data-b2b-shop)
-   [AI-asszisztens a B2B webshop ügyfélszolgálatához: eszközök, jogosultságok és átadás embernek](https://balazscsorba.com/hu/blog/ai-assistant-b2b-shop-customer-support)
-   [AI-csevegő UI Vue-ban és Nuxtban: akadálymentes streaming](https://balazscsorba.com/hu/blog/vue-ai-chat-ui-streaming-accessibility)
-   [LLM-fordítási pipeline i18n-hez: glosszárium, helyőrzők és review](https://balazscsorba.com/hu/blog/llm-translation-pipeline-i18n)

## 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)