Trust in LLM-Supported Engineering Work: The Role of Downstream Dependency
Deze kwalitatieve casestudy introduceert het concept van "downstream dependency" om uit te leggen hoe ingenieurs in de robotica-ontwikkeling door door de mens gegenereerde outputs niet beoordelen op basis van geïsoleerde kwaliteit, maar op basis van hun inspecteerbaarheid, controleerbaarheid en omkeerbaarheid binnen meerstaps-workflows, waardoor het vertrouwenonderzoek verschuift van outputverificatie naar sociaal-technisch beheer op workflowniveau.
Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer
In de moderne wereld van engineering vereist het bouwen van complexe machines, zoals robots, vaak enorme hoeveelheden trainingsdata. Het verzamelen van deze data uit de echte wereld kan traag, gevaarlijk of simpelweg te duur zijn. Om dit op te lossen, gebruiken ingenieurs "synthetische data", wat computergegenereerde informatie is die de werkelijkheid nabootst. Dit proces is niet één enkele stap, maar een lange, verbonden keten van taken. Een ingenieur kan een scenario definiëren, digitale objecten creëren, configureren hoe die objecten worden gegenereerd, de resultaten controleren en tot slot de data voorbereiden waar een robot van kan leren. Als er vroeg in deze keten een fout optreedt, kan dit doorwerken in elke daaropvolgende stap en het eindproduct ruïneren.
Onlangs zijn ingenieurs begonnen met het gebruik van large language models — krachtige computerprogramma's die tekst en code kunnen genereren — om delen van deze keten te versnellen. Deze tools kunnen beschrijvingen opstellen, code schrijven voor digitale objecten of suggesties geven over hoe verschillende onderdelen van het systeem met elkaar verbonden moeten worden. Er blijft echter een cruciale vraag bestaan: wanneer een ingenieur een dergelijke tool gebruikt, hoe beslist hij dan of hij het resultaat kan vertrouwen? Het is niet genoeg om te weten of het antwoord er nú goed uitziet. De ingenieur moet ook weten of dat antwoord de rest van de reis zal overleven. Als een computer een digitaal object genereert dat er vandaag correct uitziet maar een verborgen fout bevat, kan die fout ervoor zorgen dat de robot maanden later tijdens de training faalt. Dit artikel onderzoekt hoe professionele ingenieurs met deze onzekerheid omgaan, waarbij ze verder gaan dan simpel vertrouwen in een tool naar een meer zorgvuldige beoordeling van hoe de output van die tool zich zal gedragen terwijl deze door een complexe workflow beweegt.
De onderzoekers bestudeerden vier ingenieurs die werkzaam waren bij een klein engineeringbedrijf dat synthetische datapiplines voor robotica bouwt. Ze vroegen deze ingenieurs niet alleen wat ze van kunstmatige intelligentie vonden; ze keken hen aan het werk. Het team nam de ingenieurs op terwijl zij een reeks van vijftien verbonden taken uitvoerden, van het opzetten van een project tot het genereren en controleren van data. Twee van deze taken hielden het gebruik van het taalmodel in om digitale assets te creëren of onderdelen van het systeem te bous, terwijl de andere dertien taken de omringende context boden. De onderzoekers interviewden de ingenieurs ook en vroegen hen om hardop te denken terwijl ze werkten, waarbij ze uitlegden wat ze opmerkten, wat ze controleerden en waarom ze bepaalde beslissingen namen.
De studie toonde aan dat ingenieurs de output van de computer niet simpelweg als "betrouwbaar" of "onbetrouwbaar" beschouwen. In plaats daarvan is hun vertrouwen voorwaardelijk en verandert het afhankelijk van waar ze zich in de workflow bevinden en wat er vervolgens kan gebeuren. De onderzoekers identificeerden een kernconcept dat ze "downstream dependency" (stroomafwaartse afhankelijkheid) noemen. Dit beschrijft de relatie tussen een stuk werk dat de computer nu genereert en het toekomstige werk dat het zal moeten gebruiken. Een ingenieur kan er tevreden mee zijn om een door de computer gegenereerd idee te accepteren als het slechts een ruwe schets is voor een plan. Maar als datzelfde idee een permanent onderdeel gaat worden van de data die een robot traint, wordt de ingenieur veel voorzichtiger. Ze vrezen dat een kleine fout nu kan verspreiden en grote problemen later kan veroorzaken, zoals het corrumperen van de gehele dataset of het onveilig maken van de robot.
Vanwege deze angst voor toekomstige problemen ontwikkelden de ingenieurs specifieke manieren om hun afhankelijkheid van de computer te beheersen. Eén methode is "stage-dependent verification" (faseafhankelijke verificatie). Dit betekent dat de manier waarop ze het werk van de computer controleren, verandert afhankelijk van de taak. Wanneer de computer een lijst met getallen of instellingen suggereert, controleert de ingenieur elk getal afzonderlijk, zoals bij het doorlopen van een checklist. Maar wanneer de computer een complexe structuur of een nieuw module voor het systeem suggereert, vraagt de ingenieur om een overzichtelijke uitleg van hoe het in elkaar past voordat hij het accepteert. Ze controleren niet alleen of het antwoord juist is; ze controleren of het antwoord zinvol is in de context van het hele systeem.
De tweede methode is "scoped control" (gecontroleerde reikwijdte). Ingenieurs willen precies weten wat de computer mag veranderen en wat niet. Ze raken angstig als de computer één probleem oplost, maar onbedoeld iets anders in de buurt verandert dat wel gewoon werkte. In één geobserveerd geval vroeg een ingenieur de computer om een specifiek digitaal object te maken, maar het systeem veranderde ook een instelling voor de gehele scène. De ingenieur stopte onmiddellijk, inspecteerde de wijziging en herstelde deze voordat hij verderging. Ze moeten in staat zijn om elke wijziging die de computer maakt te zien, die wijzigingen binnen een duidelijke grens te houden en ze ongedaan te kunnen maken indien nodig. Als de computer zaken onverwacht verandert of als het resultaat er telkens anders uitziet wanneer ze om een correctie vragen, daalt het vertrouwen van de ingenieur en stoppen ze met het vertrouwen op de tool.
De studie suggereert dat voor kunstmatige intelligentie om echt nuttig te zijn in engineering, het niet alleen ontworpen kan worden om snelle, plausibele antwoorden te produceren. Het moet ook zo ontworpen worden dat het controleerbaar en beheersbaar is. De computer moet zijn werk in stappen laten zien, uitleggen waarom het bepaalde verbindingen heeft gemaakt, en duidelijk de grenzen aangeven van wat het verandert. Het moet de ingenieur in staat stellen om te zien hoe een beslissing van vandaag invloed kan hebben op het werk van morgen. Vertrouwen, concluderen de onderzoekers, is geen gevoel dat een ingenieur voor een machine heeft. Het is een praktische beoordeling die op het moment zelf wordt gemaakt, gebaseerd op de vraag of de ingenieur het werk kan verifiëren, de wijzigingen kan controleren en er zeker van kan zijn dat de output geen problemen zal veroorzaken verderop in de lijn. Het doel is niet om de ingenieur blindelings op de machine te laten vertrouwen, maar om hen de middelen te geven om er veilig op te kunnen rekenen, wetende waar precies de risico's liggen en hoe ze die kunnen beheren.
Verdrinkt u in papers in uw vakgebied?
Ontvang dagelijkse digests van de nieuwste papers die bij uw onderzoekswoorden passen — met technische samenvattingen, in uw taal.