Προγραμματισμός

4 παράγοντες για τη δοκιμή εφαρμογών μηχανικής μάθησης

Τα συστήματα μηχανικής εκμάθησης μοιάζουν λίγο με ένα μαθηματικό πρόβλημα. Βρείτε τον αλγόριθμο, αναδυθείτε στα δεδομένα και βγαίνουν απαντήσεις.

Αλλά πώς ξέρετε ότι οι απαντήσεις είναι σωστές;

Όταν προσπαθείτε να προβλέψετε ποιες ταινίες ή βιβλία αρέσουν στους ανθρώπους, αυτό μπορεί να είναι εξαιρετικά σημαντικό, η διαφορά μεταξύ της αύξησης των εσόδων και της επιτυχίας φήμης που εμφανίζεται στο mediabuzz.com. Ωστόσο, η δοκιμή είναι σπάνια στο μυαλό μας καθώς προσπαθούμε να αναπτύξουμε και να αναπτύξουμε συστήματα που βασίζονται σε αλγόριθμους μηχανικής μάθησης. Η απλή δημιουργία ενός καλού συνόλου αλγορίθμων που διαμορφώνουν τον προβληματικό χώρο είναι αρκετά δύσκολο. Όμως, η δοκιμή είναι μέρος της διαδικασίας ανάπτυξης και ανάπτυξης λογισμικού και πρέπει να εξετάσουμε σοβαρά πώς θα δοκιμαστούν αυτά τα συστήματα.

Ο πρώτος, πιο συνηθισμένος τύπος δοκιμών είναι όπου η εφαρμογή δοκιμάζεται σε μονάδα από προγραμματιστές, «δοκιμάστηκε καπνός» με αυτοματοποίηση κατά τη διαδικασία κατασκευής και ολοκλήρωσης και δοκιμάστηκε χειροκίνητα από δοκιμαστές. Αυτή η διαδικασία είναι γνωστή, αν και θα ποικίλει ανάλογα με τον τύπο του συστήματος που αναπτύσσεται.

Ο δεύτερος τύπος δοκιμών βασίζεται σε δεδομένα πραγματικού κόσμου, τα οποία ποικίλλουν ανάλογα με τα δεδομένα που διαβιβάζονται. Για παράδειγμα, ένας από τους πελάτες της Matt έγραψε λογισμικό για τον περιορισμό του κινδύνου στις χρηματοοικονομικές συναλλαγές. Το λογισμικό θα αναλύσει την αγορά και θα χαλαρώσει αργά ένα μπλοκ μετοχών για μια περίοδο ημερών, σχεδιασμένο να μην ξεκινά προειδοποιήσεις από πλευράς πώλησης. Η πρώτη είσοδος ήταν το μπλοκ προς πώληση, αλλά η δεύτερη, σε πραγματικό χρόνο, οι χρηματοοικονομικές αγορές, οι οποίες ποικίλλουν με την πάροδο του χρόνου, οπότε οι δοκιμαστικές πωλήσεις δεν θα ταιριάζουν με τις πωλήσεις στην παραγωγή. Αυτό είναι όπου οι δοκιμές γίνονται πιο προβληματικές. Πώς δοκιμάζουμε συστήματα που ενδέχεται να επιστρέψουν ένα διαφορετικό αποτέλεσμα στα ίδια δεδομένα με την πάροδο του χρόνου; Οι παραδοσιακές τεχνικές δοκιμών δεν έχουν κανένα τρόπο να λάβουν υπόψη ένα τέτοιο αποτέλεσμα. Τι πρέπει λοιπόν να κάνουν οι δοκιμαστές;

Η ποιοτική δοκιμή συστημάτων μηχανικής εκμάθησης δεν είναι ίδια με τη δοκιμή οποιουδήποτε άλλου τύπου λογισμικού. Στις περισσότερες καταστάσεις δοκιμών, προσπαθείτε να βεβαιωθείτε ότι η πραγματική έξοδος ταιριάζει με την αναμενόμενη. Με συστήματα μηχανικής εκμάθησης, το να αναζητάτε ακριβώς τη σωστή έξοδο είναι ακριβώς η λάθος προσέγγιση. Πιθανότατα δεν μπορείτε καν να υπολογίσετε το "σωστό αποτέλεσμα" χωρίς να γράψετε το λογισμικό δύο φορές. Ακόμα και τότε, μπορεί να μην είναι δυνατό.

Σε τι πρέπει να επικεντρωθούν οι υπεύθυνοι δοκιμών για εφαρμογές μηχανικής μάθησης:

1. Έχετε αντικειμενικά και μετρήσιμα κριτήρια αποδοχής. Γνωρίστε την τυπική απόκλιση που μπορείτε να αποδεχτείτε στον προβληματικό σας χώρο. Αυτό απαιτεί ορισμένες ποσοτικές πληροφορίες και την ικανότητα να βεβαιωθείτε ότι κατανοείτε και ερμηνεύετε αυτές τις μετρήσεις.

2. Δοκιμάστε με νέα δεδομένα, αντί για τα αρχικά δεδομένα εκπαίδευσης. Εάν είναι απαραίτητο, χωρίστε το σετ εκπαίδευσης σε δύο ομάδες: μία που κάνει προπόνηση και μια που κάνει δοκιμές. Καλύτερα, αποκτήστε και χρησιμοποιήστε νέα δεδομένα εάν είστε σε θέση.

3. Μην υπολογίζετε ότι όλα τα αποτελέσματα είναι ακριβή. Σκεφτείτε τους ως την καλύτερη εικασία βάσει των διαθέσιμων δεδομένων. Εάν αυτό δεν είναι αρκετά καλό, το πρόβλημα θα μπορούσε να είναι ο alogirthmn ή, πιθανότατα, το σύνολο δεδομένων. Σε ορισμένες περιπτώσεις, το "tweaking" του συνόλου δεδομένων για καθαρή εισαγωγή μπορεί να είναι η ταχύτερη λύση για αυτό το πρόβλημα.

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

Η κατώτατη γραμμή

Το κλειδί για τη δοκιμή του συστήματος είναι να κατανοήσουμε τόσο τις απαιτήσεις για τα αποτελέσματα παραγωγής όσο και τους περιορισμούς των αλγορίθμων. Οι απαιτήσεις πρέπει να μεταφραστούν σε αντικειμενικές μετρήσεις. Στην ιδανική περίπτωση, η τυπική απόκλιση του μέσου αποτελέσματος, υποθέτοντας ότι το μέσο αποτέλεσμα σχετίζεται στενά με το πραγματικό αποτέλεσμα που βρέθηκε στα δεδομένα εκπαίδευσης. Πρέπει να είστε σε θέση να αξιολογήσετε τα αποτελέσματά σας από στατιστική άποψη και όχι από άποψη ναι-όχι.

Μην βασίζεστε στην ακριβή σωστή απάντηση όλη την ώρα, ή ακόμα και τις περισσότερες φορές. Ο τρόπος δοκιμής και ο τρόπος αξιολόγησής σας εξαρτώνται εξ ολοκλήρου από τους στόχους του συστήματος. Για τα παξιμάδια των δοκιμών, είναι πολύτιμο να έχουμε μια πλατφόρμα όπως το Intel Parallel Studio XE για την ανάπτυξη και δοκιμή κώδικα και αλγορίθμων.

Τώρα είναι πιο εύκολο από ποτέ να γράψετε τον κώδικά σας για παράλληλη εκτέλεση - Δοκιμάστε το Intel® Parallel Studio XE δωρεάν για 30 ημέρες

 

$config[zx-auto] not found$config[zx-overlay] not found