Έχετε ποτέ κοιτάξει τον κώδικα που παράγει το αγαπημένο σας LLM;
Και κυρίως τις επιδόσεις του, ανάμεσα στη φλυαρία του παραγόμενου κώδικα, το κόστος παραγωγής του και την ταχύτητα εκτέλεσης του σεναρίου;
Δοκίμασα, μέσω του OpenCode Go (10 USD/μήνα), αρκετά LLM σε ένα απλό prompt: «Φτιάξε ένα PHP script που καταναλώνει ένα αρχείο XML 100.000 εγγραφών όσο το δυνατόν γρηγορότερα.»
Στο τέλος, δοκίμασα 6 LLM (αυτή τη στιγμή χρησιμοποιώ εκτενώς το DeepSeek v4.1 Flash, το οποίο βρίσκω εξαιρετικό για coding).
DeepSeek v4.1 Flash, Grok 4.7, Kimi K3.1 Pro, GPT-6 Luna, Gemini-5 Argon και Claude Haiku 5.5.
Και τα αποτελέσματα σε αυτό το αίτημα είναι τα εξής:
Ο πιο συμπαγής κώδικας παράγεται από το GPT-6 Luna, σε 29 δευτερόλεπτα, με κόστος 0,00156 USD! Αυτή είναι η μεγάλη μου έκπληξη του τεστ: το OpenAI είναι 10 φορές φθηνότερο με το Luna από το DeepSeek…
Το γρηγορότερο script παράγεται από το DeepSeek v4.1 Flash, το οποίο φτάνει τις 528.000 εγγραφές/s στην επεξεργασία αρχείου.
Πράγματι χρειάζεται μόνο 189 ms για να κάνει parse τις 100.000 εγγραφές XML!
Επιλέγει να χρησιμοποιήσει το XMLReader σε streaming… και είναι το γρηγορότερο.
Το Claude Haiku 5.5 είναι επίσης φθηνό σε αυτό το benchmark, παράγει τον κώδικα πολύ γρήγορα (17 δευτερόλεπτα), έναντι 115 δευτερολέπτων (σχεδόν 7 φορές περισσότερο) για το DeepSeek, αλλά παράγει κώδικα που είναι από τους πιο αργούς σε εκτέλεση.
Όσον αφορά την αναλογία επιδόσεων / ταχύτητας / κόστους, το DeepSeek προηγείται σε αυτό, αν κάποιος δίνει προτεραιότητα στην ταχύτητα εκτέλεσης του παραγόμενου κώδικα.
Το Grok είναι πολύ ακριβό (20 φορές περισσότερο από το DeepSeek), αλλά έρχεται δεύτερο σε επιδόσεις.
Το Luna είναι 10 φορές φθηνότερο από το DeepSeek, για να έρθει τέταρτο σε επιδόσεις, με εξαιρετικά γρήγορη παραγωγή (29 δευτερόλεπτα).
Αυτό που είναι ενδιαφέρον σε αυτή τη μικρή άσκηση είναι ότι δεν μετράμε απλώς την ικανότητα ενός LLM να παράγει λειτουργικό κώδικα, αλλά και την ικανότητά του να κάνει τις σωστές τεχνικές επιλογές, να αποφεύγει την περιττή φλυαρία και να παράγει ένα πραγματικά αποδοτικό πρόγραμμα.
Και, σαφώς, το πιο ακριβό μοντέλο δεν είναι απαραίτητα αυτό που παράγει τον καλύτερο κώδικα.
Αυτό επίσης ilustra ένα άλλο πρόβλημα: ποια μοντέλα για ποιες εργασίες…
(Η καλή) ενορχήστρωση πρόκειται να γίνει ένα ολοένα και πιο σημαντικό ζήτημα.
Πηγές LinkedIn
- Προφίλ: Pierre Jean Duvivier dit Sage (LinkedIn)
Η ανάρτηση Έχετε ποτέ κοιτάξει τον κώδικα που παράγει το αγαπημένο σας LLM; εμφανίστηκε πρώτα στο les plumes qui mordent.
Συχνές Ερωτήσεις
FAQs Κοιτάζοντας τον Κώδικα που Παράγει το Αγαπημένο σας LLM
1 Τι σημαίνει να κοιτάζεις τον κώδικα που παράγει ένα LLM
Σημαίνει να διαβάζεις πραγματικά, να εκτελείς και να ελέγχεις τον κώδικα που σου δίνει ένας βοηθός AI αντί να τον αντιγράφεις και να τον επικολλάς στα τυφλά
2 Γιατί να μπω στον κόπο να διαβάσω κώδικα που παράγεται από AI
Επειδή τα LLM μπορεί να κάνουν λάθος με αυτοπεποίθηση Το να διαβάζεις τον κώδικα σε βοηθά να εντοπίσεις bugs ζητήματα ασφαλείας και λογικά λάθη πριν φτάσουν στο project σου
3 Χρειάζεται να είμαι ειδικός για να ελέγξω κώδικα AI
Όχι Ακόμη και η βασική ανάγνωση βοηθά μπορείς να εντοπίσεις προφανή προβλήματα όπως hardcoded passwords έλλειψη χειρισμού σφαλμάτων ή κώδικα που δεν αντιστοιχεί σε αυτό που ζήτησες
4 Τι είδους λάθη κάνουν συνήθως τα LLM στον κώδικα
Τυπικά ζητήματα περιλαμβάνουν hallucinated συναρτήσεις ή βιβλιοθήκες παρωχημένα APIs σφάλματα offbyone που λείπουν edge cases και μη ασφαλείς προεπιλογές
5 Μπορεί ο κώδικας που παράγεται από AI να περιέχει ευπάθειες ασφαλείας
Ναι Τα μοντέλα μερικές φορές παράγουν κώδικα με κινδύνους SQL injection αδύναμη επικύρωση εισόδου ή εκτεθειμένα secrets Πάντα να ελέγχεις πριν το shipping
6 Γιατί ο κώδικας μερικές φορές αναφέρεται σε συναρτήσεις ή πακέτα που δεν υπάρχουν
Τα LLM προβλέπουν κείμενο που φαίνεται εύλογο οπότε μπορούν να επινοήσουν APIs Αυτό ονομάζεται hallucination πάντα να επαληθεύεις ότι τα imports και οι συναρτήσεις υπάρχουν πραγματικά
7 Είναι συνήθως σωστός ο κώδικας που παράγεται από AI
Συχνά είναι κοντά αλλά συνήθως το κοντά δεν είναι αρκετά καλό για production Αντιμετώπισέ το ως πρώτο draft όχι ως τελική απάντηση
8 Ποιος είναι ο γρηγορότερος τρόπος να ελέγξω κώδικα AI
Εκτέλεσέ το σε ένα μικρό test case διάβασέ το γραμμή προς γραμμή και έλεγξε ότι κάθε import και κάθε κλήση συνάρτησης είναι πραγματική Στη συνέχεια δοκίμασε edge cases
9 Πρέπει να δοκιμάζω τον κώδικα που παράγεται από AI διαφορετικά από τον δικό μου κώδικα
Όχι πραγματικά αλλά δοκίμασέ τον διεξοδικά ειδικά τα edge cases και τις διαδρομές σφαλμάτων αφού το μοντέλο μπορεί να μην τις έχει λάβει υπόψη
10 Μπορώ να εμπιστευτώ κώδικα AI αν φαίνεται καθαρός και καλά μορφοποιημένος
Όχι Η καθαρή μορφοποίηση δεν λέει τίποτα για την ορθότητα Μερικός από τον πιο πειστικό κώδικα AI είναι διακριτικά σπασμένος
11 Ποια είναι τα οφέλη του να ελέγχεις κώδικα AI αντί να τον απορρίπτεις εξαρχής
Παίρνεις την ταχύτητα της παραγωγής AI συν την ασφάλεια της ανθρώπινης κρίσης και συχνά μαθαίνεις νέα patterns ή προσεγγίσεις στην πορεία
12 Πώς ξέρω αν η AI χρησιμοποίησε παρωχημένη βιβλιοθήκη ή API
Έλεγξε το
