Με πάνω από 20 χρόνια εμπειρίας, μεταμορφώνουμε την ψηφιακή σας παρουσία. Εξειδικευόμαστε στην κατασκευή ιστοσελίδων και E-Shop, το SEO και το Digital Marketing, τα ERP λογισμικά και τους έξυπνους αυτοματισμούς που απογειώνουν την επιχείρησή σας.
Διεύθυνση:
Εγνατία 154, Θεσσαλονίκη 546 36
Τηλέφωνο:
+30 231 231 4095
E-mail:
hello@twodots.gr
Έτοιμοι για το επόμενο βήμα;
Το reformalization του Jordan Curve Theorem δείχνει πώς πηγές αλήθειας, validators, bookkeeping και ανθρώπινος έλεγχος κάνουν τα AI workflows αξιόπιστα.
Το reformalization του Jordan Curve Theorem δείχνει ότι ένα AI workflow γίνεται αξιόπιστο όταν δεν αυτοαξιολογείται. Χρειάζεται ελεγχόμενη πηγή αλήθειας, μικρά επαληθεύσιμα βήματα, αυστηρή καταγραφή προόδου, γρήγορο feedback από εργαλεία και άνθρωπο που παρεμβαίνει στα όρια του συστήματος. Αυτή η αρχιτεκτονική αφορά άμεσα migrations, knowledge bases, e-commerce δεδομένα, περιεχόμενο και επιχειρησιακούς αυτοματισμούς.
Η εργασία «Reformalization of the Jordan Curve Theorem» εξετάζει αν agentic pipelines με μεγάλα γλωσσικά μοντέλα μπορούν να μεταφέρουν μια μεγάλη, ήδη τυπικά ελεγμένη μαθηματική ανάπτυξη από ένα proof assistant σε άλλο. Οι ερευνητές μελέτησαν τρεις διαδρομές: Mizar προς Lean, HOL Light προς Lean και HOL Light προς Agda. Το ζητούμενο δεν ήταν να παραχθεί μια πειστική εξήγηση, αλλά κώδικας απόδειξης που ο target proof assistant μπορεί να ελέγξει ανεξάρτητα.
Για μια επιχείρηση, η αξία βρίσκεται στο operating model. Ένα AI σύστημα δεν παίρνει απλώς ένα μεγάλο prompt και παραδίδει τελικό αποτέλεσμα. Διαβάζει συγκεκριμένη πηγή, διασπά την εργασία, χρησιμοποιεί τις δυνατότητες του συστήματος-στόχου, τρέχει validators, καταγράφει τι ολοκληρώθηκε και επιστρέφει στο τελευταίο έγκυρο σημείο όταν κάτι αποτυγχάνει. Αυτό είναι το ίδιο μοτίβο που χρειάζονται οι Αυτοματισμοί Επιχειρήσεων & AI όταν επηρεάζουν πραγματικά δεδομένα, πελάτες ή αποφάσεις.
Η βασική διάκριση είναι ανάμεσα στην ευχέρεια και στην αξιοπιστία. Ένα μοντέλο μπορεί να παράγει καλογραμμένο περιεχόμενο, κώδικα ή προτάσεις χωρίς να γνωρίζει αν το αποτέλεσμα πληροί τις απαιτήσεις. Στο reformalization, το τελικό «ναι» το δίνει ο proof checker. Σε ένα business workflow, το αντίστοιχο «ναι» πρέπει να προέρχεται από tests, κανόνες δεδομένων, reconciliation, preview, approval ή άλλη εξωτερική απόδειξη.
Στο autoformalization, το σύστημα ξεκινά από φυσική γλώσσα, όπως ένα βιβλίο ή ένα paper, και επιχειρεί να τη μετατρέψει σε τυπική απόδειξη. Η φυσική γλώσσα μπορεί να περιέχει άρρητες παραδοχές, συντομεύσεις ή κενά. Στο reformalization, η αφετηρία είναι μια πλήρης formal development σε άλλο proof assistant. Η πηγή λειτουργεί ως ακριβής προδιαγραφή του θεωρήματος και ως λεπτομερής, ήδη ελεγμένη απόδειξη.
Ο στόχος δεν είναι αντιγραφή χαμηλού επιπέδου σύνταξης. Είναι μια νέα ανάπτυξη που παραμένει πιστή στο μαθηματικό περιεχόμενο, αλλά χρησιμοποιεί φυσικά τη βιβλιοθήκη, τους τύπους και τα εργαλεία του target ecosystem. Αυτή η απαίτηση ονομάζεται library alignment και έχει άμεσο επιχειρησιακό ανάλογο: ένα migration πρέπει να διατηρεί τις δεσμεύσεις της πηγής χωρίς να κουβαλά άσκοπα το legacy μοντέλο στο νέο σύστημα.
One-shot μετατροπή ή ελεγχόμενο reformalization;
Το μοντέλο λαμβάνει ασαφή πρόθεση, παράγει ολόκληρο το αποτέλεσμα και συχνά κρύβει τις παραδοχές του. Η ομάδα βλέπει το τελικό output, αλλά δυσκολεύεται να εντοπίσει πού χάθηκε μια απαίτηση.
Το workflow ξεκινά από έγκυρη πηγή, αντιστοιχίζει έννοιες στο σύστημα-στόχο, προχωρά σε μικρά βήματα και ζητά εξωτερική επαλήθευση πριν ενημερώσει την κατάσταση.
Το Jordan Curve Theorem δηλώνει, σε απλή μορφή, ότι κάθε απλή κλειστή καμπύλη στο επίπεδο το χωρίζει σε δύο ξένες περιοχές: ένα φραγμένο εσωτερικό και ένα μη φραγμένο εξωτερικό. Η εικόνα μοιάζει αυτονόητη, όμως οι τυπικές αποδείξεις είναι μεγάλες και τεχνικά ετερογενείς. Συνδυάζουν τοπολογία, γεωμετρία, αναλυτικά λήμματα και επιχειρήματα γράφων, άρα μια μικρή παράλειψη μπορεί να εμφανιστεί ως blocker πολύ αργότερα.
Αυτό το καθιστά χρήσιμο stress test για agentic work. Υπάρχει έγκυρη πηγή, καθαρός τελικός στόχος και πολλά εξαρτώμενα βήματα. Το αποτέλεσμα δεν μπορεί να «περάσει» επειδή ακούγεται εύλογο. Πρέπει να κάνει compile χωρίς placeholders ή πρόσθετα αξιώματα και να αποδεικνύει τη σωστή δήλωση. Οι συγγραφείς επισημαίνουν επίσης ότι οι μετρήσεις γραμμών, χρόνου ή κόστους είναι περιγραφικό πλαίσιο, όχι οριστικό benchmark απόδοσης.
Το επιχειρησιακό ανάλογο είναι μια σύνθετη μεταφορά προϊόντων, περιεχομένου ή γνώσης. Ένα e-shop migration μπορεί να περιλαμβάνει SKU, κατηγορίες, αποθέματα, τιμές, redirects, SEO metadata, feeds και κανόνες επιστροφών. Αν ένα στοιχείο παραλειφθεί σιωπηρά, το πρόβλημα ίσως φανεί μετά το launch. Για αυτό η επιτυχία δεν μετριέται μόνο με το αν «μεταφέρθηκαν τα περισσότερα», αλλά με το αν κάθε κρίσιμη δέσμευση έχει status και validator.
Η διαδρομή Mizar προς Lean οργανώθηκε σε τρία στάδια. Πρώτα εξήχθησαν dependency graphs και metadata από τα ενδιάμεσα αρχεία του Mizar proof checker. Έπειτα ο agent δημιούργησε Lean skeletons και αντιστοίχισε τα στοιχεία της Mizar Mathematical Library με κοντινά θεωρήματα της Mathlib. Τέλος, συμπλήρωσε τις αποδείξεις χρησιμοποιώντας τη Mizar πηγή ως proof sketch και τη Mathlib ως την εγγενή βιβλιοθήκη του στόχου.
Η τελική Lean ανάπτυξη περιείχε 413 λήμματα και θεωρήματα, περίπου 11.000 γραμμές, και έκανε build σε 111 δευτερόλεπτα με cached Mathlib. Η μείωση σε σχέση με τις περίπου 23.500 γραμμές του σχετικού Mizar source αποδίδεται κυρίως στην επαναχρησιμοποίηση κοντινών αποτελεσμάτων που υπήρχαν ήδη στη Mathlib. Πρόκειται για περιγραφικά στοιχεία μιας συγκεκριμένης μεταφοράς, όχι για υπόσχεση ότι κάθε AI migration θα έχει την ίδια οικονομία.
Η διαδρομή Mizar προς Lean σε τέσσερα τεκμηριωμένα στοιχεία
Οι αριθμοί προέρχονται από το paper και περιγράφουν το συγκεκριμένο formalization· δεν είναι γενικός δείκτης παραγωγικότητας AI.
Η πρακτική αξία είναι το library alignment. Σε ένα CRM migration, ο στόχος δεν είναι να δημιουργηθούν ξανά legacy custom fields όταν υπάρχουν κατάλληλα native objects. Σε ένα content migration, δεν αρκεί να μετακινηθεί άμορφο κείμενο· χρειάζονται σωστή σημασιολογική HTML, metadata και schema. Σε ένα knowledge workflow, η αξία αυξάνεται όταν το σύστημα ανακτά εγκεκριμένες πηγές, όπως συμβαίνει σε ένα private chatbot με RAG, αντί να αυτοσχεδιάζει από γενική μνήμη.
Στη μεταφορά HOL Light προς Lean, η στρατηγική ήταν γραμμική. Η απόδειξη χωρίστηκε σε 30 sections και ο agent δούλευε section by section, theorem by theorem. Για κάθε section ενημέρωνε κατάλογο ορισμών και θεωρημάτων, δημιουργούσε Lean skeletons με προσωρινά sorry, συμπλήρωνε κάθε proof με τη σειρά, έκανε build μετά από κάθε βήμα και ενημέρωνε CSV και status document μόνο όταν το αρχείο ήταν καθαρό.
Κάθε στοιχείο έπρεπε να ταξινομηθεί: υπάρχει ήδη στη Mathlib, δεν εφαρμόζεται στο Lean επειδή καλύπτεται από το type checking ή πρέπει να υλοποιηθεί. Όταν οι αρχικές οδηγίες άφηναν μεγαλύτερη ελευθερία, ο agent παρέλειπε μερικές φορές ένα φαινομενικά απλό theorem. Αργότερα μπλόκαρε επειδή έλειπε το lemma ή η διαθέσιμη δήλωση ήταν ασθενέστερη από την πηγή. Η αυστηρή καταγραφή δεν ήταν γραφειοκρατία· ήταν μηχανισμός συνέχειας.
Το τελικό Lean formalization είχε περίπου 29.000 γραμμές, περισσότερα από 910 θεωρήματα και λήμματα, 150 definitions και χρόνο build 206 δευτερολέπτων. Από τα source statements, 258 υπήρχαν ήδη στη Mathlib και 213 χαρακτηρίστηκαν μη εφαρμόσιμα στο Lean. Το σημαντικό μάθημα δεν είναι το μέγεθος. Είναι ότι η πρόοδος έγινε ορατή και ελέγξιμη σε επίπεδο μονάδας εργασίας.
Η διαδρομή προς Agda δεν ολοκληρώθηκε στο paper. Είχαν μεταφερθεί το Section 0, τα Sections A έως D και περίπου το μισό Section E, συνολικά περίπου 27.000 γραμμές Agda. Επειδή το κύριο θεώρημα δεν είχε ακόμη μεταφερθεί, οι συγγραφείς δεν ισχυρίζονται ότι η reformalization ήταν επιτυχής. Αυτή η σαφής διάκριση ανάμεσα σε πρόοδο και ολοκλήρωση είναι από μόνη της χρήσιμο πρότυπο reporting.
Το type checking ξεπέρασε τα 32GB μνήμης του Docker container. Ο agent αρχικά εξέλαβε την απουσία απάντησης ως επιτυχία, ενώ η διεργασία είχε τερματιστεί από το λειτουργικό σύστημα λόγω έλλειψης μνήμης. Η ομάδα χρειάστηκε να αναγνωρίσει ρητά το failure mode, να χωρίσει τα proofs σε μικρότερα chunks και να επιβάλει cached interfaces ώστε να μειωθεί ο χρόνος επαλήθευσης.
Το ίδιο συμβαίνει σε πραγματικές integrations. Ένα request που δεν επέστρεψε error δεν σημαίνει ότι γράφτηκε στο ERP. Ένα CMS job που σταμάτησε να δίνει output δεν σημαίνει ότι δημοσίευσε. Ένα feed που ανέβηκε δεν σημαίνει ότι εγκρίθηκε. Το workflow πρέπει να διακρίνει success, timeout, retryable failure, resource exhaustion και άγνωστη κατάσταση, με τρόπο που μπορεί να καταλάβει και ο agent και ο άνθρωπος.
Στο paper, το LLM προτείνει και διορθώνει, αλλά ο target proof checker παραμένει ο τελικός κριτής. Η reformalization θεωρείται verified success μόνο όταν το αποτέλεσμα ελέγχεται πλήρως, δεν περιέχει sorry placeholders ή πρόσθετα αξιώματα και αποδεικνύει τη σωστή τελική δήλωση. Η ευφράδεια του μοντέλου δεν αποτελεί κριτήριο ορθότητας.
Σε ένα e-commerce workflow, οι validators μπορεί να ελέγχουν μοναδικό SKU, αριθμητική τιμή, διαθεσιμότητα έναντι ERP, έγκυρο GTIN, canonical URL και αποδοχή από το product feed. Στο content, μπορεί να ελέγχουν HTML, schema, πηγές, duplicate blocks, links και οπτικό rendering. Σε customer support, μπορεί να απαιτούν ανάκτηση εγκεκριμένης πολιτικής και ανθρώπινο approval πριν από επιστροφή χρημάτων ή δέσμευση προς πελάτη.
Το NIST AI Risk Management Framework κινείται στην ίδια κατεύθυνση: ορίζει ότι οι ρόλοι ανθρώπινης εποπτείας πρέπει να είναι σαφείς και ότι η αξιολόγηση χρειάζεται αντικειμενικές, επαναλήψιμες διαδικασίες testing, evaluation, verification και validation. Η καταλληλότητα των μετρικών εξαρτάται από το πραγματικό context χρήσης. Ένα workflow δεν είναι αξιόπιστο επειδή πέρασε ένα demo test, αλλά επειδή δοκιμάζεται σε συνθήκες κοντά στην παραγωγή και μπορεί να αποτύχει με ασφαλή τρόπο.
Στη Mizar προς Lean διαδρομή, ο agent απομακρύνθηκε περίπου δέκα φορές από τη διαθέσιμη πηγή και προσπάθησε να σχεδιάσει proof sketch από την αρχή, ιδιαίτερα μετά από context-window summarization. Η ανθρώπινη παρέμβαση δεν πρόσθεσε μαθηματική γνώση. Επανέφερε τον agent στη διαδικασία: χρησιμοποίησε την πηγή, ακολούθησε την υπάρχουσα στρατηγική και μη δημιουργείς νέα διαδρομή χωρίς λόγο.
Σε ένα brand migration, η ίδια απόκλιση μπορεί να αλλάξει approved positioning. Σε product data, μπορεί να συμπληρώσει κενά με πιθανές αλλά μη επαληθευμένες ιδιότητες. Σε ένα help center, μπορεί να παραλείψει εξαίρεση που προστατεύει πελάτη και εταιρεία. Η σωστή σημασιολογική αναζήτηση βοηθά να βρεθεί η πηγή, αλλά το workflow πρέπει επίσης να επιβάλει ότι η απάντηση παραμένει μέσα στις δεσμεύσεις της.
Κανόνας σχεδιασμού
Δώστε δημιουργική ελευθερία μόνο στα σημεία όπου η απόκλιση είναι αναστρέψιμη και ελέγξιμη.Κρατήστε αυστηρούς validators για γεγονότα, οικονομικά δεδομένα, δικαιώματα, νομικές δεσμεύσεις, URLs και system state. Επιτρέψτε περισσότερη ελευθερία στο ύφος ή στην παρουσίαση μόνο αφού έχουν κλειδώσει οι κρίσιμες απαιτήσεις.
Αυτό δεν σημαίνει ότι οι agents πρέπει να εκτελούν τυφλά κάθε βήμα. Σημαίνει ότι οι αποκλίσεις γίνονται ορατές, αιτιολογούνται και εγκρίνονται. Η διάκριση ανάμεσα σε απλή παραγωγή και πιο αυτόνομη ροή εξηγείται και στη σύγκριση γενετικής και agentic AI. Όσο αυξάνεται η αυτονομία, τόσο περισσότερο χρειάζονται state, permissions, tests και recovery paths.
Η μελέτη δεν προσφέρει έτοιμη συνταγή για κάθε εταιρεία, αλλά δίνει ένα ισχυρό pattern: source-aware decomposition, εξωτερική επαλήθευση, μηχανικό bookkeeping, γρήγορο feedback και στοχευμένη ανθρώπινη εποπτεία. Η εφαρμογή μπορεί να ξεκινήσει από μία συχνή εργασία με σαφές input, ελέγξιμο output και γνωστό κόστος λάθους. Ένας πρακτικός οδηγός για το πρώτο use case βρίσκεται και στο άρθρο για το πώς αυτοματοποιούνται εργασίες με τεχνητή νοημοσύνη.
Από την πηγή αλήθειας σε ελεγχόμενη παραγωγή
Περιγράψτε το output, τις κρίσιμες δεσμεύσεις και ποιος validator ή υπεύθυνος έχει δικαίωμα να πει «ολοκληρώθηκε». Χωρίστε τα hard failures από τις διαγνωστικές προειδοποιήσεις.
Καταγράψτε ποια έγγραφα, APIs, πίνακες ή πολιτικές είναι authoritative, ποιος τα ενημερώνει και πώς εντοπίζεται η έκδοσή τους. Μην αφήνετε το μοντέλο να συμπληρώνει σιωπηρά όσα λείπουν.
Ελέγξτε ποια πεδία, objects, taxonomies ή native λειτουργίες υπάρχουν ήδη. Διατηρήστε το νόημα και τις δεσμεύσεις της πηγής χωρίς να αναπαράγετε περιττό legacy τεχνικό χρέος.
Δώστε σε κάθε URL, προϊόν, κανόνα ή εγγραφή σαφές status. Τρέξτε τον κατάλληλο έλεγχο πριν προχωρήσετε και κρατήστε checkpoint ώστε ένα retry να μη δημιουργεί διπλότυπα.
Ξεχωρίστε validation failure, timeout, έλλειψη πόρων, απουσία πηγής και ανάγκη απόφασης. Ορίστε ποια failures επαναλαμβάνονται αυτόματα και ποια περνούν σε άνθρωπο με επαρκές context.
Παρακολουθήστε ποσοστό σωστής ολοκλήρωσης, διορθώσεις, retries, ανθρώπινες παρεμβάσεις, χρόνο ανά verified result και περιστατικά σιωπηρής παράλειψης. Επεκτείνετε τη ροή μόνο όταν τα αποτελέσματα επαναλαμβάνονται.
Το reformalization του Jordan Curve Theorem δεν αποδεικνύει ότι κάθε σύνθετη εργασία μπορεί να αυτοματοποιηθεί με τον ίδιο τρόπο. Οι proof assistants διαθέτουν εξαιρετικά σαφή semantics και ισχυρούς checkers, ενώ πολλά επιχειρησιακά προβλήματα έχουν ασαφείς στόχους, μεταβαλλόμενα δεδομένα και κοινωνικές ή νομικές συνέπειες. Οι ίδιοι οι συγγραφείς τονίζουν ότι η προσέγγιση δεν είναι silver bullet και ότι μεγάλες διαφορές θεμελίων παραμένουν δύσκολες.
Η μελέτη δείχνει όμως κάτι εφαρμόσιμο: η ποιότητα του μοντέλου είναι μόνο ένα μέρος του συστήματος. Η ωριμότητα προκύπτει από πηγές, decomposition, library alignment, state, γρήγορο feedback, validators και ξεκάθαρο ανθρώπινο ρόλο. Ένα brand που οργανώνει τη γνώση, τα δεδομένα και τα acceptance criteria του μπορεί να αξιοποιήσει περισσότερη αυτονομία με μικρότερο ρίσκο από ένα brand που επενδύει μόνο σε μεγαλύτερα prompts.
Το πιο χρήσιμο ερώτημα λοιπόν δεν είναι «ποιο μοντέλο θα κάνει όλη τη δουλειά;». Είναι «ποια πηγή εμπιστευόμαστε, ποιο εργαλείο ελέγχει κάθε στάδιο και τι συμβαίνει όταν η επαλήθευση αποτύχει;». Όταν αυτές οι απαντήσεις είναι συγκεκριμένες, το AI μετακινείται από το εντυπωσιακό demo σε υποδομή που μπορεί να υποστηρίξει πραγματική λειτουργία.
Από το demo σε ελεγχόμενη επιχειρησιακή ροή
Η TWO DOTS χαρτογραφεί πηγές αλήθειας, integrations, validators, permissions και ανθρώπινα approval gates, ώστε κάθε AI workflow να έχει σαφή κατάσταση, μετρήσιμο αποτέλεσμα και ασφαλή διαδρομή αποτυχίας.
Συχνές ερωτήσεις
Είναι η μεταφορά μιας ήδη τυπικά ελεγμένης απόδειξης από ένα proof assistant σε άλλο. Ο στόχος είναι μια νέα, ανεξάρτητα ελέγξιμη ανάπτυξη που παραμένει πιστή στην πηγή και χρησιμοποιεί φυσικά τη βιβλιοθήκη και τα εργαλεία του συστήματος-στόχου.
Το autoformalization ξεκινά συνήθως από φυσική γλώσσα, η οποία μπορεί να έχει κενά ή άρρητες παραδοχές. Το reformalization ξεκινά από πλήρη formal development, άρα διαθέτει λεπτομερή και ήδη ελεγμένη πηγή αλήθειας.
Είναι απλό στη διατύπωση αλλά μεγάλο και τεχνικά ετερογενές στην τυπική απόδειξη. Οι ώριμες υλοποιήσεις σε διαφορετικούς proof assistants το κάνουν κατάλληλο stress test για decomposition, library alignment, bookkeeping και verification loops.
Η πηγή, τα dependency metadata και η αντιστοίχιση με τη Mathlib επέτρεψαν στον agent να χτίσει native Lean development αντί να αντιγράψει μηχανικά το Mizar. Όταν απομακρυνόταν από την πηγή, η ανθρώπινη παρέμβαση τον επανέφερε στη διαδικασία.
Κάνει ορατή την κατάσταση κάθε μονάδας εργασίας, τις εξαιρέσεις και το τελευταίο έγκυρο checkpoint. Έτσι αποφεύγονται σιωπηρές παραλείψεις, διπλότυπα και καθυστερημένα blockers σε migrations, περιεχόμενο ή αυτοματισμούς.
Είναι ο εξωτερικός μηχανισμός που αποδεικνύει ότι το output πληροί τις απαιτήσεις: tests, schema validation, reconciliation με ERP, έλεγχος feed, link και HTML checks, preview ή ανθρώπινο approval για αποφάσεις υψηλού ρίσκου.
Όχι. Το paper δείχνει ότι η επιτυχία εξαρτάται επίσης από την ποιότητα των πηγών και των βιβλιοθηκών, τη διάσπαση της εργασίας, την ταχύτητα του feedback, το state, τους validators, τα guardrails και τη σαφή ανθρώπινη εποπτεία.
