De agent bleef antwoorden. Zijn kennis was hij kwijt.

Een student bouwde een AI-agent voor een afstudeerproject. De agent beantwoordde technische vragen uit een map met handleidingen van fabrikanten, opgeslagen als pdf-bestanden in een documentbibliotheek in de cloud. De student publiceerde de agent, en die werkte een paar dagen. Daarna, na een testperiode met een aantal vragen, stopte de agent met synchroniseren met zijn kennisbank (knowledge base). Dat meldde de student op het communityforum van de leverancier.

De agent bleef gepubliceerd. Hij bleef antwoorden geven. Maar hij gebruikte de handleidingen niet meer, terwijl hij juist was gebouwd om daaruit te antwoorden. De student meldde ook dat het platform niet vertelde waarom de synchronisatie was gestopt.

Van buiten leek het nog steeds een werkende agent.

Een gebruiker die een agentbuilder op een eigen server in Docker draait, meldde op de issuetracker van het project dat een flow na een upgrade stopte met indexeren. Een webapplicatie stuurde Word-bestanden naar de flow. De flow knipte elk bestand in stukken en sloeg die op in een vectordatabase. Na de upgrade gaf de aanroep nog steeds 'geslaagd' terug, en de eigen geschiedenis van de server toonde de aanroep. Maar er werd niets nieuws geïndexeerd, en er was geen foutmelding. Een latere versie was nog steeds kapot.

Een gebruiker die een platform voor LLM-apps op een eigen server draait, meldde op de issuetracker van het project dat een gepubliceerde chatapp een deel kwijtraakte van wat de kenniszoekopdracht vond. De zoekstap vond stukken van documenten met afbeeldingen erbij. In de preview van de builder, uitgevoerd met het eigen account van de gebruiker, bereikten de afbeeldingen het model. Bij eindgebruikers van de gepubliceerde app gebeurde dat nooit. De run slaagde, zonder foutmelding en zonder logregel. Het model schreef zijn antwoord alleen op basis van de bijschriften. De gebruiker telde de runs op de eigen server over zeven dagen: 19 preview-runs, waarvan 5 met afbeeldingen; 24 runs van eindgebruikers, geen enkele met afbeeldingen.

In elk geval bleef de agent, of de flow erachter, gewoon werken. Er kwamen antwoorden. Aanroepen gaven 'geslaagd' terug. Wat ontbrak, was de kennis: een documentmap die niet meer synchroniseerde, bestanden die nooit werden geïndexeerd, afbeeldingen die het model nooit bereikten.

Geen van de drie gaf een foutmelding. Elk van hen vond het gat omdat ze ernaar zochten.

Een groen vinkje bij een run zegt dat de run is afgelopen. Het zegt niet dat de agent zijn kennis had toen hij antwoordde. Meer over runs die 'geslaagd' melden terwijl de taak niet is gedaan, leest u in AI agent of automatisering: een groen vinkje betekent niet dat de taak is afgerond.

De derde melding leert nog iets: de test slaagde en de productie faalde. De preview draaide met het eigen account van de bouwer; echte gebruikers draaiden als iemand anders. Een test die niet draait zoals gebruikers werken, kan de fout missen.

Deze controles gelden voor elke tool waarmee een agent uit uw documenten antwoordt, ook de onze. Waar EpicStaff een antwoord heeft, staat dat onder de controle.

1. Bekijk de indexeringsstatus van elk document

Indexeren is de stap die een document opknipt in fragmenten (chunks), korte stukken tekst, en die opslaat zodat de zoekopdracht ze kan vinden. Een document dat in de map staat maar niet is geïndexeerd, hoort niet bij de kennis van de agent. Zoek het scherm dat de status van elk document toont. Kijk daar na elke upload, niet alleen op de eerste dag.

In EpicStaff: EpicStaff toont voor elk document een indexeringsstatus.

2. Weet hoe een mislukt document zichtbaar wordt, en wie het zou merken

Indexeren kan mislukken voor één document en lukken voor alle andere. Zoek uit hoe een mislukt document eruitziet in uw tool. Bepaal daarna wie kijkt, en hoe vaak. Een foutmarkering waar niemand naar kijkt, vertelt niemand iets.

In EpicStaff: Een mislukt document wordt gemarkeerd als mislukt (failed). Niets waarschuwt u; u moet zelf kijken.

3. Controleer of het runverslag toont wat de kenniszoekopdracht teruggaf

Ziet een antwoord er verkeerd uit, dan is de eerste vraag: wat gaf de zoekopdracht aan de agent? Toont het runverslag alleen de vraag en het antwoord, dan kunt u een slechte zoekopdracht niet onderscheiden van een slecht antwoord. Zoek naar de fragmenten die de zoekopdracht teruggaf, en uit welk bestand elk fragment kwam. Wat een runverslag verder moet bevatten, leest u in De AI agent is klaar. Niemand kan zeggen wat hij deed.

In EpicStaff: Voor de standaard kenniszoekopdracht (knowledge search) toont het runverslag de fragmenten die de zoekopdracht teruggaf, met hun tekst, bestandsnaam en score.

4. Weet wat de agent zegt als de zoekopdracht niets vindt

Een zoekopdracht kan niets opleveren. De vraag kan buiten de documenten vallen, of de index kan leeg zijn. Veel agents antwoorden dan vanuit de algemene training van het model, op dezelfde rustige toon. Schrijf instructies die de agent laten zeggen dat de documenten niets opleverden. Test die instructies daarna met een vraag die uw documenten niet kunnen beantwoorden.

In EpicStaff: Dat de zoekopdracht niets vond, ziet u alleen als u het runverslag opent. Het antwoord zelf ziet er normaal uit.

5. Weet of de agent draait als zijn kennisbank leeg is, nog wordt opgebouwd of is mislukt

Vraag naar drie toestanden: de kennisbank heeft geen documenten, hij is nog aan het indexeren, of het indexeren is mislukt. Weigert de agent in elke toestand, waarschuwt hij, of antwoordt hij zoals altijd? Probeer elke toestand uit op een testagent, zodat u het antwoord kent voordat een gebruiker erachter komt.

6. Weet wanneer elk document voor het laatst is geïndexeerd

Een synchronisatie die stopt, laat de index achter zoals hij op die dag was. De bron kan daarna veranderen, en de agent weet dat niet. Vergelijk voor een paar belangrijke documenten de datum waarop de bron voor het laatst veranderde met de datum waarop de index hem voor het laatst opnam. Kunt u die tweede datum niet zien, houd dan zelf bij wanneer u opnieuw indexeert.

7. Stel volgens een vast schema een vraag die alleen de kennisbank kan beantwoorden

Kies vijf vragen waarvan het antwoord alleen in uw documenten staat: een onderdeelnummer, een clausule, een getal uit een handleiding. Schrijf de juiste antwoorden op. Stel de agent die vragen elke week op een vaste dag, en vergelijk. Stel ze zoals uw gebruikers dat doen: via de gepubliceerde agent, met een gewoon gebruikersaccount, niet alleen in de preview van de builder. De derde melding hierboven laat zien waarom.

Mensen stellen een agent een vraag omdat ze het antwoord niet weten. Daarvoor is de agent er. Het betekent ook dat de gebruiker het minst goed kan zien dat een antwoord niet uit uw documenten kwam.

Deze controles kunt u dus niet aan gebruikers overlaten. Iemand die de documenten kent, moet ze in handen hebben: het statusscherm, de runverslagen en de wekelijkse vragen. Wijs die persoon aan voordat de volgende synchronisatie stopt.