Een AI-functie die in een PHP-applicatie is geïntegreerd, kan te lang duren, niet beschikbaar zijn of een resultaat opleveren dat niet bruikbaar is voor het proces. Het probleem los je niet op door elk antwoord als geldig te behandelen of het verzoek eindeloos te herhalen: beide keuzes kunnen de gebruikerservaring, gegevens en kosten in gevaar brengen. Een fallback voor AI-integratie in PHP bepaalt wat het systeem doet wanneer de afhankelijkheid uitvalt en welke bewerkingen niet mogen doorgaan zonder een aanvaardbaar antwoord.
Het juiste alternatief hangt af van de impact van de functie. Een tekstsuggestie kan tijdelijk achterwege blijven; een beslissing die invloed heeft op een betaling, een bevoegdheid of een gegevensupdate mag niet worden uitgevoerd op basis van onvolledige of veronderstelde informatie. Het doel is voorspelbaar gedrag, niet alle fouten verbergen.
Bepalen wat als een fout geldt
Specificeer voordat je alternatieven implementeert onder welke omstandigheden een antwoord onbruikbaar is. Door de gevallen van elkaar te onderscheiden, kun je gemakkelijker een beleid kiezen en meten of het werkt:
- Time-out: het verzoek overschrijdt de wachttijdlimiet van de applicatie.
- Onbeschikbaarheid of transportfout: de verbinding valt weg of de provider geeft een foutmelding.
- Leeg antwoord: de aanroep wordt voltooid, maar bevat niet de verwachte inhoud.
- Ongeldig formaat: het resultaat kan niet worden geparseerd of voldoet niet aan het vereiste schema, bijvoorbeeld JSON met ontbrekende velden.
- Onaanvaardbaar resultaat: de uitvoer is leesbaar, maar voldoet niet aan bedrijfsregels, validaties of beveiligingscriteria.
Een technisch correct antwoord is niet automatisch een geldige beslissing. Als de applicatie een categorie uit een vaste set verwacht, moet ze controleren of de waarde tot die set behoort. Als ze verplichte velden verwacht, moet ze die valideren voordat ze aan een ander component worden doorgegeven. Deterministische controles moeten in de PHP-code worden uitgevoerd; ze worden niet opnieuw aan hetzelfde model gedelegeerd.
De wachttijd en retries beperken
Stel een time-out in die past bij de bewerking en bij de totale tijd die de gebruiker of het proces kan wachten. Houd ook rekening met de limieten van de webserver, de queue en eventuele tussenliggende HTTP-clients: een lokale time-out die de limiet van het verzoek overschrijdt, biedt geen daadwerkelijke controle. Bij een achtergrondtaak kan een andere wachttijd acceptabel zijn, mits er expliciet beleid bestaat voor openstaande taken.
Retries moeten begrensd zijn en alleen worden toegepast op fouten die tijdelijk kunnen zijn. Een netwerkonderbreking kan een extra poging rechtvaardigen; een antwoord dat niet aan het schema voldoet, vraagt doorgaans om validatie, een fallback of beoordeling, niet om blind opnieuw proberen. Beperk het aantal pogingen en de totale tijd. Stel ook een maximum in als je een oplopende wachttijd gebruikt.
Houd er rekening mee dat een aanroep herhalen extra verbruik of bijwerkingen kan veroorzaken. Vermijd automatische retries zonder limiet en controleer of de bewerking idempotent is. Tekst genereren zonder bijwerkingen is niet hetzelfde als een actie die een bestelling aanmaakt of een melding verstuurt. Splits bij gevoelige bewerkingen het genereren van een voorstel af van de uitvoering ervan en stel voor die laatste eigen controles verplicht.
Een alternatief kiezen op basis van de impact
Een fallback is geen algemeen antwoord voor alle fouten. De fallback moet de bedrijfsregels intact laten en duidelijk maken wat de applicatie kan doen:
- Degraderen: als AI alleen extra gemak biedt, laat de gebruiker dan doorgaan zonder die functie. Toon bijvoorbeeld het standaardformulier wanneer er geen suggestie wordt gegenereerd.
- Uitstellen: als het resultaat later kan worden geproduceerd, sla de taak dan op met de status ‘in behandeling’ en bied de mogelijkheid om die via een queue opnieuw te proberen, met limieten en monitoring.
- Beoordeling aanvragen: als menselijk inzicht nodig is, toon dan een voorstel als concept of verwijs de zaak door naar een persoon. Presenteer niet-gevalideerde uitvoer niet als definitieve beslissing.
- Weigeren of stoppen: als een noodzakelijke voorwaarde om te handelen niet kan worden geverifieerd, blokkeer de actie dan en leg uit hoe de gebruiker verder kan gaan of hulp kan vragen.
De beslissing moet gebaseerd zijn op het risico van onjuist handelen, niet alleen op de kosten van een onderbreking. Een zoekfunctie met suggesties kan de oorspronkelijke zoekopdracht blijven gebruiken. Een workflow die klantgegevens wijzigt, mag daarentegen geen ontbrekende velden invullen op basis van aannames. Als AI-uitvoer invloed heeft op een bedrijfsbeslissing, behoud dan waar mogelijk een handmatige route of een deterministische regel.
De integriteit van processen beschermen
Behandel de modeluitvoer als externe invoer: parse de structuur, valideer elke waarde en beperk welke bewerkingen ermee kunnen worden gestart. Voeg de uitvoer niet rechtstreeks in SQL-query’s, opdrachten, HTML of instructies voor andere systemen in. Gebruik geparametriseerde query’s, passende encoding en allowlists, naast domeinspecifieke controles.
Maak een duidelijke scheiding tussen voorstellen en uitvoeren. AI kan bijvoorbeeld een classificatie voorstellen; de code controleert of die is toegestaan en het productbeleid bepaalt of deze automatisch wordt toegepast of in behandeling blijft. Als een vereist gegeven ontbreekt, is het doorgaans veiliger om ernaar te vragen, de zaak onvolledig te laten of het proces te stoppen dan het gegeven te verzinnen. Ook het gedrag bij fouten moet voldoen aan de gebruikelijke machtigingen, validaties en autorisatieregels.
Fouten loggen zonder onnodige informatie op te slaan
Logs moeten helpen bij de diagnose zonder een kopie van gesprekken te worden. Sla technische gebeurtenissen op, zoals de bewerking, het fouttype, de duur, het aantal pogingen, het validatieresultaat en een correlatie-ID. Voeg voldoende informatie toe om bijvoorbeeld een time-out van ongeldige JSON te onderscheiden, maar log standaard geen volledige prompts, antwoorden, inloggegevens of persoonsgegevens.
Als inhoud moet worden bewaard voor beoordeling of auditing, bepaal dan vooraf het doel, de toegang, de bewaartermijn en de beschermingsmaatregelen. Volg in je metrics de frequentie van time-outs, ongeldige antwoorden, fallbacks en openstaande taken, naast de latency en retries. Een stijging kan wijzen op een operationeel probleem of een verandering in het gedrag van de uitvoer. Metrics helpen trends te herkennen; ze vervangen de beoordeling van de afzonderlijke zaak niet en bewijzen op zichzelf niet dat een antwoord correct is.
Scenario’s testen en criteria afspreken
Test de integratie met gecontroleerde antwoorden en controleer zowel het zichtbare resultaat als de gevolgen voor het systeem. Neem hoge latency, verbindingsverlies, een leeg antwoord, een ongeldig formaat, gegevens die buiten de regels vallen en herstel na een fout mee. Controleer of acties niet dubbel worden uitgevoerd, retries binnen hun limieten blijven en logs geen gevoelige inhoud blootleggen. Test ook wat er gebeurt wanneer een taak in behandeling blijft of menselijke tussenkomst vereist.
Spreek vóór de ingebruikname van een functie de volgende beslissingen af met product en engineering:
- Is de functie essentieel om de bewerking te voltooien of verbetert ze alleen de gebruikerservaring?
- Welke totale wachttijd is per kanaal aanvaardbaar?
- Bij welke fouten mag opnieuw worden geprobeerd en hoeveel pogingen zijn toegestaan?
- Wat is het veilige alternatief: doorgaan zonder AI, uitstellen, menselijke beoordeling of stoppen?
- Welke validaties moeten slagen voordat het antwoord wordt gebruikt?
- Welke gegevens worden gelogd, wie heeft er toegang toe en hoe lang worden ze bewaard?
- Hoe wordt het team gewaarschuwd en wie handelt openstaande zaken af?
Een bruikbaar beleid maakt het mogelijk bijkomende functies te degraderen en bewerkingen te stoppen die afhankelijk zijn van niet-geverifieerde gegevens. Als niet precies kan worden uitgelegd wat er gebeurt bij een vertraagd, ongeldig of ontbrekend antwoord, heeft de integratie nog geen operationele fallback. Documenteer die regels bij de workflow en test ze opnieuw wanneer het product, de validaties of de manier waarop de service wordt gebruikt veranderen.
