With over 20 years of experience, we transform your digital presence. We specialize in website and E-Shop development, SEO and Digital Marketing, ERP software and smart automation that take your business to the next level.
Στους GUI agents, η ποιότητα της διαδρομής αποκαλύπτει κόστος, επαναλήψεις και απόκλιση που κρύβει το τελικό αποτέλεσμα.
Answer first: η LACL-GUI δείχνει ότι για την εκπαίδευση GUI agents δεν αρκεί να γνωρίζουμε αν μια εργασία τελείωσε. Δύο επιτυχίες μπορεί να έχουν τεράστια διαφορά σε περιττά κλικ, latency και κόστος, ενώ δύο αποτυχίες μπορεί να απέχουν από τον στόχο κατά ένα βήμα ή κατά ολόκληρη τη διαδικασία.
Η μέθοδος προσθέτει δύο σήματα πάνω από το δυαδικό outcome: προτιμά τις πιο σύντομες επιτυχημένες διαδρομές της ίδιας εργασίας και διακρίνει τις αποτυχίες από το σημείο όπου αποκλίνουν από μια επιτυχημένη αναφορά. Για product teams, το χρήσιμο συμπέρασμα είναι σαφές: completion rate, ποιότητα διαδρομής και ασφάλεια επαλήθευσης πρέπει να μετρώνται χωριστά.
Οι GUI agents εκτελούν ακολουθίες ενεργειών σε web, desktop ή mobile περιβάλλοντα, συνδυάζοντας screenshots, πρόσφατο ιστορικό, reasoning και δομημένες ενέργειες. Σε πολλά συστήματα Reinforcement Learning with Verifiable Rewards, η ανταμοιβή δίνεται μόνο στο τέλος: 1 όταν η εργασία ολοκληρωθεί και 0 όταν αποτύχει. Κάθε βήμα της ίδιας διαδρομής κληρονομεί έτσι το ίδιο outcome.
Το σήμα είναι απλό και επαληθεύσιμο, αλλά συμπιέζει σημαντικές διαφορές. Ένας agent μπορεί να πετύχει με έξι ενέργειες και ένας δεύτερος με είκοσι επτά, έπειτα από επαναλήψεις και λανθασμένα κλικ. Αντίστοιχα, μία αποτυχία μπορεί να σταματήσει λίγο πριν από την επιβεβαίωση και μία άλλη να ανοίξει λάθος μενού από το πρώτο βήμα. Για μια επιχείρηση, αυτές οι διαδρομές δεν έχουν το ίδιο κόστος ούτε τον ίδιο κίνδυνο.
Η ανάγκη αυτή συμπληρώνει το behavioral testing για AI agents: το aggregate success rate δεν δείχνει ποιες συμπεριφορές παράγουν την επιτυχία, πόσο εύθραυστη είναι η πορεία ή πότε χρειάζεται ανθρώπινη παρέμβαση.
Outcome
Απαντά αν ο verifier επιβεβαίωσε το τελικό state. Είναι απαραίτητο, αλλά δεν εξηγεί πώς έφτασε εκεί ο GUI agent.
SuccessFailure
Μήκος διαδρομής
Συγκρίνει επιτυχίες του ίδιου task και εντοπίζει επαναλήψεις, άσκοπη εξερεύνηση και διορθώσεις μετά από λάθος.
CostLatency
Σημείο απόκλισης
Διαχωρίζει μια near-success αποτυχία από πορεία που έγινε λανθασμένη νωρίς και συνέχισε χωρίς ανάκαμψη.
DivergenceRecovery
Το όριο των GRPO και REAL
Η εργασία ξεκινά από γνωστές αδυναμίες του Group Relative Policy Optimization. Οι συγγραφείς συνοψίζουν δύο gradient pathologies: στις θετικές διαδρομές, tokens υψηλής πιθανότητας μπορεί να λαμβάνουν δυσανάλογα ισχυρές ενημερώσεις· στις αρνητικές, λίγα tokens υψηλής πιθανότητας μπορούν να κυριαρχούν στην ενημέρωση. Η κατανομή του gradient δεν ακολουθεί πάντα πιστά την ποιότητα ολόκληρης της trajectory.
Η μέθοδος REAL αντιμετωπίζει το RLVR ως πρόβλημα ταξινόμησης και προσφέρει πιο ελεγχόμενη, φραγμένη κατανομή gradient. Όμως το label μένει δυαδικό: όλες οι επιτυχίες μπαίνουν στη θετική ομάδα και όλες οι αποτυχίες στην αρνητική. Η LACL-GUI κρατά αυτό το βασικό όριο, αλλά προσθέτει σχετικές προτιμήσεις μέσα σε κάθε ομάδα.
Η διάκριση έχει σημασία για κάθε ομάδα που εξετάζει το sparse reward στην εκπαίδευση AI. Ένα επαληθεύσιμο τελικό score είναι χρήσιμο μόνο όταν το learning pipeline διατηρεί αρκετή πληροφορία για τις διαφορετικές ποιότητες των rollouts.
Πώς αξιολογούνται οι επιτυχημένες διαδρομές
Για τις επιτυχημένες trajectories, το πρόσθετο σήμα είναι το μήκος. Όταν πολλαπλές εκτελέσεις ξεκινούν από το ίδιο state και ολοκληρώνουν τον ίδιο στόχο, η συντομότερη θεωρείται προτιμότερη. Το σκεπτικό είναι ότι τα επιπλέον βήματα συχνά προέρχονται από εξερεύνηση χωρίς πρόοδο, επαναλαμβανόμενα κλικ ή λάθη από τα οποία ο agent ανέκαμψε.
Η μέθοδος εφαρμόζει μικρή, zero-mean μεταβολή στα logits της θετικής ομάδας. Οι σύντομες επιτυχίες αποκτούν σχετικά μεγαλύτερη βαρύτητα και οι μακρύτερες μικρότερη. Με stop-gradient στα ομαδικά στατιστικά, οι συγγραφείς αποδεικνύουν first-order invariance: η objective διατηρεί τη REAL μέχρι όρους δεύτερης τάξης ως προς τον συντελεστή perturbation.
Το «συντομότερο» δεν πρέπει να αποσυνδεθεί από την ορθότητα. Σε workflow που απαιτεί επιβεβαίωση αποθέματος, συγκατάθεση πελάτη ή έλεγχο πριν από δημοσίευση, η παράλειψη ενός βήματος δεν είναι efficiency. Είναι ελάττωμα. Η σύγκριση έχει νόημα μόνο ανάμεσα σε διαδρομές με ίδιο αρχικό state, ίδιο στόχο και επαληθευμένο outcome.
Τι σημαίνει «καλύτερη αποτυχία»
Για τις αποτυχημένες trajectories, το συνολικό μήκος δεν αρκεί. Μια σύντομη αποτυχία μπορεί απλώς να εγκατέλειψε από την αρχή. Η LACL-GUI συγκρίνει κάθε αποτυχία με τη συντομότερη διαθέσιμη επιτυχημένη διαδρομή της ίδιας εργασίας. Η αναφορά προέρχεται από τις τρέχουσες επιτυχίες ή από Success Buffer που αποθηκεύει προηγούμενες επιτυχημένες trajectories.
Η σύγκριση γίνεται βήμα προς βήμα στις οπτικές παρατηρήσεις με Structural Similarity Index. Το πρώτο σημείο όπου η ομοιότητα πέφτει κάτω από το κατώφλι ορίζει το divergence length. Στη συνέχεια υπολογίζονται τα βήματα που ακολούθησαν μετά την απόκλιση. Αποτυχίες που έμειναν κοντά στη σωστή πορεία τιμωρούνται ηπιότερα από εκτελέσεις που αποκλίνουν νωρίς και συνεχίζουν με πολλές άστοχες ενέργειες.
Αυτό δεν σημαίνει ότι η οπτική ομοιότητα αποδεικνύει σωστή πρόθεση. Δύο screenshots μπορεί να μοιάζουν ενώ το υποκείμενο state διαφέρει ή να διαφέρουν οπτικά χωρίς ουσιαστική αλλαγή στη δουλειά. Σε production χρειάζεται ο συνδυασμός visual trace, structured events και επαλήθευσης του πραγματικού state.
Η υποδομή πίσω από τη LACL-GUI
Η LACL-GUI συνοδεύεται από ασύγχρονη αρχιτεκτονική τεσσάρων μερών. Το Rollout Service συλλέγει trajectories παράλληλα από διαφορετικά GUI environments. Το Data Manager κρατά ομάδες που περιέχουν τόσο επιτυχίες όσο και αποτυχίες, επειδή ομάδες με ένα μόνο outcome δεν δίνουν contrastive supervision. Το Success Buffer αποθηκεύει επιτυχημένες αναφορές ανά task. Ο Trainer ενημερώνει την policy και συγχρονίζει περιοδικά τα νέα βάρη στους rollout workers.
Η ασύγχρονη συλλογή είναι κρίσιμη σε long-horizon αλληλεπιδράσεις, όπου οι πραγματικές UI ενέργειες είναι αργές και διαφορετικά tasks χρειάζονται άνισο χρόνο. Το buffer αντιμετωπίζει επίσης τα sparse rewards: όταν ένα τρέχον batch δεν έχει αρκετές επιτυχίες, υπάρχουν παλιότερες αναφορές για σύγκριση.
Η μελέτη δεν απομονώνει όμως το λειτουργικό κόστος αυτής της υποδομής σε παραγωγή. Εκτός από inference, μια επιχείρηση θα χρειαζόταν αποθήκευση trajectories, screenshots, versioned policies, verifier logs και πολιτική διατήρησης δεδομένων. Η μετάβαση από ένα AI agent demo στην παραγωγή κρίνεται συχνά ακριβώς σε αυτά τα operational στρώματα.
Τι έδειξαν οι 222 εργασίες του OSWorld
Η αξιολόγηση έγινε σε 222 από τις 369 εργασίες του αρχικού OSWorld. Αφαιρέθηκαν Chrome και multi-app tasks επειδή το συγκεκριμένο περιβάλλον Baidu RLE είχε ασταθές δίκτυο και ελλιπή εξωτερικά assets. Οι υπόλοιπες εργασίες κάλυψαν Gimp, LibreOffice Calc, Impress και Writer, λειτουργικό σύστημα, Thunderbird, VLC και VS Code.
Χρησιμοποιήθηκαν Qwen3-VL-Thinking μοντέλα 4B και 8B, έως 50 βήματα ανά trajectory, έξι tasks ανά iteration και οκτώ trajectories ανά task. Η εκπαίδευση έτρεξε σε οκτώ H100 για έως 50 iterations και αναφέρθηκε το καλύτερο checkpoint σύμφωνα με την αξιολόγηση κατά τη διάρκεια της εκπαίδευσης.
Τέσσερα τεκμηριωμένα μεγέθη της αξιολόγησης
Οι τιμές αφορούν το συγκεκριμένο φιλτραρισμένο OSWorld setup και τα κοινά outcomes των συγκρίσεων μήκους, όχι κάθε GUI agent ή κάθε παραγωγικό περιβάλλον.
222εργασίες σε οκτώ application domains μετά το φιλτράρισμα
50,0%overall success του LACL-GUI-8B στο εξεταζόμενο subset
8,19μέσα βήματα σε 70 tasks που πέτυχαν και οι τρεις μέθοδοι
26,72μέσα βήματα σε 93 tasks όπου και οι τρεις μέθοδοι απέτυχαν
Το LACL-GUI-8B κατέγραψε 50,0% συνολική επιτυχία, έναντι 47,2% για GRPO, 47,3% για REAL και 42,7% για το Qwen3-VL-8B-Thinking backbone. Στο 4B scale έφτασε 44,5%, έναντι 42,2% για GRPO και 43,0% για REAL. Πρόκειται για διαφορές 2,8 και 2,7 ποσοστιαίων μονάδων στο 8B όταν η σύγκριση μένει στο ίδιο backbone.
Το incremental ablation ανέβασε το 8B αποτέλεσμα από 42,7% σε 45,4% με decoupled architecture, 46,5% με Success Buffer, 47,2% με trajectory filter και 50,0% με την LACL-GUI objective. Άρα το τελικό κέρδος δεν αποδίδεται σε ένα μόνο στοιχείο· η objective προστέθηκε πάνω σε ήδη βελτιωμένη υποδομή.
Λιγότερα βήματα, αλλά όχι παντού
Για να μη συγχέεται η αποδοτικότητα με τη διαφορετική πιθανότητα επιτυχίας, οι συγγραφείς συνέκριναν μήκος μόνο εκεί όπου base model, REAL και LACL-GUI είχαν το ίδιο outcome. Σε 70 κοινές επιτυχίες, η LACL-GUI είχε 8,19 βήματα κατά μέσο όρο έναντι 9,13 της REAL, με μείωση 10,3%. Σε 93 κοινές αποτυχίες, οι αντίστοιχες τιμές ήταν 26,72 και 29,87 βήματα, με μείωση 10,5%.
Η εικόνα δεν ήταν ομοιόμορφη. Στις επιτυχίες, το Writer παρουσίασε μικρή αύξηση και το VLC μεγάλη αύξηση μήκους έναντι REAL. Στις αποτυχίες, Writer και VS Code είχαν επίσης μεγαλύτερες διαδρομές. Οι εξαιρέσεις εμποδίζουν μια υπερβολική υπόσχεση ότι κάθε εφαρμογή γίνεται συντομότερη.
Αυτός είναι και ο λόγος που ένα AI benchmark μπορεί να αλλάξει τον νικητή. Το τελικό score εξαρτάται από το subset, τον verifier, τα environment failures, το επιτρεπόμενο horizon και τον τρόπο επιλογής checkpoint.
Το παράδειγμα του Gimp κάνει τη διαφορά ορατή
Οι συγγραφείς αναλύουν task αλλαγής του theme του Gimp από dark σε light. Η LACL-GUI ολοκληρώνει την εργασία σε έξι βήματα: ανοίγει το Edit, μπαίνει στα Preferences, επιλέγει Theme, αλλάζει σε Light και επιβεβαιώνει. Μια επιτυχημένη REAL trajectory χρειάζεται 27 βήματα.
Η μακρύτερη εκτέλεση περιλαμβάνει επαναλαμβανόμενες ενέργειες χωρίς πρόοδο και, όταν αλλάζει το UI state, συνεχίζει να κάνει κλικ σε παλιά θέση. Και οι δύο trajectories παίρνουν reward 1, αλλά μόνο η πρώτη αποτελεί καθαρό πρότυπο efficiency.
Στις αποτυχίες, δύο trajectories αποκλίνουν στο ίδιο κρίσιμο σημείο. Η μία σταματά πρόωρα επειδή θεωρεί λανθασμένα ότι ολοκλήρωσε τη δουλειά· η άλλη συνεχίζει με άκαρπη εξερεύνηση. Το δυαδικό reward 0 δεν αποτυπώνει πόσο διαφορετική είναι η πιθανότητα ανάκαμψης, το κόστος και η αιτία του λάθους.
Από το paper σε production GUI agents
Η άμεση συνεισφορά της LACL-GUI αφορά training σε benchmark και όχι έτοιμη επιχειρηματική πλατφόρμα. Ωστόσο, η αρχή μεταφέρεται χρήσιμα σε agents που ενημερώνουν προϊόντα, εξάγουν reports, οργανώνουν καμπάνιες, χειρίζονται tickets ή συμπληρώνουν back-office συστήματα.
Η ομάδα χρειάζεται να καταγράφει όχι μόνο completion αλλά και βήματα, retries, επιστροφές σε προηγούμενη οθόνη, χρόνο ανά ενέργεια, πρώτη απόκλιση, recovery και τελική verification. Η ανάλυση για τους multimodal AI agents και το χάσμα ανάμεσα στην αντίληψη και τη σωστή δράση εξηγεί γιατί ένα μοντέλο μπορεί να «βλέπει» το interface χωρίς να ελέγχει αξιόπιστα την ακολουθία.
Δεν πρέπει να ανταμείβεται μηχανικά η συντομία. Ένας agent που παραλείπει preview, δεύτερο έλεγχο τιμής ή confirmation πριν από μαζική αλλαγή μπορεί να φαίνεται γρήγορος και να είναι επικίνδυνος. Η σωστή προτίμηση είναι η συντομότερη διαδρομή που ικανοποιεί όλα τα business και safety invariants.
Κανόνας απόφασης για GUI automation
Μην κάνετε rollout μόνο επειδή ανέβηκε το completion rate
Go σημαίνει επαληθευμένο τελικό state, αποδεκτό μήκος, χαμηλό retry rate, traceable divergence, ελεγχόμενο recovery, κόστος μέσα στο budget και σαφή human-handoff gates. No-go σημαίνει επιτυχία χωρίς audit trail, συντόμευση που παραλείπει έλεγχο ή benchmark που εξαιρεί ακριβώς τα production workflows.
Το ίδιο κριτήριο εμφανίζεται στο K-Bench για AI agents και πραγματικά artifacts: μια πειστική απάντηση ή ένα success flag δεν αποτελεί απόδειξη ότι παραδόθηκε σωστά ολόκληρη η εργασία.
Επτά έλεγχοι πριν από παραγωγικό rollout
Από το binary outcome σε ελεγχόμενη trajectory quality
Step 1Ορίστε το πραγματικό τελικό state
Χρησιμοποιήστε verifier που ελέγχει το αποτέλεσμα στο σύστημα και όχι μόνο το τελευταίο μήνυμα του GUI agent.
Step 2Καταγράψτε ολόκληρη τη διαδρομή
Κρατήστε versioned actions, observations, timestamps, policy έκδοση και tool responses με κανόνες ελαχιστοποίησης και διατήρησης δεδομένων.
Step 3Μετρήστε αναγκαία και περιττά βήματα
Ξεχωρίστε τα business-required checks από retries, loops, επιστροφές και κλικ που δεν αλλάζουν state.
Step 4Εντοπίστε την πρώτη ουσιαστική απόκλιση
Συνδυάστε visual similarity με structured state και event logs, ώστε ένα cosmetic UI change να μη θεωρείται αποτυχία και ένα κρυφό λάθος να μη διαφεύγει.
Step 5Ταξινομήστε recovery και stop behavior
Μετρήστε αν ο agent αναγνωρίζει το λάθος, αν επιστρέφει σε ασφαλές checkpoint ή αν συνεχίζει άσκοπα μέχρι το step limit.
Step 6Κάντε slice ανά εφαρμογή και workflow
Μην κρύβετε Writer, VLC, checkout ή CRM failures μέσα σε συνολικό μέσο όρο· κάθε domain χρειάζεται δικό του error budget.
Step 7Συνδέστε rollout gates με ανθρώπινη εποπτεία
Ορίστε πότε επιτρέπεται αυτόματη ολοκλήρωση, πότε απαιτείται confirmation και πότε η trajectory σταματά και παραδίδεται σε άνθρωπο.
Η διαδικασία πρέπει να επαναληφθεί σε production-like περιβάλλον και όχι μόνο στο lab harness. Για high-impact flows, κάθε policy ή UI αλλαγή χρειάζεται regression set που περιλαμβάνει κοντινές επιτυχίες, πρώιμες αποκλίσεις, loops και ασφαλή handoffs. Η NIST AI RMF οργάνωση σε Govern, Map, Measure και Manage είναι χρήσιμο πλαίσιο για να μη μείνει η τεχνική μέτρηση αποσυνδεδεμένη από ownership και risk response.
Όρια που δεν πρέπει να κρύβονται
Τα αποτελέσματα προέρχονται από φιλτραρισμένο υποσύνολο του OSWorld και συγκεκριμένο Baidu RLE environment. Η αφαίρεση Chrome και multi-app εργασιών μείωσε το evaluation noise, αλλά περιόρισε ακριβώς τα web και cross-application σενάρια που είναι συχνά κρίσιμα στην παραγωγή.
Η μελέτη αναφέρει το καλύτερο checkpoint σε έως 50 iterations. Αυτή η επιλογή μπορεί να δώσει πιο αισιόδοξη εικόνα από έναν fixed-checkpoint κανόνα ή ανεξάρτητο validation protocol. Επίσης, η divergence estimation εξαρτάται από SSIM και κατώφλι. Τα συνολικά success rates ήταν 49,5%, 50,0% και 49,9% για thresholds 0,80, 0,85 και 0,90, αλλά οι domain-level μεταβολές ήταν μεγαλύτερες.
Η συντομότερη επιτυχημένη reference δεν είναι αναγκαστικά η ασφαλέστερη, η πιο εξηγήσιμη ή η πιο συμμορφωμένη σε κάθε πραγματικό workflow. Το Success Buffer μπορεί επίσης να παλιώσει όταν αλλάξει το UI. Χρειάζονται reference freshness, invalidation rules και tests μετά από αλλαγές σε layout, δικαιώματα ή business policy.
Τέλος, τα αποτελέσματα δεν αποδεικνύουν ότι η LACL-GUI θα έχει το ίδιο uplift σε e-commerce, marketing ή customer support. Δείχνουν ότι το trajectory-level supervision αξίζει να εξεταστεί με αυστηρά ablations και production-specific verifiers.
Το σωστό συμπέρασμα
Η LACL-GUI αλλάζει το ερώτημα από «πέτυχε ή απέτυχε;» σε «πώς πέτυχε και πόσο κοντά έφτασε όταν απέτυχε;». Με length-aware προτίμηση στις επιτυχίες, divergence-aware αντιμετώπιση των αποτυχιών, Success Buffer και ασύγχρονη συλλογή trajectories, προσθέτει ποιότητα διαδικασίας πάνω από το δυαδικό αποτέλεσμα.
Στο συγκεκριμένο OSWorld subset, η μέθοδος βελτίωσε το overall success του 8B backbone και μείωσε το μέσο μήκος σε κοινά outcomes. Τα domain exceptions, το φιλτράρισμα του benchmark και η επιλογή καλύτερου checkpoint απαιτούν όμως προσεκτική ερμηνεία.
Για μια επιχείρηση, η πιο χρήσιμη πρακτική δεν είναι να αντιγράψει έναν ακαδημαϊκό loss. Είναι να κατασκευάσει αξιολόγηση που ξεχωρίζει outcome, efficiency, divergence, recovery και safety checks. Μόνο τότε η βελτίωση ενός GUI agent αντιστοιχεί σε πιο αξιόπιστη δουλειά και όχι απλώς σε καλύτερο score.
Από το demo σε ελεγχόμενο computer-use workflow
Σχεδιάστε GUI agents με verifiers, trajectory observability και ασφαλή handoffs
Η TWO DOTS χαρτογραφεί business invariants, state checks, retry budgets, failure slices, audit trails και rollout gates ώστε ο agent να ολοκληρώνει τη σωστή εργασία με διαδρομή που μπορείτε να ελέγξετε.
Είναι σύστημα AI που μετατρέπει μια οδηγία σε ακολουθία ενεργειών πάνω σε γραφικό περιβάλλον, χρησιμοποιώντας οπτικές παρατηρήσεις, ιστορικό και δομημένες εντολές όπως κλικ ή πληκτρολόγηση.
Τι προσθέτει η LACL-GUI στο δυαδικό reward;
Προσθέτει προτίμηση για πιο σύντομες επιτυχημένες διαδρομές και ηπιότερη αντιμετώπιση αποτυχιών που αποκλίνουν αργά από μια επιτυχημένη αναφορά, χωρίς να αλλάζει το βασικό όριο επιτυχίας και αποτυχίας.
Γιατί προτιμώνται οι σύντομες επιτυχημένες διαδρομές;
Μέσα στο ίδιο task, με ίδιο αρχικό state και ίδιο επιτυχημένο outcome, τα επιπλέον βήματα συχνά δείχνουν άσκοπη εξερεύνηση, επαναλήψεις ή λάθη με μεταγενέστερη ανάκαμψη. Δεν είναι καθολικός κανόνας για κάθε workflow.
Πώς μετριέται η απόκλιση μιας αποτυχημένης διαδρομής;
Οι διαδοχικές οπτικές παρατηρήσεις συγκρίνονται με τη συντομότερη διαθέσιμη επιτυχημένη αναφορά της ίδιας εργασίας μέσω SSIM και κατωφλίου ομοιότητας. Το πρώτο σημείο ουσιαστικής διαφοράς ορίζει το divergence length.
Ποιο ήταν το βασικό αποτέλεσμα στο OSWorld;
Στο φιλτραρισμένο σύνολο 222 εργασιών, το LACL-GUI-8B έφτασε 50,0% overall success, έναντι 47,2% για GRPO, 47,3% για REAL και 42,7% για το αντίστοιχο backbone.
Χρησιμοποιήθηκαν και οι 369 εργασίες του OSWorld;
Όχι. Οι ερευνητές χρησιμοποίησαν 222 εργασίες και αφαίρεσαν Chrome και multi-app tasks λόγω ασταθούς δικτύου και ελλιπών εξωτερικών assets στο δικό τους περιβάλλον.
Η LACL-GUI μειώνει πάντα τον αριθμό βημάτων;
Όχι. Οι συνολικοί μέσοι όροι μειώθηκαν στα κοινά outcomes, αλλά υπήρχαν εξαιρέσεις ανά εφαρμογή: Writer και VLC στις επιτυχίες, Writer και VS Code στις αποτυχίες.
What is the practical lesson for a business?;
Να μετρά χωριστά τελικό outcome, βήματα, επαναλήψεις, σημείο πρώτης απόκλισης, κόστος και επιτυχία της τελικής επαλήθευσης. Η συντομότερη διαδρομή δεν πρέπει να ανταμείβεται όταν παραλείπει αναγκαίο έλεγχο ή ανθρώπινο handoff.