> A termékadat strukturált, ezért a PDF-szerű chunkolás itt elbukik. Hogyan sorosítsd a PIM-attribútumokat, és hogyan küldd a specifikációs kérdéseket szűrőkhöz.
>
> Web page: https://balazscsorba.com/hu/blog/rag-product-catalog-pim-data · Language: Magyar · Also available in: [English](https://balazscsorba.com/blog/rag-product-catalog-pim-data.md) · [Deutsch](https://balazscsorba.com/de/blog/rag-product-catalog-pim-data.md)
> Author: Balázs Csorba · Published: 2026-10-17 · Keywords: rag product catalog, rag pim data, llm product data, product catalog chatbot, akeneo rag, pimcore ai search, rag structured data, metadata filtering rag, product attributes embeddings, b2b product assistant, etim classification ai

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

# RAG termékkatalógusra: PIM-adatokból megbízható válaszok

A termékadat strukturált, ezért a PDF-szerű chunkolás itt elbukik. Hogyan sorosítsd a PIM-attribútumokat, és hogyan küldd a specifikációs kérdéseket szűrőkhöz.

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

-   RAG
-   PIM
-   Product data
-   B2B e-commerce
-   Metadata filtering

![Kilenc négyzetből álló keret apró jelekkel, alatta tölcsér egyetlen kártyához.](https://balazscsorba.com/images/blog/rag-product-catalog-pim-data/cover.webp?v=22f9b0ebf9)

## A lényeg röviden

-   A katalóguskérdéseknek típusai vannak: a cikkszámhoz pontos keresés kell, a specifikációhoz strukturált szűrő, és csak a leíró kérdések illenek jól a vektoros kereséshez.
-   A PIM-értékek típusosak, és nyelvet, csatornát és mértékegységet hordoznak, mint az Akeneo locale, scope és data hármasai; címkékkel és mértékegységgel sorosítsd őket, soha ne nyers attribútumkódokkal.
-   Termékmodellenként egy szöveget indexelj, a változatattribútumokat pedig strukturált payloadként tárold, hogy egy méretre vagy menetre vonatkozó kérdés ne egy embeddingen múljon.
-   Az LLM egy sémába vonja ki a szűrőket, amelyet az attribútummodellel validálsz, utána szűrt hibrid keresés fut; az ár és a készlet élőben jön a webshopból, nem az indexből.
-   Lekérdezésenként elvárt SKU-kkal értékelj, az Amazon ESCI-adathalmazának Exact, Substitute, Complement és Irrelevant fogalmaival.

Ezen az oldalon

1.  [Hogyan néznek ki valójában a PIM-adatok?](https://balazscsorba.com/#what-pim-data-looks-like)
2.  [Melyik katalóguskérdéshez milyen visszakeresés kell?](https://balazscsorba.com/#question-types)
3.  [Mi legyen egy dokumentum: termék, modell vagy változat?](https://balazscsorba.com/#document-granularity)
4.  [Hogyan lesz az attribútumokból szöveg?](https://balazscsorba.com/#serializing-attributes)
5.  [Miért szűrőbe valók a specifikációk, és nem embeddingbe?](https://balazscsorba.com/#filters-not-embeddings)
6.  [Mi ne kerüljön soha az indexbe?](https://balazscsorba.com/#prices-and-freshness)
7.  [Hogyan segítenek a nyelvek és az osztályozások?](https://balazscsorba.com/#multilingual-catalogues)
8.  [Hogyan teszteld a katalógusasszisztenst?](https://balazscsorba.com/#evaluating-catalogue-rag)
9.  [Hol érdemes kezdeni?](https://balazscsorba.com/#where-to-start)
10.  [Források](https://balazscsorba.com/#sources)

Cikk meghallgatása

0:000:00

A legtöbb RAG-oktatóanyag dokumentumokból indul: PDF-ekből, wikioldalakból, kézikönyvekből. A termékkatalógus más eset. Egy PIM-ben a tudás már strukturált: típusos attribútumok, mértékegységek, változatok, osztályozások, nyelvenkénti fordítások és értékesítési csatornánkénti értékek. Ha ezt szöveggé lapítod, és úgy chunkolod, mint egy kézikönyvet, éppen azt a szerkezetet dobod el, amitől a katalóguskérdések megválaszolhatók.

Ez a cikk egy katalógusasszisztens adatoldala: hogyan néznek ki a PIM-adatok, hogyan sorosítsd őket a visszakereséshez, mely kérdések tartoznak szűrőkhöz embeddingek helyett, és hogyan teszteld, hogy a válasz a helyes SKU-t nevezi meg. A [szemantikus termékkeresés B2B-webshopokban](https://balazscsorba.com/hu/blog/semantic-product-search-b2b) cikkre épít, amely a rangsorolással foglalkozik, és feltételezi, hogy a [Pimcore–ERP deltaszinkron](https://balazscsorba.com/hu/blog/pimcore-erp-delta-sync) problémái már előrébb meg vannak oldva.

## Hogyan néznek ki valójában a PIM-adatok?

Vegyük példának az Akeneót. Egy termék `values` mezője attribútumkód szerint van kulcsolva, és minden kód `locale`, `scope` és `data` mezőkkel rendelkező értékobjektumok tömbjére mutat. Egy lokalizálható attribútumnak nyelvenként egy értéke van, egy csatornafüggőnek csatornánként egy, és ha mindkettő, akkor nyelv–csatorna páronként egy. A metrikus érték nem szám, hanem `amount`, `unit` és `symbol` mezőkből álló objektum, ahol a szimbólum a mértékegységcsaládból jön.

```
"values": {
  "name":        [{ "locale": "de_DE", "scope": null, "data": "Sechskantschraube DIN 933" }],
  "length":      [{ "locale": null, "scope": null,
                    "data": { "amount": "50", "unit": "MILLIMETER", "symbol": "mm" } }],
  "material":    [{ "locale": null, "scope": null, "data": "stainless_a2" }],
  "description": [{ "locale": "de_DE", "scope": "ecommerce", "data": "..." },
                  { "locale": "de_DE", "scope": "print",     "data": "..." }]
}
```

A változatok egy második réteget adnak hozzá. Az Akeneóban egy családváltozat egy vagy két változatszintet határoz meg, szintenként a tengelyeket, és azt, hogy mely attribútumok közösek és melyek változnak; így legfeljebb három gazdagítási szint lehet: gyökér termékmodell, al-termékmodell és változattermék. Csak a változatterméknek van SKU-ja, a termékmodellnek kódja van. A Pimcore a classification store-ral más utat jár: adattípusos kulcsok csoportokba rendezve, a csoportok objektumokhoz rendelve, opcionális lokalizációval, és mennyiségi értékekkel, amelyek egy számot egy mértékegységgel párosítanak.

Sok műszaki B2B-katalógus emellett ETIM szerint is osztályozott; a kiadó szerint ez a műszaki termékek nemzetközi osztályozási szabványa: osztályok egységes jellemzőlistával és előre meghatározott értékekkel, 17 nyelven. Az ETIM 10.0 2024 decemberében jelent meg, IXF, azaz XML formátumban. Ha a beszállítóid ETIM-adatot szállítanak, már van egy márkákon átívelő attribútumszókészleted, ami a szűrőkhöz aranyat ér.

## Melyik katalóguskérdéshez milyen visszakeresés kell?

A leghasznosabb tervezési lépés az, hogy a várható kérdéseket aszerint rendezed, milyen visszakeresést igényelnek. Egy B2B-katalógusnál egészen más keverékre számíts, mint egy támogatási wikinél: sok kérdés kikeresés vagy feltétel, kevesebb a nyitott kérdés.

Kérdés

Példa

Útvonal

Azonosító

Van 4711-050?

Pontos keresés SKU-ra, EAN-ra, beszállítói számra

Specifikáció

M8 rozsdamentes csavar, legalább 50 mm

Strukturált szűrő, utána rangsor

Összehasonlítás

Mi a különbség az X200 és az X300 között?

Mindkét rekord lekérése, attribútumok összevetése

Leíró

Valami kültérre, sós víz közelébe

Hibrid keresés a szövegen

Kapcsolat

Melyik anya illik ehhez a csavarhoz?

PIM-kapcsolatok, utána kikeresés

Kereskedelmi

Mennyibe kerül nekem, van raktáron?

Élő hívás a webshophoz vagy ERP-hez, soha nem az index

Az Amazon Shopping Queries adathalmaza jó hivatkozási alap a fogalmakhoz. Nagyjából 130 000 lekérdezése és 2,6 millió emberi relevanciaítélete minden lekérdezés–termék párt így címkéz: Exact (a lekérdezés minden feltételét teljesíti), Substitute (néhány szempontnak nem felel meg, de helyettesítheti), Complement (nem teljesíti a lekérdezést, de egy pontos találattal együtt használható) vagy Irrelevant. Egy katalógusasszisztensnek tudnia kell, a négy közül melyiket kínálja, és ki is kell mondania: a helyettesítő termék pontos találatként való bemutatása a klasszikus módja annak, hogy elveszítsd egy B2B-beszerző bizalmát.

## Mi legyen egy dokumentum: termék, modell vagy változat?

Az első ösztön a SKU-nként egy dokumentum. Változatokat tartalmazó katalógusoknál ez a szövegindexben rosszul működik. Ugyanannak a csavarnak negyven hossza osztozik a néven, a leíráson és a legtöbb attribútumon, így egy leíró lekérdezés egyetlen termék közel azonos másolataival tölti meg a legjobb találatokat, és minden alternatívát kiszorít. Negyven szinte azonos szöveg beágyazása ráadásul tárhelyet és indexelési időt visz el haszon nélkül.

Jobban működik, ha a rekordot kettéválasztod. A szövegindexbe termékmodellenként egy dokumentum kerül, a közös attribútumokból és a változattengelyek tömör összefoglalójából, például: hossz 20–120 mm, rozsdamentes A2 és A4. A változatattribútumok strukturált payloadként élnek, vagy ugyanazon a ponton a vektortárban, vagy külön táblában a modellkód szerint. A visszakeresés jelentés alapján megtalálja a modellt, a változatot pedig szűrő vagy kikeresés választja ki. A változat nélküli egyszerű termékek önmaguk modelljei.

A szöveg arra felel, mi a termék; a szerkezet arra, melyik változat.

## Hogyan lesz az attribútumokból szöveg?

A sorosító a katalógus-RAG-folyamat leginkább alábecsült része. Az embedding-modellek és az LLM-ek címkéket olvasnak, nem kódokat: a `stainless_a2` és a `MILLIMETER` keveset mond, az Anyag: rozsdamentes acél A2 és a Hossz: 50 mm sokat. Néhány szabály, amit alkalmazok:

-   **Minden kódot oldj fel a címkéjére** a célnyelven: attribútumnevek, választható opciók, mértékegységek a szimbólumukon keresztül.
-   **Válassz egy csatornát.** A csatornafüggő értékek csatornánként eltérnek; a webshop-scope-ot indexeld, ne a nyomtatott katalógus szövegét.
-   **Nyelvenként egy szöveg,** kifejezett tartalék-szabállyal, hogy egy német lekérdezés véletlenül se találjon félig angol rekordot.
-   **Hagyd ki az üres és a belső attribútumokat:** beszerzési árak, munkafolyamat-jelzők, importidőbélyegek. Zajt okoznak, és néha kiszivárognak.
-   **Az azonosítók a szövegbe is kerüljenek:** a SKU, az EAN és a beszállítói szám a BM25-mezőbe való, mert a felhasználók bemásolják őket.

```
def serialize(model, variants, locale, labels, channel="ecommerce"):
    def val(values, code):
        for v in values.get(code, []):
            if v["locale"] in (locale, None) and v["scope"] in (channel, None):
                d = v["data"]
                if isinstance(d, dict) and "amount" in d:      # metric value
                    return f'{d["amount"]} {d["symbol"]}'
                return labels.option(code, d, locale) if isinstance(d, str) else d
        return None

    lines = [f'# {val(model["values"], "name")}']
    for code in labels.common_attributes(model["family"]):
        v = val(model["values"], code)
        if v not in (None, "", []):
            lines.append(f'{labels.attribute(code, locale)}: {v}')
    # summarise the variant axes instead of repeating every variant
    for axis in labels.axes(model["family_variant"]):
        seen = sorted({str(val(x["values"], axis)) for x in variants})
        lines.append(f'{labels.attribute(axis, locale)} (variants): {", ".join(seen)}')
    lines.append("SKUs: " + " ".join(x["identifier"] for x in variants))
    return "\n".join(lines)
```

Hogy az attribútumokat kulcs–érték sorokként, Markdown-táblázatként vagy JSON-ként jeleníted meg, azt tesztelni kell, nem hinni. A Table Meets LLM tanulmány szerint az LLM-ek teljesítménye táblázatos feladatokon a bemeneti döntésektől, például a formátumtól és a tartalom sorrendjétől függően változott; a saját embedding-modelled és a saját lekérdezéseid döntik el, melyik formátum keresődik vissza a legjobban. Én címke: érték sorokkal kezdek, mert ezek a BM25-nek, az embeddingeknek és az LLM-nek egyaránt jók.

## Miért szűrőbe valók a specifikációk, és nem embeddingbe?

Egy sűrű embedding a szöveget egy irányba tömöríti, amely azt ragadja meg, miről szól. Nem arra készült, hogy megkülönböztesse a 48 mm-t az 50 mm-től, vagy tudja, hogy a legalább 50 kizárja a 48-at. A BM25 egyezik az 50-es tokennel, de a tartományokról és a mértékegységekről ő sem tud semmit. A feltételeket ezért ki kell vonni a kérdésből, és szűrőként típusos mezőkre kell alkalmazni. A vektoradatbázisok ezt közvetlenül támogatják; a Qdrantban egy `must` záradék `range` feltétellel és `gte` vagy `lte` határokkal megoldja, a dokumentáció pedig minden szűrt mezőre payload-indexet javasol.

```
{
  "query": "<embedding of: stainless hex screw for outdoor use>",
  "filter": {
    "must": [
      { "key": "thread",        "match": { "value": "M8" } },
      { "key": "material",      "match": { "any": ["stainless_a2", "stainless_a4"] } },
      { "key": "length_mm",     "range": { "gte": 50 } },
      { "key": "locale",        "match": { "value": "de_DE" } }
    ]
  },
  "limit": 20
}
```

A szűrők kivonása egy kis LLM-hívás strukturált kimenettel: add át a modellnek a szűrhető attribútumok listáját típussal, megengedett opciókkal és kanonikus mértékegységgel, és kérj vissza egy JSON-objektumot. Utána validáld kódban. Az ismeretlen attribútumkódok kiesnek, az opcióértékeknek létezniük kell, a mértékegységeket pedig összehasonlítás előtt normalizálod, így az 5 cm-ből 50 mm lesz. Ez ugyanaz a fegyelem, mint a [Text-to-SQL korlátokkal](https://balazscsorba.com/hu/blog/text-to-sql-llm-guardrails) cikkben: a modell javasol, a séma dönt. Ha egy feltételt nem lehet leképezni, maradjon a szöveges lekérdezésben ahelyett, hogy csendben eltűnne, és mondd meg a felhasználónak, mely szűrők futottak.

**Az üres attribútum nem nem**

A katalógusadatok hiányosak, a ritkán keresett cikkeknél gyakran nagyon. Ha az asszisztens korrózióállósági osztály nélküli rekordot kap, és megkérdezik, alkalmas-e a csavar sós vízhez, az őszinte válasz az, hogy az adatok ezt nem mondják meg. A hiányzó értékeket add át kifejezetten nincs megadva jelöléssel, utasítsd a modellt, hogy soha ne következtessen műszaki értékre a terméknévből vagy hasonló termékekből, és teszteld olyan kérdésekkel, amelyekről tudod, hogy üres attribútumot érintenek. Egy hibás teherbírási adat B2B-ben felelősségi kérdés, nem UX-hiba.

## Mi ne kerüljön soha az indexbe?

Az árak, a készlet és a szállítási határidők. B2B-webshopokban az ár gyakran ügyfélspecifikus, szerződéses árakkal, sávokkal és kedvezményekkel, a készlet pedig percről percre változik. Ezeknek az értékeknek az indexpillanatképe eleve hibás, és rosszabb esetben az egyik ügyfélnek a másik feltételeit mutatja. Ne kerüljenek se a szövegbe, se a payloadba. Ha a válaszhoz kellenek, az asszisztens a webshop ár- és elérhetőségi végpontját hívja a bejelentkezett ügyfél munkamenetével, ugyanúgy, ahogy a kirakat teszi. Ennek az eszközoldalát a [MI-asszisztens B2B-webshop ügyfélszolgálathoz](https://balazscsorba.com/hu/blog/ai-assistant-b2b-shop-customer-support) cikkben írtam le.

A többinél a frissesség szinkronizálási kérdés. Sorosítsd és ágyazd be újra a termékmodellt, ha bármely közös attribútuma vagy címkéje változik, és csak a payloadot frissítsd, ha egy változatattribútum változik; ez olcsó, mert nincs benne embedding. Egy megváltozott opciócímke, például egy németül átnevezett anyag, minden modellt érint, amely használja, ezért a változásérzékelést a sorosított szöveg hash-ére alapozd, ne csak a PIM módosítási időbélyegére.

## Hogyan segítenek a nyelvek és az osztályozások?

A katalógusadat gyakran jobban le van fordítva, mint bármelyik wiki, mert a PIM attribútumonként kikényszeríti a fordítást. Használd ki: nyelvenként egy sorosított szöveg, lekérdezéskor nyelv szerint szűrve, dokumentált tartalékkal hiányzó fordítás esetére. Az opciók és a mértékegységek a payloadban nyelvfüggetlenek, így a szűrők németül, angolul és magyarul ugyanúgy működnek, és csak a szövegindex nyelvspecifikus. A nyelveken átívelő visszakeresés általános kompromisszumait a [többnyelvű RAG német és magyar nyelvre](https://balazscsorba.com/hu/blog/multilingual-rag-german-hungarian) cikk tárgyalja.

Az olyan osztályozások, mint az ETIM, egy második előnnyel is járnak. Mivel egy osztálynak egységes jellemzőlistája van, a szűrőkivonó prompt osztályonként építhető fel: ha a kérdés mondjuk egy csavarosztályhoz kötődik, csak annak jellemzői kerülnek szűrőként a modell elé. Így a prompt rövid marad, a kivont szűrők pedig érvényesek, még olyan beszállítóknál is, akiknek saját attribútumnevei eltérnek.

## Hogyan teszteld a katalógusasszisztenst?

A katalógus-RAG-nek van egy előnye a dokumentum-RAG-gel szemben: az alapigazság egyértelmű. Minden tesztlekérdezéshez leírhatod a helyes SKU-kat vagy termékmodelleket, így a visszakeresés értékelése azonosítókon mért találati arány és recall@k lesz, nem szövegrészek megítélése. A készletet keresési naplókból és értékesítési kérdésekből építem fel, a fenti táblázat kérdéstípusai szerint csoportosítva, és az elvárt eredményeket ESCI-kategóriákkal címkézem, hogy egy helyettesítő ne számítson találatnak. Magukat a metrikákat a [RAG értékelése](https://balazscsorba.com/hu/blog/rag-evaluation-metrics) cikk tárgyalja.

-   **Azonosító-lekérdezések:** 100% pontos találatot várj; ami ennél kevesebb, az tokenizáló- vagy mezőleképezési hiba, nem modellprobléma.
-   **Specifikációs lekérdezések:** a kivont szűrőt vesd össze egy kézzel írt elvárt szűrővel, mielőtt az eredményeket nézed.
-   **Hiányzó adatra vonatkozó lekérdezések:** a helyes válasz a nincs megadva; a kitalált értékek hibának számítanak.
-   **Kereskedelmi lekérdezések:** ellenőrizd, hogy az ár az élő hívásból jön, két eltérő feltételű ügyféllel tesztelve.

## Hol érdemes kezdeni?

A sorosítóval és az azonosítós útvonallal kezdj, mert olcsók, és a legkínosabb hibákat tüntetik el. Utána add hozzá a szűrőkivonást ahhoz az öt–tíz attribútumhoz, amely a valódi kérdésekben a leggyakrabban szerepel, nem mindhez. Csak ezután hangold a szövegindexet, a chunkméreteket és a rerankereket. Ha a katalógusod strukturált adatokkal is megjelenik, ugyanaz az attribútumleképezés mindkettőt táplálhatja, ahogy a [Schema.org strukturált adatok B2B-webshopokhoz](https://balazscsorba.com/hu/blog/schema-org-structured-data-b2b-shop) cikkben leírtam. A mögöttes minta egyszerű: a PIM már elvégezte a termékismeret strukturálásának nehéz munkáját, egy jó katalógusasszisztens pedig ezt a szerkezetet egészen a válaszig megőrzi.

## Források

1.  [Akeneo API: Products, product values, metric values and product models](https://api.akeneo.com/concepts/products.html)
2.  [Akeneo Help Center: What about products with variants?](https://help.akeneo.com/serenity-take-the-power-over-your-products/serenity-what-about-products-with-variants)
3.  [Pimcore documentation: Classification Store](https://docs.pimcore.com/platform/Pimcore/Objects/Object_Classes/Data_Types/Classification_Store/)
4.  [ETIM International: Classification](https://www.etim-international.com/classification/)
5.  [ETIM International: ETIM releases and the IXF format](https://etim-international.com/?p=754)
6.  [Reddy et al.: Shopping Queries Dataset, a large-scale ESCI benchmark for improving product search (2022)](https://arxiv.org/abs/2206.06588)
7.  [Amazon Science: esci-data repository](https://github.com/amazon-science/esci-data)
8.  [Qdrant documentation: Filtering](https://qdrant.tech/documentation/concepts/filtering/)
9.  [Sui et al.: Table Meets LLM, can large language models understand structured table data? (WSDM 2024)](https://arxiv.org/abs/2305.13062)

## Gyakori kérdések

Beágyazhatom egyszerűen a termékexportot, és használhatok RAG-ot?

Igen, és a leíró kérdésekre elfogadhatóan fog válaszolni. A cikkszámoknál, a numerikus specifikációknál és a változatok közti különbségeknél viszont elbukik, mert az embeddingek nem hasonlítanak össze megbízhatóan számokat és pontos kódokat. Kombináld a szövegindexet az attribútumokon futó strukturált szűrőkkel.

Minden változat külön dokumentum legyen?

A szövegindexben általában nem. Egy termékmodell változatai szinte ugyanazt a szöveget tartalmazzák, ezért kiszorítják egymást a legjobb találatok közül. A termékmodellt indexeld, a változatattribútumokat payloadként tárold, a pontos változatot pedig szűrővel vagy lekérdezéssel oldd fel.

Honnan jön az ár és a készlet?

A válasz pillanatában a webshopból vagy az ERP-ből. B2B-ben az ár gyakran ügyfélspecifikus, a készlet folyamatosan változik, így egy indexpillanatkép eleve hibás. Az asszisztens a bejelentkezett ügyfél kontextusával hívjon meg egy ár- és elérhetőségi végpontot.

Segít az ETIM a RAG-ban?

Igen, ahol az adataid ezzel vannak osztályozva. Az ETIM osztályokat definiál egységes jellemzőlistával és előre meghatározott értékekkel, ami beszállítóktól függetlenül konzisztens attribútumneveket ad a szűrőkhöz, és többnyelvű szókészletet is.

Hogyan akadályozom meg, hogy az asszisztens specifikációkat találjon ki?

Az attribútumértékeket strukturált adatként, mértékegységgel add át a modellnek, utasítsd, hogy csak ezekből válaszoljon, és az üres attribútumot kezeld kifejezetten „nincs megadva” értékként. Teszteld olyan attribútumokra vonatkozó kérdésekkel, amelyekről tudod, hogy hiányoznak.

Í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

-   [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)
-   [Lekérdezés-újraírás beszélgetésalapú kereséshez: kontextus, HyDE és szűrők](https://balazscsorba.com/hu/blog/conversational-search-query-rewriting)

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