STEP-KTODER: γιατί το AI πρέπει να μαθαίνει ποια συνάρτηση έκανε το λάθος

Ένα πρόγραμμα μπορεί να αποτυγχάνει επειδή μία μόνο συνάρτηση χειρίζεται λάθος ένα edge case. Αν όμως το εκπαιδευτικό σήμα χαρακτηρίζει ολόκληρη τη λύση «κακή», το μοντέλο τιμωρείται και για τα τμήματα που έγραψε σωστά. Η μελέτη Function-Level Execution Feedback for Code Preference Optimization προτείνει ακριβέστερη εποπτεία: κάθε module-level function αντιμετωπίζεται ως βήμα, ελέγχεται με στοχευμένα unit tests και συνδυάζεται με το αποτέλεσμα του πλήρους προγράμματος.

Το πλαίσιο ονομάζεται Step-KTOder και παρουσιάστηκε από ερευνητές των Seoul National University και Konkuk University. Η εργασία, που έγινε δεκτή στα Findings of EMNLP 2026, αξιολογεί τη μέθοδο σε HumanEval(+), MBPP(+), BigCodeBench και LiveCodeBench. Για ομάδες που χτίζουν coding copilots, agents ή εσωτερικά εργαλεία ανάπτυξης, το ουσιαστικό μήνυμα δεν είναι απλώς ότι ένα νέο objective ανέβασε ένα benchmark. Είναι ότι η αξία του feedback εξαρτάται από δύο επιλογές: σε ποιο επίπεδο δίνεται και αν μπορεί να επαληθευτεί με εκτέλεση.

Γιατί το τελικό pass ή fail είναι πολύ χοντρό σήμα

Οι συνηθισμένες μέθοδοι preference optimization αντιμετωπίζουν συχνά ολόκληρη την απάντηση ως μία μονάδα. Το Direct Preference Optimization, ή DPO, μαθαίνει από ζεύγη προτιμώμενων και μη προτιμώμενων outputs. Το Kahneman-Tversky Optimization, ή KTO, μπορεί να μάθει από μεμονωμένα outputs με δυαδικό desirable ή undesirable label. Όταν το output είναι κώδικας, αυτό το label προκύπτει συνήθως από το αν η πλήρης λύση πέρασε το διαθέσιμο test suite.

Η απλότητα έχει κόστος. Μια λύση με τέσσερις σωστές συναρτήσεις και μία λανθασμένη λαμβάνει το ίδιο αρνητικό outcome label με μια λύση που αποτυγχάνει παντού. Το feedback δεν αποκαλύπτει ποιο τμήμα πρέπει να διατηρηθεί και ποιο να διορθωθεί. Στα μαθηματικά, η process supervision μπορεί να ακολουθήσει τα ενδιάμεσα βήματα ενός συλλογισμού. Στον κώδικα δεν υπάρχει ένα καθολικά αποδεκτό «βήμα»: μπορεί να είναι γραμμή, block, κατάσταση εκτέλεσης, reasoning trace ή άλλο δομικό στοιχείο.

Οι συγγραφείς επιλέγουν τη συνάρτηση ως πρακτική μονάδα. Είναι σημασιολογικά ουσιαστική, έχει interface και μπορεί, τουλάχιστον σε αρκετές περιπτώσεις, να δοκιμαστεί ανεξάρτητα. Έτσι η εποπτεία δεν εξαρτάται μόνο από μια λεκτική κρίση για το αν ο κώδικας «φαίνεται σωστός», αλλά από παρατηρήσιμη συμπεριφορά.

Πώς κατασκευάζεται το Step-KTOder

Η διαδικασία έχει τέσσερα βασικά στάδια. Πρώτα, ένα ισχυρό instruction-tuned code model ξαναγράφει τη reference solution ως πρόγραμμα πολλών συναρτήσεων χωρίς να αλλάζει το εξωτερικό interface. Η αναδιατυπωμένη λύση διατηρείται μόνο αν εξακολουθεί να περνά το αρχικό test suite. Αυτό δημιουργεί έναν σκελετό όπου κάθε module-level function μπορεί να αντιμετωπιστεί ως ξεχωριστό step.

Δεύτερον, παράγονται στοχευμένα unit tests για κάθε συνάρτηση και για πιθανά edge cases. Δεν γίνονται δεκτά όλα τα παραγόμενα tests. Πρέπει να κάνουν parse, να εκτελούνται επιτυχώς πάνω στη reference implementation, να καλούν πραγματικά τη συνάρτηση-στόχο και να περιέχουν μη τετριμμένα assertions των οποίων το αποτέλεσμα εξαρτάται από το output της. Αν δεν υπάρχει έγκυρο τοπικό test, η συνάρτηση παίρνει null label και αποκλείεται από το step loss.

Τρίτον, το υπό εκπαίδευση μοντέλο συμπληρώνει on-policy τον σκελετό των συναρτήσεων. Η μελέτη παράγει οκτώ candidates ανά skeleton με θερμοκρασία 0,4 και top-p 0,95. Τέταρτον, κάθε υποψήφια λύση εκτελείται τόσο απέναντι στα τοπικά tests όσο και απέναντι στο test suite του dataset. Έτσι κάθε παράδειγμα αποκτά ένα global outcome label και μια ακολουθία από function-level labels.

Η τελική objective συνδυάζει outcome-level KTO με masked step-level KTO. Οι συναρτήσεις με αξιόπιστο label συμμετέχουν στο τοπικό loss, ενώ όσα παραδείγματα δεν έχουν αρκετά εποπτευόμενα steps επιστρέφουν σε outcome-only KTO. Η υλοποίηση απαιτεί τουλάχιστον δύο supervised functions για να ενεργοποιήσει το step loss, επειδή σε μία μόνο συνάρτηση το τοπικό σήμα είναι ουσιαστικά μια ανακλιμάκωση του συνολικού.

Όταν τοπική και συνολική ορθότητα συγκρούονται

Ένα από τα πιο ενδιαφέροντα ευρήματα είναι ότι δεν πρέπει να «καθαρίζονται» βιαστικά οι περιπτώσεις όπου τα labels διαφωνούν. Μια λύση μπορεί να περνά το συνολικό test suite αλλά μια επιμέρους συνάρτηση να αποτυγχάνει σε πιο στοχευμένα tests. Αυτό δεν είναι απαραίτητα θόρυβος. Μπορεί να σημαίνει ότι τα αρχικά tests δεν κάλυψαν το συγκεκριμένο edge case ή ότι το τελικό αποτέλεσμα πέτυχε παρά μια τοπική αδυναμία.

Στα datasets της μελέτης εμφανίστηκαν 1.194 τέτοιες συγκρούσεις για το Qwen2.5-Coder-1.5B, 1.397 για το Qwen2.5-Coder-3B και 1.428 για το DeepSeek-Coder-6.7B. Όταν οι ερευνητές διατήρησαν αυτά τα conflict labels, το Qwen 3B με Step-KTOder έφτασε 0,128 στο BigCodeBench Hard και 0,127 στο LiveCodeBench. Με masking των συγκρούσεων οι αντίστοιχες τιμές ήταν 0,115 και 0,119.

Για μια παραγωγική ομάδα, η ερμηνεία χρειάζεται προσοχή. Δεν σημαίνει ότι κάθε σύγκρουση μεταξύ tests είναι χρήσιμη ή ότι όλα τα test suites είναι σωστά. Δείχνει όμως ότι η διαφωνία ανάμεσα σε local και global checks είναι πληροφορία προς διερεύνηση. Αν εξαφανιστεί για να αποκτήσουμε ένα «καθαρό» label, μπορεί να χαθεί ακριβώς το σήμα που εντοπίζει κρυφές αστοχίες.

Τι έδειξαν τα benchmarks

Η μέθοδος δοκιμάστηκε σε τρεις code-specialized βάσεις: Qwen2.5-Coder-1.5B-Instruct, Qwen2.5-Coder-3B-Instruct και DeepSeek-Coder-6.7B-Instruct. Οι βελτιώσεις έναντι outcome-only KTO ήταν μικρές ή μηδενικές στα ευκολότερα HumanEval και MBPP, αλλά πιο εμφανείς στα δυσκολότερα BigCodeBench Hard και LiveCodeBench.

Για το Qwen 1.5B, το BigCodeBench Hard αυξήθηκε από 0,061 με KTO σε 0,068 με Step-KTOder, σχετική βελτίωση 11,5%, ενώ το LiveCodeBench ανέβηκε από 0,052 σε 0,056. Για το Qwen 3B, οι τιμές αυξήθηκαν από 0,115 σε 0,128 και από 0,116 σε 0,127 αντίστοιχα. Για το DeepSeek 6.7B, το BigCodeBench Hard μετακινήθηκε από 0,122 σε 0,128 και το LiveCodeBench από 0,127 σε 0,131.

Η εργασία αναφέρει επίσης ότι, σε σύγκριση με τα μη post-trained base models, το Step-KTOder βελτίωσε έως 26,7% το BigCodeBench Hard και έως 27,0% το LiveCodeBench. Αυτές οι τιμές δεν πρέπει να συγχέονται με τη σύγκριση έναντι KTO: μετρούν διαφορετικό baseline. Το ουσιαστικό pattern είναι ότι το λεπτομερέστερο execution-grounded feedback αποδίδει περισσότερο εκεί όπου το task είναι δυσκολότερο και η συνολική επιτυχία από μόνη της δίνει φτωχότερο σήμα.

Η επιφύλαξη είναι εξίσου σημαντική με το κέρδος. Τα αποτελέσματα είναι pass rates συγκεκριμένων μοντέλων και πρωτοκόλλων, όχι γενική πρόβλεψη για κάθε repository ή coding agent. Η μελέτη δείχνει πότε αξίζει να δοκιμαστεί η ιδέα, όχι ότι κάθε ομάδα θα δει τις ίδιες ποσοστιαίες αλλαγές.

Τα function labels εντοπίζουν τις βλάβες;

Οι συγγραφείς έκαναν μια στοχευμένη repair intervention. Σε λανθασμένες λύσεις αντικατέστησαν συναρτήσεις με τις σωστές reference implementations και μέτρησαν πόσο συχνά επισκευάζεται ολόκληρο το πρόγραμμα. Όταν αντικατέστησαν locally negative functions, η λύση διορθώθηκε στο 74,9% των περιπτώσεων. Με τυχαίες παρατηρημένες συναρτήσεις το repair rate ήταν 32,9%, ενώ με locally positive functions μόλις 1,2%.

Το πείραμα δεν αποδεικνύει ότι κάθε αρνητικό label απομονώνει τέλεια τη μοναδική αιτία. Δείχνει όμως ότι τα function-level tests συγκεντρώνουν το σήμα σε τμήματα που είναι πολύ πιο πιθανό να ευθύνονται για το συνολικό failure. Η πρόσθετη mutation-sensitivity ανάλυση ενισχύει αυτή την ανάγνωση: τα tests απέρριψαν 25.880 από 27.958 έγκυρα συντακτικά mutants, mutation kill rate 92,6%.

Γιατί η εκτέλεση ξεπέρασε τον LLM judge

Η μελέτη αντικατέστησε τα execution-based step labels με κρίσεις από GPT-5.4 mini. Η συνολική συμφωνία ήταν 73,2%, αλλά ο μέσος όρος έκρυβε έντονη ασυμμετρία: ο LLM judge συμφώνησε με την εκτέλεση στο 94,1% των failing functions, αλλά μόνο στο 52,2% των passing functions. Με άλλα λόγια, είχε τάση να προβλέπει περισσότερες αποτυχίες και να μετατρέπει καθαρά θετικά labels σε αρνητικά.

Το πρόβλημα δεν έμεινε στο annotation. Με execution labels, το Qwen 3B Step-KTOder πέτυχε 0,128 στο BigCodeBench Hard και 0,127 στο LiveCodeBench. Με LLM-as-a-judge labels οι τιμές έπεσαν σε 0,095 και 0,112, σχετική αλλαγή -25,8% και -11,8% έναντι της execution εκδοχής. Στο MBPP Plus υπήρξε μικρή άνοδος, από 0,630 σε 0,635, αλλά η συνολική εικόνα στα πιο απαιτητικά benchmarks επιδεινώθηκε.

Το συμπέρασμα δεν είναι ότι ένας LLM judge δεν έχει θέση σε code workflows. Μπορεί να βοηθήσει σε πρόθεση, αναγνωσιμότητα, τεκμηρίωση ή σε περιπτώσεις όπου δεν υπάρχει εκτελέσιμο oracle. Όταν όμως το ζητούμενο είναι συμπεριφορική ορθότητα και υπάρχουν αξιόπιστα tests, η εκτέλεση παρέχει ισχυρότερο ground truth. Η γλωσσική κρίση μπορεί να είναι συμπληρωματική, όχι αυτόματη αντικατάσταση.

Ποιότητα unit tests: το αθέατο θεμέλιο

Η επιτυχία του πλαισίου εξαρτάται από το αν τα unit tests είναι έγκυρα και διακριτικά. Στη διαδικασία της μελέτης, το 82,0% των testable functions από TACO και το 84,5% από APPS απέκτησαν τουλάχιστον ένα έγκυρο test. Ο μέσος αριθμός valid tests ανά καλυμμένη συνάρτηση ήταν 5,46 και 5,59 αντίστοιχα. Η μέση διαθεσιμότητα tests ανά πρόβλημα ήταν 83,4% για TACO και 85,4% για APPS.

Οι αριθμοί δείχνουν ότι η αυτοματοποίηση μπορεί να καλύψει μεγάλο μέρος του υλικού, όχι ότι εξαφανίζει την ανάγκη ελέγχου. Οι συγγραφείς φιλτράρουν tests που δεν κάνουν parse, δεν εκτελούνται, δεν καλούν τον στόχο ή περιέχουν τετριμμένα assertions. Επιπλέον, η εργασία αναγνωρίζει ρητά ότι τα παραγόμενα tests μπορεί να είναι ελλιπή. Μια λάθος συνάρτηση μπορεί να περάσει ένα αδύναμο local suite, ενώ μια σωστή υλοποίηση μπορεί να αποτύχει αν το test ενσωματώνει λανθασμένη υπόθεση.

Στην πράξη, το test-generation pipeline χρειάζεται δικά του metrics: reference pass, mutation sensitivity, πραγματική κλήση του στόχου, κάλυψη edge cases και ποσοστό συναρτήσεων χωρίς αξιόπιστο oracle. Το Step-KTOder εφαρμόζει reliability masking για steps χωρίς έγκυρο label, μια συνετή επιλογή που είναι προτιμότερη από το να βαφτιστεί η αβεβαιότητα ως αρνητικό παράδειγμα.

Τι σημαίνει για coding agents και production workflows

Η μελέτη αφορά offline preference optimization και όχι έτοιμο μηχανισμό παραγωγικής αξιολόγησης agents. Παρ’ όλα αυτά, προτείνει μια χρήσιμη αρχιτεκτονική αρχή: όταν ένα σύνθετο output μπορεί να αποσυντεθεί σε εκτελέσιμες μονάδες, το feedback πρέπει να διατηρεί αυτή τη δομή. Σε έναν coding agent, αντί να αποθηκεύεται μόνο το αν πέρασε το τελικό CI, μπορούν να καταγράφονται τα αποτελέσματα ανά function, module ή ανεξάρτητο contract.

Αυτό βελτιώνει την παρατηρησιμότητα. Μια ομάδα μπορεί να διακρίνει αν το μοντέλο αποτυγχάνει σε parsing, business rules, data transformations ή integration boundaries. Μπορεί επίσης να δημιουργήσει πιο χρήσιμα training examples, επειδή οι σωστές υπομονάδες δεν χρειάζεται να απορριφθούν μαζί με το λάθος σύνολο. Η ίδια ανάγκη για μετρήσιμη τεκμηρίωση εμφανίζεται όταν η documentation των AI agents μετατρέπεται από κενό γνώσης σε ελέγξιμο bug.

Υπάρχει και governance όφελος. Τα εκτελέσιμα checks αφήνουν audit trail: ποιο input χρησιμοποιήθηκε, ποιο assertion απέτυχε και ποια έκδοση του candidate αξιολογήθηκε. Αυτό δεν εγγυάται πλήρη ορθότητα, αλλά είναι πιο επιθεωρήσιμο από μια αδιαφανή βαθμολογία ενός δεύτερου LLM. Σε περιβάλλοντα με πολλούς agents, η ίδια αρχή συμπληρώνει την ανάγκη για συντονισμό των AI coding agents: το handoff πρέπει να μεταφέρει όχι μόνο αποτέλεσμα, αλλά και τεκμήρια ανά ελέγξιμη μονάδα.

Η πρακτική μεταφορά χρειάζεται να παραμείνει αναλογία σχεδιασμού. Η εργασία δεν μέτρησε production repositories, οργανωτικά workflows ή SLA. Μια ομάδα μπορεί όμως να χρησιμοποιήσει το ίδιο σχήμα για pilot: coarse outcome, local executable contracts, διατήρηση conflicts και ξεχωριστή μέτρηση label quality. Αυτό συνδέεται άμεσα με την προδιαγραφή ως λειτουργικό σύστημα της AI ανάπτυξης λογισμικού, επειδή τα contracts πρέπει να είναι αρκετά σαφή ώστε να γίνονται tests.

Τα όρια που δεν πρέπει να αγνοηθούν

Η εργασία αξιολογεί Python προβλήματα από TACO και APPS για την κατασκευή δεδομένων και συγκεκριμένα benchmark suites για την τελική μέτρηση. Οι ίδιοι οι συγγραφείς σημειώνουν περιορισμούς ως προς τα model families, τα datasets και την κατανομή δυσκολίας. Η pipeline κρατά προβλήματα με σαφές function-style entry point, με αποτέλεσμα τα τελικά training sets να γέρνουν προς ευκολότερα και πιο decomposition-friendly tasks.

Η επιλογή της συνάρτησης ως step λειτουργεί καλά όταν η λειτουργικότητα απομονώνεται. Δεν καλύπτει εξίσου εύκολα bugs που προκύπτουν μόνο από αλληλεπίδραση πολλών modules, concurrency, performance regressions, stateful services ή αλλαγές στο περιβάλλον. Εκεί χρειάζονται διαφορετικές μονάδες feedback, όπως API contracts, integration tests ή trace-level invariants.

Η παραγωγή decompositions και tests έχει επίσης κόστος. Για τη διαμόρφωση των δεδομένων του Qwen2.5-Coder-3B-Instruct, η μελέτη αναφέρει περίπου 78 GPU-hours: 24 για decomposition, 43 για generation των function-level tests και 11 για την παραγωγή οκτώ candidates. Οι decompositions και τα tests επαναχρησιμοποιούνται, αλλά μια επιχείρηση χρειάζεται δικό της υπολογισμό σε σχέση με τον όγκο, την κρισιμότητα των failures και την αξία του βελτιωμένου μοντέλου.

Τέλος, τα benchmark κέρδη δεν είναι ομοιόμορφα. Σε αρκετές στήλες η διαφορά από KTO είναι μηδενική ή μικρή. Το πλεονέκτημα συγκεντρώνεται κυρίως σε πιο δύσκολες αξιολογήσεις. Η ομάδα δεν πρέπει να υιοθετήσει περίπλοκο pipeline μόνο επειδή η ιδέα είναι ελκυστική, αλλά να ελέγξει αν τα δικά της failures είναι πράγματι τοπικά και αν το function-level signal αλλάζει τις πραγματικές μετρικές της.

Μια πρακτική διαδρομή εφαρμογής

Το πρώτο βήμα είναι να οριστεί η κατάλληλη μονάδα feedback. Σε ορισμένα repositories θα είναι η συνάρτηση, αλλού ένα API contract, ένα transformation stage ή ένα εργαλείο που καλεί ο agent. Η μονάδα πρέπει να είναι αρκετά αυτόνομη ώστε να ελεγχθεί, αλλά όχι τόσο μικρή ώστε το label να χάνει το νόημά του.

Έπειτα διαχωρίζονται το local και το global result, μαζί με τις συγκρούσεις τους. Πριν τα labels χρησιμοποιηθούν για training, μετριέται η αξιοπιστία των tests. Τέλος, γίνεται ελεγχόμενο πείραμα απέναντι σε outcome-only baseline, με έμφαση στα δύσκολα, αντιπροσωπευτικά tasks και όχι μόνο σε εύκολους μέσους όρους. Αν η ομάδα δουλεύει με αυτόνομους agents, οι ίδιοι έλεγχοι πρέπει να ενταχθούν σε ένα ασφαλές agentic AI workflow με περιορισμένα δικαιώματα και επαληθεύσιμα artifacts.

Τι κρατάμε από το Step-KTOder

Η πιο ώριμη ανάγνωση είναι ότι τα μοντέλα δεν χρειάζονται απλώς περισσότερο feedback· χρειάζονται feedback με σωστή ανάλυση και επαληθεύσιμη πηγή. Όταν ένα συνολικό failure ακυρώνει σωστά components ή όταν ένα συνολικό pass κρύβει αδυναμία σε edge case, η εκτέλεση ανά συνάρτηση αποκαθιστά μέρος της πληροφορίας που χάνεται.

Η συνάρτηση δεν είναι καθολική λύση για κάθε codebase. Είναι όμως ισχυρό παράδειγμα μιας γενικότερης αρχής: η μονάδα εποπτείας πρέπει να ευθυγραμμίζεται με τη μονάδα που μπορεί να αποτύχει και να ελεγχθεί. Για μια ομάδα software ή AI, αυτό σημαίνει σαφέστερα contracts, καλύτερα tests, διατήρηση των conflicts και metrics που ξεχωρίζουν την τοπική ορθότητα από το end-to-end αποτέλεσμα.

Το Step-KTOder δεν καταργεί το συνολικό test suite και δεν αντικαθιστά το human review. Συνδυάζει το coarse outcome με fine-grained execution evidence. Αυτή η ισορροπία είναι και το πιο χρήσιμο επιχειρησιακό του δίδαγμα: ο αυτοματισμός γίνεται πιο αξιόπιστος όταν η απόφαση μπορεί να εντοπιστεί, να αναπαραχθεί και να αμφισβητηθεί.