Το κρυφό κόστος του νέφους

Κεφάλαιο 5 — Το κρυφό κόστος του νέφους

Η κυρίαρχη αφήγηση των τελευταίων πέντε ετών λέει ότι το νέφος είναι οικονομικό, επεκτάσιμο και απλό. Για πολλούς φόρτους εργασίας αυτό είναι απολύτως αληθές. Για τα εταιρικά RAG, όλο και πιο συχνά, δεν είναι. Και η στιγμή που το συνειδητοποιείς είναι συνήθως στο τέλος του πρώτου τριμήνου, όταν έρχεται ο λογαριασμός.

Ας πάρουμε την πιο υποτιμημένη γραμμή του λογαριασμού: τα API των μοντέλων όρασης. Όταν μια εταιρεία εισάγει το φωτογραφικό της αρχείο σε ένα σύγχρονο RAG, κάθε φωτογραφία πρέπει να "περιγραφεί" από ένα πολυτροπικό μοντέλο που εξάγει περιεχόμενο, αντικείμενα, πλαίσιο, τυχόν επικαλυπτόμενα κείμενα, διάθεση, σύνθεση. Ένας μεγάλος ευρωπαϊκός πάροχος μοντέλων — ακόμα χωρίς όνομα — προσέφερε το 2025 ένα εξαιρετικό μοντέλο της οικογένειας Qwen με 32 δισεκατομμύρια παραμέτρους, σε μια ενδιαφέρουσα τιμή ανά εικόνα. Το πρόβλημα, που ανακαλύφθηκε μόνο στο πεδίο και μετά από μήνες παραγωγής: υπό φόρτο, ο πάροχος περικόπτει τις απαντήσεις. Όχι πάντα, όχι με προβλέψιμο τρόπο, όχι όταν ήταν μπροστά η ομάδα δοκιμών: τυχαία. Μια φωτογραφία στις δέκα, μερικές φορές μία στις πέντε, επέστρεφε με ένα JSON κομμένο στη μέση, κακώς αναλυμένο, με μερικά ή μηδενικά μεταδεδομένα. Οι χρόνοι εκτινάχθηκαν από δέκα δευτερόλεπτα σε διακόσια δευτερόλεπτα ανά εικόνα, χωρίς μοτίβο. Το κόστος της επανεκτέλεσης — επειδή οι επανεκτελέσεις χρεώνονται, κάθε κλήση, ακόμη και αυτή που ο διακομιστής περικόπτει — ήταν υψηλότερο από το αναμενόμενο. Η βάση δεδομένων ήταν ανομοιογενής: ορισμένες φωτογραφίες πλούσιες σε μεταδεδομένα, άλλες ελλιπείς. Και η ομάδα δεν μπόρεσε να αναπαράγει το πρόβλημα σε περιβάλλοντα δοκιμών, επειδή στις δοκιμές το φορτίο ήταν χαμηλό και όλα λειτουργούσαν.

Η λύση ήρθε σε τρία κομμάτια: ένα πιο συνοπτικό prompt (οι συντομότερες απαντήσεις δεν αποκόπτονται τόσο εύκολα), μια έξυπνη λογική επανάληψης (αν η απάντηση διαρκέσει περισσότερο από πενήντα δευτερόλεπτα και επιστρέψει κενή, δοκιμάστε ξανά αμέσως) και — όταν ο όγκος το δικαιολογεί — η δυνατότητα να παρακάμψετε εντελώς το cloud και να εκτελέσετε το μοντέλο όρασης σε μια τοπική GPU, πιο αργή αλλά ντετερμινιστική. Η σωστή αρχιτεκτονική, από αυτή την εμπειρία, δεν είναι "cloud πάντα" ούτε "τοπικό πάντα". Είναι "επιλέξτε για κάθε κλήση, ανάλογα με αυτό που χρειάζεται εκείνη τη στιγμή".

Έπειτα υπάρχει το κεφάλαιο των ερωτημάτων. Κάθε αναζήτηση χρήστη, σε ένα κλασικό RAG εγγενώς βασισμένο στο cloud, πυροδοτεί μια κασκαντέρ πληρωμένων κλήσεων API. Μία για την ενσωμάτωση της ερώτησης. Μία για την ταξινόμηση της πρόθεσης (τι είδους ερώτηση είναι;). Μία για την επανακατάταξη των εγγράφων. Μία για τη δημιουργία της τελικής απάντησης. Κάθε μία κοστίζει ένα κλάσμα του λεπτού. Για μια εσωτερική υπηρεσία με πενήντα χρήστες και δέκα χιλιάδες ερωτήματα την ημέρα — που δεν είναι λίγα αλλά ούτε και τεράστιος αριθμός για μια μέση εταιρεία — ο μηνιαίος λογαριασμός φτάνει σε νούμερα που θα έκαναν ακόμη και έναν επιεική CFO να συνοφρυωθεί. Και η ανάπτυξη είναι γραμμική: διπλασιάζετε τους χρήστες, διπλασιάζετε τον λογαριασμό. Δεν υπάρχουν οικονομίες κλίμακας στα tokens που καταναλώνονται, όχι για εσάς.

Υπάρχει επίσης ένα πρόβλημα που ήταν υποδόριο το 2025 και έγινε κεντρικό το 2026: κάθε μεμονωμένο ερώτημα στέλνει τμήματα εταιρικών εγγράφων — μερικές φορές εμπιστευτικά, μερικές φορές καλυπτόμενα από NDA, μερικές φορές υπόκειμενα σε κανονισμούς του κλάδου — στους διακομιστές ενός εξωτερικού παρόχου, σε δικαιοδοσίες που δεν συμπίπτουν πάντα με τη δική σας, με πολιτικές διατήρησης των αρχείων καταγραφής που δεν είναι πάντα διαφανείς. Περισσότερες από μία ευρωπαϊκές εταιρείες, τους τελευταίους δεκαοκτώ μήνες, ανακάλυψαν μόνο κατά τη διάρκεια ενός ελέγχου — συνήθως προκαλούμενου από έναν ανήσυχο πελάτη ή από μια επαλήθευση ISO — ότι τα συμβόλαιά τους, οι τιμοκατάλογοι και οι τεχνικές προδιαγραφές είχαν υποβληθεί σε επεξεργασία (και ενδεχομένως καταγραφεί για σκοπούς "βελτίωσης της υπηρεσίας") από υποδομές εκτός ΕΕ. Η έκπληξη, συνήθως, κόστισε περισσότερο από την εξοικονόμηση που επιδιώχθηκε αποφεύγοντας τον τοπικό υλικό.

Η εναλλακτική δεν είναι ο αντίθετος δογματισμός. Το "Όχι cloud, μόνο τοπικά" είναι εξίσου λάθος με το "Cloud πάντα". Η εναλλακτική είναι μια αρχιτεκτονική που σας επιτρέπει να επιλέγετε, για κάθε μεμονωμένο κομμάτι της διοχέτευσης — embedding, ταξινόμηση, επανακατάταξη, όραση, τελική δημιουργία —, εάν θα χρησιμοποιήσετε ένα μοντέλο cloud ή ένα τοπικό, και να αλλάξετε γνώμη σε μια ημέρα, όχι σε ένα τρίμηνο. Αυτό απαιτεί ένα σχέδιο στο οποίο οι προμηθευτές είναι εναλλάξιμοι, όπου κανένα κομμάτι δεν είναι δεσμευμένο στο όνομα μιας συγκεκριμένης εταιρείας, όπου η μετάβαση από το Regolo στο Ollama (ή το αντίστροφο) είναι μια γραμμή διαμόρφωσης, όχι μια επανεγγραφή. Και αυτό, μέχρι πρόσφατα, ήταν σπάνιο. Τα δημοφιλή πλαίσια, παρά την πρόσοψη του "ανεξάρτητου από τον πάροχο", ήταν στην πραγματικότητα πολύ συνδεδεμένα με κάποιον.