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

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.

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

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). 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), ezért a kinyerési réteg legyen cserélhető. Az általános elemzési kompromisszumokat a PDF-feldolgozás RAG-hoz 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.

• 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 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, ECLASS), é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 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), 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.

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

Források

1. Harvard Business Review: The Short Life of Online Sales Leads (March 2011)
2. Mistral AI: OCR 4.1 model card
3. Mistral AI: models overview and deprecations
4. Google Cloud: Document AI pricing
5. Google Cloud: Document AI deprecations
6. Amazon Textract pricing
7. Microsoft Learn: Azure OpenAI structured outputs
8. Tian et al.: Just Ask for Calibration (EMNLP 2023)
9. Peppol BIS Upgrade 3: ordering profiles and code lists
10. ETIM International: model releases
11. ECLASS: classification standard
12. O*NET OnLine: Order Clerks (43-4151.00)