Vorig jaar kwam een van onze klanten -- een distributeur van zware apparatuur met meer dan 400.000 SKU's -- naar ons met een probleem dat pijnlijk bekend is in onderdelen-e-commerce: hun klanten konden niet vinden wat ze nodig hadden. Niet omdat de onderdelen niet in de catalogus stonden, maar omdat niemand de zoekbalk in loopt wetende dat de rubber pakking die ze nodig hebben onderdeel nummer 7R-4864 is. Ze weten dat het "het ronde zwarte afdichtingsstuk op de hydraulische pomp van een Cat 320" is. Of ze hebben een foto van een gebarsten onderdeel en verder niets.

Dit is waar AI-onderdeelzoekers van pas komen. Niet als een sciencefiction-concept, maar als iets dat je vandaag daadwerkelijk kunt bouwen en implementeren op een moderne headless webstack. Ik heb de afgelopen 18 maanden aan dit soort systemen gewerkt, en ik wil je laten zien wat echt is, wat hype is, en hoe je het architectuur.

Inhoudsopgave

Het probleem met traditioneel onderdelen zoeken

Traditionele onderdelencat alogi werken op een eenvoudige aanname: de gebruiker kent het onderdeelnummer, de OEM-referentie of de exacte productnaam. In werkelijkheid is dat maar 30-40% van de tijd waar. De rest van de tijd staart je klant naar een gebroken onderdeel, googelt fragmenten tekst die erop gestempeld staan, of probeert iets te beschrijven wat ze nauwelijks begrijpen.

Dit gebeurt meestal:

  1. Klant zoekt "waterpompafdichting" -- krijgt 847 resultaten over 12 apparatuurlijnen
  2. Klant probeert te filteren op apparatuurmodel -- de filtertaxonomie komt niet overeen met hoe ze over hun machine denken
  3. Klant belt je ondersteuningslijn -- houdt een personeelslid 15 minuten bezig om iets te matchen wat automatisch had kunnen gaan
  4. Klant geeft op -- gaat naar een concurrent of Amazon

De gegevens ondersteunen dit. Industriestudies van 2024-2025 laten zien dat onderdelen-e-commerce-sites met alleen trefwoordzoeking winkelwagenverlatingscijfers van meer dan 75% hebben. Dit is geen UX-probleem dat je met betere knopkleuren kunt oplossen. Het is een fundamenteel zoekprobleem.

De kosten van het fout doen zijn aanzienlijk. Een onderdelendistributeur waarmee we werkten schatte dat ze jaarlijks 2,3 miljoen dollar verloren door verlaten zoekopdrachten -- klanten die zochten, niets nuttigs vonden en weggingen. Hun ondersteuningsteam behandelde meer dan 400 oproepen per dag die in wezen "help me het juiste onderdeel te vinden" waren.

Hoe AI-onderdeelidentificatie daadwerkelijk werkt

Laten we dit demystificeren. AI-onderdeelidentificatie is niet één technologie -- het is een stack van mogelijkheden die samenwerken. In de kern los je een matchingprobleem op: neem een ambigue input (een foto, een beschrijving, een partieel nummer) en kaart deze toe aan een specifieke SKU in je catalogus.

De drie invoermodi

De meeste AI-onderdeelzoekers ondersteunen drie soorten invoer:

  • Tekstbeschrijving: "De rubberen riem die rond de dynamo van een 2019 Cummins ISX15 loopt"
  • Visueel uploaden: Een foto van het onderdeel, gemaakt met een telefooncamera
  • Gedeeltelijke identificatoren: Een fragment van een onderdeelnummer, een fabrikantscode gestempeld op het onderdeel, of zelfs een streepjesscan

Elke modus vereist verschillende AI-mogelijkheden, maar ze convergeren allemaal op dezelfde haallaaag.

De pijplijn

Dit is hoe de pijplijn in de praktijk eruit ziet:

Gebruikersinput (tekst/afbeelding/partieel nummer)
    ↓
Invoerverwerking (NLP / Computer Vision / OCR)
    ↓
Functie-extractie (embeddings, visuele kenmerken, entiteitsextractie)
    ↓
Gelijkaardigheidszoeken (vectordatabasequery tegen catalogusembeddings)
    ↓
Rangschikking & filtering (compatibiliteitscontrole, beschikbaarheid, vertrouwensscore)
    ↓
Resultaten (topovereenkomsten met vertrouwen %, compatibele alternatieven)

De magie -- als we het zo willen noemen -- gebeurt in de inbeddings- en retrieval-stappen. Je zet zowel de query van de gebruiker als je hele onderdelencat alogi om in vectorrepresentaties in dezelfde inbeddings-ruimte, en vindt vervolgens de dichtstbijzijnde overeenkomsten.

Visueel onderdelen zoeken: Computer Vision in de praktijk

Visuele onderdeelidentificatie is de opvallendste functie, en eerlijk gezegd is het het afgelopen jaar opmerkelijk goed geworden. Hier is hoe we het benaderen.

Hoe het onder de motorkap werkt

Wanneer een klant een foto van een onderdeel uploadt, moet het systeem:

  1. Het onderdeel detecteren in de afbeelding (scheidt het van de achtergrond, handen, werkbank, enzovoort)
  2. Visuele kenmerken extraheren -- vorm, afmetingen ten opzichte van bekende referenties, oppervlaktekenmerken, aansluitingstypen, bevestigingspunten
  3. OCR uitvoeren op zichtbare tekst -- onderdeelnummers gestempeld in metaal, labels, fabrikantaanduidingen
  4. Tegen de catalogus matchen met behulp van zowel visuele gelijkenis als geëxtraheerde tekst

Multimodale modellen zoals GPT-4o, Gemini 2.5 Pro en Claude's visiekenmerken hebben dit spel dramatisch veranderd. In plaats van scratch custom computer vision-pijplijnen te bouwen (wat we 2 jaar geleden met YOLO + custom classifiers deden), kun je nu een afbeelding naar een multimodaal model sturen met cataloguscontext en verbazingwekkend nauwkeurige identificatie krijgen.

import openai

def identify_part(image_base64, equipment_context=None):
    messages = [
        {
            "role": "system",
            "content": """You are a spare parts identification specialist. 
            Analyze the uploaded image and identify the part. Extract:
            - Part type/category
            - Visible markings, numbers, or text
            - Physical characteristics (material, color, shape, approximate size)
            - Likely equipment compatibility
            Return structured JSON with your identification and confidence score."""
        },
        {
            "role": "user",
            "content": [
                {"type": "text", "text": f"Identify this part. Equipment context: {equipment_context or 'unknown'}"},
                {"type": "image_url", "image_url": {"url": f"data:image/jpeg;base64,{image_base64}"}}
            ]
        }
    ]
    
    response = openai.chat.completions.create(
        model="gpt-4o",
        messages=messages,
        response_format={"type": "json_object"}
    )
    return response.choices[0].message.content

Maar hier is wat de blogposts en verkoopverhalen je niet zullen vertellen: multimodale modellen alleen zijn niet voldoende voor productieonderdeelidentificatie. Ze zijn geweldig in het zeggen "dit is een hydraulische cilinderapakking" maar waardeloos in het zeggen "dit is specifiek onderdeelnummer 4J-0524 uit de revisie van 2018." Je hebt een retrieval-laag nodig erboven.

De retrieval-laag

De echte architectuur combineert het algemene begrip van de AI met je specifieke catalogusgegevens:

  1. Pre-proces je catalogus: genereer inbeddings voor elk onderdeel (met productbeschrijvingen, specs, en idealiter referentieafbeeldingen)
  2. Gebruik het multimodale model om kenmerken uit de foto van de klant te extraheren
  3. Query je vectordatabase (Pinecone, Weaviate, Qdrant -- we hebben goed resultaat gehad met alles drie) voor dichtste buren
  4. Herrangschik resultaten met behulp van bedrijfslogica (apparatucompatibiliteit, populariteit, beschikbaarheid)

Deze hybride benadering haalt consistent 85-92% nauwkeurigheid op eerste overeenkomstidentificatie voor cat alogi onder 100K SKU's. Voor grotere cat alogi daalt nauwkeurigheid tot 70-80% op de eerste overeenkomst maar blijft boven 95% binnen de top 5 resultaten.

Op NLP gebaseerd onderdelen zoeken: beschrijving naar onderdeelnummer

Op tekst gebaseerd onderdelen zoeken is eigenlijk het meer voorkomende geval, en het is waar je de grootste ROI krijgt. De meeste klanten typen een beschrijving voordat ze een foto maken.

Verder gaan dan trefwoordzoeken

Traditionele zoekmachines matchen trefwoorden. Een klant die "alternatoriem voor Cat 320D" zoekt, moet het systeem begrijpen dat:

  • "Alternatoriem" is de onderdelecategorie
  • "Cat" betekent Caterpillar
  • "320D" is het apparatuurmodel
  • De werkelijke catalogusitem kan "V-riem, alternatoraandrijving" zeggen voor een "Caterpillar 320D L hydraulische graafmachine"

Op NLP gebaseerde onderdeelzoekers gebruiken semantisch zoeken -- het matchen van betekenis, niet alleen woorden. Dit is een vereenvoudigde versie van hoe we dit instellen:

// Voorbeeld: verwerking van een natuurlijke taalonderdelenquery
import { OpenAI } from 'openai';

interface ParsedQuery {
  partCategory: string;
  equipmentMake: string;
  equipmentModel: string;
  characteristics: string[];
  rawDescription: string;
}

async function parsePartsQuery(query: string): Promise<ParsedQuery> {
  const openai = new OpenAI();
  
  const response = await openai.chat.completions.create({
    model: 'gpt-4o-mini', // Snel en goedkoop voor parsing
    messages: [
      {
        role: 'system',
        content: `Extract structured part search parameters from the user's description.
        Resolve common abbreviations: Cat=Caterpillar, Deere=John Deere, Kommy=Komatsu, etc.
        Return JSON with: partCategory, equipmentMake, equipmentModel, characteristics[], rawDescription`
      },
      { role: 'user', content: query }
    ],
    response_format: { type: 'json_object' }
  });
  
  return JSON.parse(response.choices[0].message.content!);
}

Eenmaal je de intentie hebt geparseerd, combineer je gestructureerde filtering (apparatuumerk/model) met semantisch zoeken (vectorgelijkenis op de onderdelenbeschrijving). Deze tweelingsfasebenadering is dramatisch nauwkeuriger dan beide benaderingen alleen.

Conversationele verfijning

De beste AI-onderdeelzoekers geven niet alleen resultaten terug -- ze stellen verduidelijkingsvragen. Als iemand "filter voor mijn vrachtwagen" zoekt, moet het systeem vragen: Welk merk en model? Is dit een olie filter, luchtfilter, brandstoffilter of interieurfilter? Welk jaar?

Deze conversationele benadering, gebouwd met een LLM die het dialoog handelt, kan identificatienauwkeurigheid verhogen van 60% naar 95%+ door de juiste context te verzamelen voordat je zoekt.

Architectuur voor een AI-onderdeelzoeker op een headless stack

Dit is waar het interessant wordt voor webontwikkelaars. Het bouwen van een AI-onderdeelzoeker is niet alleen een AI-probleem -- het is een webarchitectuurprobleem. Je moet realtime afbeeldinguploads verwerken, AI-reacties streamen, een vectordatabase samen met je productcat alogi beheren, en het geheel snel houden.

We bouwen deze op een headless architectuur, meestal met Next.js op de frontend en een headless CMS die de productcat alogi beheert. Dit is waarom dit belangrijk is.

De stack

┌─────────────────────────────────┐
│  Next.js Frontend (App Router)  │  ← Afbeelding uploaden, chat UI, resultaten
├─────────────────────────────────┤
│  API Routes / Edge Functions    │  ← Query parsing, orchestratie
├─────────────────────────────────┤
│  AI Services Layer              │
│  ├── OpenAI / Anthropic API     │  ← NLP + Vision
│  ├── Vector DB (Pinecone)       │  ← Gelijkaardigheidszoeken
│  └── OCR Service (optional)     │  ← Tekstextractie uit afbeeldingen
├─────────────────────────────────┤
│  Headless CMS + PIM             │  ← Productgegevens, specs, afbeeldingen
│  (Sanity / Contentful / custom) │
├─────────────────────────────────┤
│  ERP / Inventory System         │  ← Beschikbaarheid, prijsstelling
└─────────────────────────────────┘

De headless CMS bevat je onderdelencat alogi -- beschrijvingen, specificaties, compatibiliteitsgegevens, referentieafbeeldingen. Tijdens een nightly (of real-time) synchronisatie genereer je vectorinbeddings voor elk onderdeel en push je ze naar je vectordatabase. Wanneer een query binnenkomt, orkestreert de Next.js API-route de hele pijplijn.

Als je een op Next.js gebaseerde onderdelencat alogi runt, heeft ons Next.js-ontwikkelingsteam dit exacte patroon voor meerdere klanten gebouwd. De sleutelinsight is dat de AI-onderdeelzoeker geen afzonderlijk product is -- het is een laag bovenop je bestaande catalogusinfrastructuur.

Voor content-zware onderdelencat alogi waarbij SEO belangrijk is (en het is altijd belangrijk voor onderdelen), hebben we deze ook op Astro gebouwd voor de statische cataloguspagina's met interactieve AI-zoekcomponenten gehydreerd op de client. Het beste van beide werelden: snelle statische pagina's die Google leuk vindt, met dynamisch AI-zoeken als de gebruiker het nodig heeft.

AI-onderdeelidentificatiebenadering vergelijken

Hier is een breakdown van de belangrijkste benaderingen, gebaseerd op wat we daadwerkelijk hebben getest:

Benadering Nauwkeurigheid (eerste overeenkomst) Snelheid Kosten per query Het best voor Beperkingen
Multimodaal LLM (GPT-4o/Gemini) direct 60-75% 2-5s $0,02-0,08 Algemene identificatie Kan specifieke SKU's zonder cataloguscontext niet matchen
Semantisch zoeken + vectordatabase 75-85% 200-500ms $0,001-0,005 Op tekst gebaseerde queries Mist visueel-alleen aanwijzingen
Hybride (LLM + vectordatabase + bedrijfsregels) 85-95% 1-3s $0,01-0,05 Productie-onderdeelzoekers Complexer om te bouwen en onderhouden
Custom CV-model (getraind op je catalogus) 90-97% 100-300ms $0,001-0,01 Hoog volume, specifieke domeinen 3-6 maanden om te trainen, heeft gelabelde gegevens nodig
PLM-ingebakt (PTC Windchill AI, Siemens) 88-95% 1-2s $50-200/gebruiker/maand Enterprise-fabrikanten PLM-lock-in, niet klantgericht

Voor de meeste onderdelen-e-commerce-sites is de hybride benadering de sweet spot. Je krijgt uitstekende nauwkeurigheid zonder de 6-maanden investering van het trainen van een custom model.

Implementatie in de praktijk: wat we hebben geleerd

Datakwaliteit is alles

Ik kan dit niet genoeg benadrukken. Je AI-onderdeelzoeker is slechts zo goed als je catalogusgegevens. Als je productbeschrijvingen "SEAL KIT" zijn zonder verdere context, geen hoeveelheid AI-magie zal helpen. Voordat je de AI-laag bouwt, investeer in het verrijken van je catalogus:

  • Volledige tekstbeschrijvingen met afmetingen, materialen en toepassingen
  • Apparatucompatibiliteitskaarten (merk → model → jaar → systeem → onderdeel)
  • Meerdere referentiefotos per onderdeel (verschillende hoeken, geïnstalleerde weergave, vergelijking met hand voor schaal)
  • Cross-referentiegegevens (OEM-nummer → aftermarketalternatieven)

We besteden doorgaans 40-60% van een onderdeelzoeker-project aan datavoorbereiding. Het is niet sexy, maar het is waar nauwkeurigheid leeft.

Als je complexe productgegevens over meerdere bronnen beheert, geeft een headless CMS-setup je de flexibiliteit om deze gegevens correct te structureren en deze bloot te stellen aan zowel je storefront als je AI-pijplijn.

Edge cases zullen je dempen

Enkele echte scenario's die onze vroege modellen brak:

  • Versleten onderdelen: Een sterk gecorrodeerde bout ziet er totaal anders uit dan de catalogusfoto van een glanzend nieuw
  • Dubbelzinnige onderdelen: Een gewone rubberen O-ring kan één van 5.000 SKU's zijn zonder dimensionale gegevens
  • Regionale naamgeving: "Circlip" vs "snap ring" vs "retaining ring" -- hetzelfde onderdeel, drie namen
  • Fotokwaliteit: Klanten nemen foto's in donkere motorruimten met olieachtige telefoonkamera's

Je handelt deze af met sierlijke degradatie. Wanneer de AI niet zeker is (onder 70% overeenkomst), schakel naar een geleide flow: "Ik denk dat dit een hydraulische afdichting kan zijn. Kun je me vertellen..." en begeleid ze door verfijning.

De vertrouwensscore is belangrijk

Zet altijd een vertrouwensscore aan de gebruiker bloot. "95% overeenkomst" bouwt vertrouwen en drijft conversies. "Hier zijn enkele opties die kunnen overeenkomen" als het vertrouwen lager is, is eerlijk en nog steeds nuttig. Presenteer nooit een 40% overeenkomst als een definitief antwoord -- zo verzend je verkeerde onderdelen en eet je retourkosten.

Prijzen en kostenoverweging in 2025

Laten we echte nummers bespreken. Het bouwen van een AI-onderdeelzoeker heeft drie kostendimensies:

AI API-kosten

  • GPT-4o (voor visueel + tekst): ~$2,50/1M invoertokens, $10/1M uitvoertokens. Een typische onderdelenquery met een afbeelding kost ongeveer $0,03-0,08
  • GPT-4o-mini (voor tekstparsing): ~$0,15/1M invoertokens. Ongeveer $0,001-0,003 per query
  • Anthropic Claude 3.5 Sonnet: ~$3/1M invoertokens. Vergelijkbare per-querykosten als GPT-4o
  • Inbeddingsgeneratie (OpenAI text-embedding-3-large): $0,13/1M tokens. Eenmalige kosten per catalogusitem

Voor een site met 10.000 AI-ondersteunde zoekopdrachten per dag, verwacht je $300-800/maand in API-kosten met de hybride benadering.

Infrastructuurkosten

  • Pinecone (vectordatabase): Starter is gratis, Standard begint bij ~$70/maand voor 1M vectoren
  • Weaviate Cloud: Vanaf $25/maand voor kleine catalogi
  • Vercel (hosting van de Next.js frontend): Pro op $20/maand per teamlid, Enterprise voor hoog verkeer

Ontwikkelingsinvestering

Een productie-AI-onderdeelzoeker van nul af aan bouwen: 8-16 weken voor een team van 2-3 ontwikkelaars. Budget $40.000-$120.000 afhankelijk van catalogusgrootte en complexiteit. Je kunt onze prijzenpagina zien voor hoe we deze engagements structureren, of neem contact op als je specifieke zaken wilt bespreken.

De ROI-wiskunde werkt meestal snel uit. Als je slechts 100 ondersteuningsgesprekken per dag bespaart tegen $8-12 per gesprek, dat is $25.000-$36.000/maand in ondersteuningskostenbesparing alleen -- vóór het rekenen van de verhoging in conversiecijfer uit beter zoeken.

Prestatiebanken en wat je mag verwachten

Op basis van implementaties waaraan we hebben gewerkt en industriegegevens uit 2025:

  • Zoeken-naar-winkelwagen-conversie: AI-ondersteund onderdelen zoeken verhoogt conversie met 35-60% in vergelijking met alleen trefwoord zoeken
  • Ondersteuningsticketreductie: 40-65% afname van "help me een onderdeel te vinden" contacten
  • Gemiddelde tijd om onderdeel te vinden: Daalt van 4-8 minuten tot 30-90 seconden
  • Eerste-overeenkomst-nauwkeurigheid: 85-92% voor hybride benaderingen op catalogi onder 100K SKU's
  • Klanttevredenheid: NPS-toenames van 15-25 punten gerapporteerd door vroege gebruikers

PTC rapporteert dat hun Windchill AI 10-100x sneller onderdeelmatching in ondernemingsomgevingen bereikt. Siemens Xcelerator claimt 40-55% sneller BOM-navigatie met platte Engelse queries. Dit zijn PLM-schaalgetallen, maar het patroon geldt ook voor e-commerce.

Het OpenAI o3-model, uitgebracht eind 2025, introduceerde chain-of-thought-redenering dat bijzonder nuttig is voor meerstaps-onderdeelidentificatie -- zoals achteruit werken van een symptoom ("mijn motor oververhit zich") naar het waarschijnlijk gefaalde onderdeel naar het vervangingsonderdeelnummer.

Veelgestelde vragen

Hoe nauwkeurig is AI-onderdeelidentificatie van een foto? Met een goed gebouwd hybride systeem (multimodaal AI + vectordatabase + je catalogusgegevens), verwacht je 85-92% eerste-overeenkomst-nauwkeurigheid voor catalogi onder 100K SKU's. Nauwkeurigheid daalt voor sterk versleten onderdelen of foto's van slechte kwaliteit, maar top-5-resultaten blijven meestal boven 95%. Custom-getrainde computer vision-modellen voor specifieke productdomeinen kunnen eerste-overeenkomst-nauwkeurigheid naar 90-97% duwen, maar ze vereisen aanzienlijke gelabelde trainingsgegevens en 3-6 maanden ontwikkeling.

Wat als de beschrijving van de klant vaag is of verkeerde terminologie gebruikt? Dit is precies waar NLP glinster. Moderne taalmodellen begrijpen synoniemen, regionale terminologie, en zelfs typfouten. "Het spinnerige ding dat de batterij oplaadt" kan met hoog vertrouwen op "dynamo" worden gekaart. De sleutel is het bouwen van een conversationele verfijningsstroom -- wanneer de AI niet zeker is, stelt het verduidelijkingsvragen over apparatutype, locatie op de machine, of fysieke kenmerken in plaats van troep resultaten terug te geven.

Hoeveel kost het om een AI-onderdeelzoeker te bouwen? Een productie-klare AI-onderdeelzoeker kost meestal $40.000-$120.000 om te bouwen, afhankelijk van cataloguscomplexiteit. Doorlopende AI-servicekosten bedragen $300-$800/maand voor 10.000 dagelijkse zoekopdrachten met behulp van de hybride benadering. Vectordatabasehosting voegt $25-$100/maand toe. De meeste bedrijven zien positieve ROI binnen 2-4 maanden door verminderde ondersteuningskosten en verhoogde conversiesnelheden.

Kunnen AI-onderdeelzoekers werken met bestaande e-commerce-platforms? Ja, maar het is gemakkelijker met headless architecturen. Als je op Shopify, BigCommerce of een legacy-platform bent, kun je een AI-zoeklaag via API-integratie toevoegen. Headless-setups met Next.js of Astro geven je meer controle over de zoekervaring en nauwere integratie met de AI-pijplijn. De AI-laag zit tussen je frontend en je productgegevens -- het vervangt je e-commerce-platform niet.

Welke gegevens moet ik voorbereiden voordat ik AI-onderdeelidentificatie implementeer? Minimaal: gedetailleerde productbeschrijvingen, apparatucompatibiliteitskaarten en minimaal één referentiefoto per onderdeel. Hoe meer gestructureerde gegevens je hebt (afmetingen, materialen, cross-verwijzingen naar OEM-nummers, installatiehandleidingen), hoe beter de AI presteert. Plan om 40-60% van je projecttijdlijn aan datavoorbereiding en -verrijking door te brengen. Slechte gegevens erin betekent slechte resultaten eruit -- geen AI-model kan een catalogus repareren waarbij alles "MISC PART" genoemd wordt.

Hoe gaat visueel onderdelen zoeken om met onderdelen die er hetzelfde uitzien maar verschillende specs hebben? Dit is één van de moeilijkste problemen. Een O-ring van 25 mm ziet er identiek uit als een van 26 mm in een foto. Goede systemen hanteren dit door: (1) de klant vragen om een referentieobject voor schaal op te nemen, (2) apparatucontext gebruiken om mogelijkheden te beperken, (3) meerdere overeenkomsten met duidelijk gespecificeerde verschillen gemarkeerd weergeven, en (4) integratie met meettaken waar mogelijk. De AI mag nooit stiekem één kiezen als er meerdere visueel identieke onderdelen bestaan.

Wat is het verschil tussen PLM-gebaseerde onderdeelzoekers en e-commerce-onderdeelzoekers? PLM-tools zoals PTC Windchill AI en Siemens Xcelerator zijn ontworpen voor interne engineeringteams die met CAD-modellen en stuklijsten werken. Ze zijn krachtig maar kosten $50-200/gebruiker/maand en vereisen PLM-ecosysteem-aankoop. E-commerce-onderdeelzoekers zijn klantgericht, moeten messy real-world inputs verwerken (telefooncamera's, vage beschrijvingen), en moeten snel en vergevingsgezind zijn. Ze zijn gebouwd op algemene AI-API's en vectordatabases, meestal veel minder kosten per query.

Zullen AI-onderdeelzoekers onderdelentoonbankpersoneel vervangen? Niet helemaal, maar ze veranderen de baan. AI handelt de routine 70-80% van queries af -- de eenvoudige identificaties waar iemand gewoon hulp nodig heeft om de juiste SKU te vinden. Complexe zaken (aangepaste wijzigingen, verouderde apparatuur, "het maakt een raar geluid" diagnostiek) hebben nog steeds ervaren mensen nodig. De beste implementaties leiden lastige zaken naar menselijke experts met de voorlopige analyse van de AI al bijgevoegd, waardoor de menselijke interactie sneller en productiever wordt.