# Argilla

[https://argilla.glossapi.gr/](https://argilla.glossapi.gr/)

# Είσοδος στην πλατφόρμα (Login)

### Σύνδεση στον λογαριασμό σας

Για να εισέλθετε, ακολουθήστε τα παρακάτω βήματα:

#### Βήμα 1: Μεταβείτε στην αρχική σελίδα
Ανοίξτε τον φυλλομετρητή σας και πληκτρολογήστε τη διεύθυνση:  
[https://argilla.glossapi.gr/](https://argilla.glossapi.gr/)

#### Βήμα 2: Επιλέξτε «Σύνδεση με Keycloak»
Στην αρχική σελίδα, εντοπίστε και πατήστε το κουμπί **«Σύνδεση με Keycloak»** (δείτε την φωτογραφία, μέσα στο πλαίσιο).  
Αυτή η ενέργεια θα σας μεταφέρει με ασφάλεια στο σύστημα ταυτοποίησης της πλατφόρμας.

[![argilla-login.png](https://docs.ellak.gr/uploads/images/gallery/2026-06/scaled-1680-/argilla-login.png)](https://docs.ellak.gr/uploads/images/gallery/2026-06/argilla-login.png)

#### Βήμα 3: Συμπληρώστε τα στοιχεία σας
Στη φόρμα εισόδου που θα εμφανιστεί:
- **Username:** πληκτρολογήστε το όνομα χρήστη που σας έχει δοθεί.
- **Password:** πληκτρολογήστε τον κωδικό πρόσβασης.

[![argilla-keycloak.png](https://docs.ellak.gr/uploads/images/gallery/2026-06/scaled-1680-/argilla-keycloak.png)](https://docs.ellak.gr/uploads/images/gallery/2026-06/argilla-keycloak.png)

#### Βήμα 4: Ολοκληρώστε την είσοδο
Πατήστε το κουμπί εισόδου (π.χ. «Σύνδεση» ή «Sign In»).  
Μετά την επιτυχή ταυτοποίηση, θα μεταφερθείτε αυτόματα στο κεντρικό περιβάλλον εργασίας της πλατφόρμας.

> **Σημείωση:** Αν αντιμετωπίσετε πρόβλημα με τα στοιχεία σας, επικοινωνήστε με τον διαχειριστή.

Δείτε και το [βίντεο εδώ](https://tube.ellak.gr/view?m=6Ld9Qs89g).

# Περιβάλλον εργασίας και αξιολόγηση δεδομένων

### Βασική πλοήγηση και διαδικασία αξιολόγησης

Μόλις συνδεθείτε, θα βρεθείτε στο κεντρικό ταμπλό του Argilla. Ακολουθήστε αυτόν τον οδηγό για να εξοικειωθείτε και να ξεκινήσετε την εργασία σας.

#### 1. Γνωριμία με το κεντρικό περιβάλλον
- Στην κεντρική σελίδα βλέπετε με μία ματιά:
  - **Διαθέσιμα σύνολα δεδομένων (datasets)** που έχουν ανατεθεί σε εσάς.
  - **Πρόοδο εργασιών** (πόσα σημεία έχετε αξιολογήσει, πόσα απομένουν).
- Το περιβάλλον είναι φιλικό και σχεδιασμένο ώστε να εστιάζετε στο περιεχόμενο.

[![argilla-env.png](https://docs.ellak.gr/uploads/images/gallery/2026-06/scaled-1680-/argilla-env.png)](https://docs.ellak.gr/uploads/images/gallery/2026-06/argilla-env.png)

#### 2. Πρόσβαση στις αναλυτικές οδηγίες αξιολόγησης
Πριν ξεκινήσετε την αξιολόγηση οποιουδήποτε dataset, **υποχρεωτικά** διαβάστε τις επίσημες οδηγίες:
- Μέσα στην πλατφόρμα, αναζητήστε το κουμπί **[«Οδηγός Reviewers για το glossApi»](https://argilla.glossapi.gr/docs/reviewer_guides/Reviewers.html)** (συνήθως βρίσκεται σε εμφανές σημείο, π.χ. επάνω δεξιά ή στο πλαϊνό μενού).
- Πατήστε το για να ανοίξει ο πλήρης οδηγός, όπου θα βρείτε:
  - Κανόνες σχολιασμού
  - Παραδείγματα σωστών και λανθασμένων αξιολογήσεων
  - Οδηγίες για το πώς να ψηφίζετε ή να διορθώνετε δεδομένα

> **Σημαντικό:** Κάθε dataset ενδέχεται να έχει ειδικές οδηγίες. Ελέγχετε πάντα τον οδηγό πριν ξεκινήσετε.

[![argilla-Reviewers.png](https://docs.ellak.gr/uploads/images/gallery/2026-06/scaled-1680-/argilla-reviewers.png)](https://docs.ellak.gr/uploads/images/gallery/2026-06/argilla-reviewers.png)

#### 3. Νέα datasets και ενημερώσεις
- Η πλατφόρμα εμπλουτίζεται συχνά με **νέα datasets** προς επεξεργασία.
- **Δεν χρειάζεται να συνδέεστε καθημερινά.** Θα λαμβάνετε περιοδικά **ενημερωτικά email**, τα οποία θα σας ειδοποιούν όταν υπάρχουν νέα δεδομένα προς αξιολόγηση.
- Όταν λάβετε ειδοποίηση, συνδεθείτε, διαβάστε τυχόν νέες οδηγίες και ξεκινήστε την αξιολόγηση.

#### 4. Συμβουλές για αποτελεσματική εργασία
- Εργάζεστε με τον δικό σας ρυθμό, αρκεί να τηρείτε τα χρονικά περιθώρια που αναφέρονται στα email.
- Αν έχετε απορίες, συμβουλευτείτε ξανά τον «Οδηγό Reviewers» ή επικοινωνήστε με την ομάδα διαχείρισης.
- Κάθε σχόλιο ή διόρθωση που κάνετε είναι πολύτιμη για τη βελτίωση των δεδομένων.

# Οδηγός Reviewers για το glossApi

## Ποιο guide να διαβάσω

* [Αναλυτικός οδηγός reviewers](/docs/reviewer_guides/Reviewers.html): πλήρης έκδοση με κριτήρια, καλές πρακτικές και παραδείγματα.
* [One-page guide](/docs/reviewer_guides/Reviewers-OnePage.html): σύντομη έκδοση για γρήγορη αναφορά.
* [Οδηγός για μη τεχνικούς reviewers](/docs/reviewer_guides/Reviewers-NonTechnical.html): απλή έκδοση σε καθημερινή γλώσσα.

## Σκοπός του review

Ο ρόλος του reviewer δεν είναι απλώς να “διορθώσει κείμενα”. Κάθε record που γίνεται `accept`, `edit` ή `reject` επηρεάζει άμεσα την ποιότητα του dataset που θα χρησιμοποιηθεί για fine-tuning. Ένα λάθος `accept` μπορεί να περάσει θόρυβο στο training. Ένα σωστό `reject` μπορεί να αφαιρέσει προβληματικά παραδείγματα. Ένα σωστό `edit` μπορεί να μετατρέψει ένα μέτριο παράδειγμα σε χρήσιμο training sample.

Στόχος είναι κάθε τελικό ζευγάρι `question` και `answer` να είναι:

* σωστό με βάση το `source_text`
* καθαρό και φυσικό στα Ελληνικά
* χρήσιμο για εκπαίδευση μοντέλου
* συνεπές με τα υπόλοιπα reviewed records

## Πού θα δουλέψετε

Για την τρέχουσα παραγωγική ροή:

* Argilla URL: `https://argilla.glossapi.gr`
* Workspace: `default`

Επιλέξτε το review dataset που σας έχει ανατεθεί και ξεκινήστε να δουλέψετε.

Αν υπάρχουν φίλτρα στο UI, προτιμήστε να δουλεύετε πρώτα στα records που είναι ακόμη pending ή δεν έχουν review response.

## Τι βλέπει ο reviewer σε κάθε record

Το review dataset έχει τρία read-only πεδία και τρία review πεδία.

Read-only πεδία:

* `source_text`: το αρχικό κείμενο από το οποίο πρέπει να προκύπτουν η ερώτηση και η απάντηση
* `generated_question`: η ερώτηση που παρήγαγε το μοντέλο
* `generated_answer`: η απάντηση που παρήγαγε το μοντέλο

Review πεδία:

* `review_action`: `accept`, `edit`, `reject`
* `corrected_question`: διορθωμένη ερώτηση, μόνο όταν χρειάζεται
* `corrected_answer`: διορθωμένη απάντηση, μόνο όταν χρειάζεται

## Βασική αρχή αξιολόγησης

Ο reviewer πρέπει να στηρίζεται μόνο στο `source_text`.

Μην χρησιμοποιείτε:

* εξωτερική γνώση
* προσωπικές υποθέσεις
* γνώσεις για το μάθημα ή το βιβλίο που δεν εμφανίζονται ρητά στο κείμενο
* συμπλήρωση κενών με εικασία

Αν μια πληροφορία δεν υποστηρίζεται από το κείμενο, δεν πρέπει να παραμείνει στο τελικό training sample.

## Ροή εργασίας ανά record

1. Διαβάστε πρώτα ολόκληρο το `source_text`.
2. Διαβάστε το `generated_question`.
3. Ελέγξτε αν η ερώτηση είναι σαφής, μία και μόνο μία, και απαντιέται από το κείμενο.
4. Διαβάστε το `generated_answer`.
5. Ελέγξτε αν η απάντηση είναι σωστή, πλήρης και αυστηρά τεκμηριωμένη από το κείμενο.
6. Επιλέξτε `Accept as-is`, `Edit` ή `Reject`.
7. Αν επιλέξετε `Edit`, συμπληρώστε μόνο τα πεδία που χρειάζονται πραγματικά αλλαγή.
8. Κάντε έναν τελευταίο έλεγχο ότι η τελική ερώτηση και η τελική απάντηση ταιριάζουν μεταξύ τους.
9. Υποβάλετε το review response.

## Πότε να κάνετε Accept as-is

Επιλέξτε `Accept as-is` όταν ισχύουν όλα τα παρακάτω:

* η ερώτηση είναι κατανοητή και σαφής
* η ερώτηση βασίζεται στο `source_text`
* η ερώτηση δεν ζητά πληροφορία που δεν υπάρχει στο κείμενο
* η απάντηση απαντά ακριβώς στην ερώτηση
* η απάντηση υποστηρίζεται από το κείμενο χωρίς εικασίες
* η απάντηση δεν περιέχει πρόσθετες, μη τεκμηριωμένες λεπτομέρειες
* η γλώσσα είναι επαρκώς φυσική και καθαρή
* δεν υπάρχει ουσιαστικό ορθογραφικό, νοηματικό ή πραγματολογικό πρόβλημα

Κάντε `Accept as-is` ακόμη και αν θα μπορούσατε θεωρητικά να το γράψετε λίγο καλύτερα, όταν η υπάρχουσα διατύπωση είναι ήδη σωστή και χρήσιμη για training. Δεν χρειάζεται edit για καθαρά προσωπικές προτιμήσεις ύφους.

## Γιατί να κάνετε Accept as-is

Το `Accept as-is` είναι σωστή επιλογή όταν το παράδειγμα είναι ήδη καλό, γιατί:

* διατηρείται η ταχύτητα του review
* αποφεύγονται περιττές ανθρώπινες παρεμβάσεις
* μειώνεται ο reviewer-induced drift στο ύφος του dataset
* παραμένει μεγαλύτερος ο όγκος καλών samples χωρίς άσκοπο rewording

## Πότε να κάνετε Edit

Επιλέξτε `Edit` όταν το record είναι χρήσιμο αλλά χρειάζεται διόρθωση για να είναι training-quality.

Τυπικές περιπτώσεις για `Edit`:

* η ερώτηση είναι σωστή ως ιδέα αλλά θέλει πιο καθαρή διατύπωση
* η ερώτηση είναι υπερβολικά ασαφής ή αμφίσημη
* η απάντηση είναι μερικώς σωστή αλλά ελλιπής
* η απάντηση είναι σωστή αλλά περιέχει μία μικρή μη τεκμηριωμένη προσθήκη
* υπάρχει ορθογραφικό ή γραμματικό πρόβλημα που επηρεάζει την ποιότητα του sample
* η ερώτηση και η απάντηση δεν ταιριάζουν ακριβώς μεταξύ τους, αλλά διορθώνονται εύκολα
* η διατύπωση είναι αφύσικη ή μη κατάλληλη για εκπαιδευτικό QA, αλλά το record σώζεται εύκολα

## Κανόνες όταν κάνετε Edit

* Αν αλλάζει μόνο η ερώτηση, συμπληρώστε μόνο το `corrected_question`.
* Αν αλλάζει μόνο η απάντηση, συμπληρώστε μόνο το `corrected_answer`.
* Αν αλλάζουν και τα δύο, συμπληρώστε και τα δύο.
* Αν αλλάξετε την ερώτηση, επιβεβαιώστε ότι η απάντηση εξακολουθεί να την απαντά σωστά.
* Αν αλλάξετε την απάντηση, επιβεβαιώστε ότι η ερώτηση εξακολουθεί να είναι η σωστή ερώτηση για την απάντηση αυτή.

Πολύ σημαντικό:

* Αν επιλέξετε `Edit` αλλά αφήσετε και τα δύο corrected fields κενά, στο export θα γίνει fallback στο αρχικό generated pair. Άρα το record θα μείνει ουσιαστικά αδιόρθωτο.

## Πότε να κάνετε Reject

Επιλέξτε `Reject` όταν το record δεν πρέπει να περάσει στο training set και δεν αξίζει να σωθεί με review edit.

Τυπικές περιπτώσεις για `Reject`:

* το `source_text` είναι τόσο θορυβώδες, κατεστραμμένο ή ελλιπές που δεν επιτρέπει αξιόπιστη ερώτηση-απάντηση
* η ερώτηση και η απάντηση είναι σοβαρά εκτός κειμένου
* η απάντηση περιέχει σοβαρή hallucination ή αντίφαση με το κείμενο
* το generated pair θα χρειαζόταν πλήρη αναδημιουργία και όχι απλή διόρθωση
* το κείμενο είναι τόσο fragmentary που δεν μπορεί να υποστηρίξει σαφές και χρήσιμο QA pair
* το record είναι άδειο, πρακτικά μη αξιοποιήσιμο ή προφανώς defective
* υπάρχει περιεχόμενο που δεν θα έπρεπε να χρησιμοποιηθεί για fine-tuning ακόμη και αν μπορούσε να διορθωθεί πρόχειρα

Πρακτικός κανόνας: αν δεν μπορείτε να υπερασπιστείτε το τελικό sample αποκλειστικά με βάση το `source_text`, μην το κρατήσετε.

## Γιατί να κάνετε Reject

Το `Reject` δεν είναι τιμωρία του μοντέλου. Είναι μηχανισμός ποιοτικού ελέγχου. Χρησιμοποιείται για να:

* απομακρυνθεί θόρυβος από το training set
* αποφευχθεί η εκπαίδευση του μοντέλου σε λάθος ή αβέβαια patterns
* προστατευτεί η αξιοπιστία του dataset
* μην ξοδεύεται reviewer time σε samples που δεν σώζονται αποδοτικά

## Πότε να προτιμήσετε Edit αντί για Reject

Προτιμήστε `Edit` όταν:

* η βασική ιδέα της ερώτησης είναι σωστή
* το κείμενο υποστηρίζει ξεκάθαρα ένα σωστό QA pair
* η διόρθωση είναι συγκεκριμένη και υπερασπίσιμη
* το sample χρειάζεται περιορισμένη ή μέτρια παρέμβαση, όχι πλήρη επανασχεδίαση

Προτιμήστε `Reject` όταν:

* δεν είστε βέβαιοι ποια θα ήταν η σωστή διόρθωση
* θα έπρεπε να ξαναγράψετε από την αρχή και την ερώτηση και την απάντηση
* το κείμενο δεν παρέχει σταθερή βάση για καλό sample

## Καλές πρακτικές για υψηλής ποιότητας review

* Να είστε αυστηροί με την πιστότητα στο κείμενο.
* Να είστε συντηρητικοί με εξωτερικές ερμηνείες.
* Να κάνετε τη μικρότερη δυνατή αλλαγή που φέρνει το record σε αποδεκτή ποιότητα.
* Να κρατάτε μία μόνο ερώτηση ανά record.
* Να προτιμάτε σαφείς και συγκεκριμένες ερωτήσεις αντί για αόριστες.
* Να προτιμάτε απαντήσεις πλήρεις αλλά όχι φλύαρες.
* Να αποφεύγετε άσκοπες επαναλήψεις του source text λέξη προς λέξη, εκτός αν αυτό είναι ο πιο καθαρός τρόπος να αποδοθεί σωστά η απάντηση.
* Να αποφεύγετε απαντήσεις που εισάγουν νέο περιεχόμενο που δεν τεκμηριώνεται στο κείμενο.
* Να κρατάτε συνέπεια σε παρόμοιες περιπτώσεις από record σε record.
* Να θυμάστε ότι ο στόχος είναι training usefulness, όχι λογοτεχνική τελειότητα.

## Καλές πρακτικές ειδικά για θορυβώδη ή OCR-like κείμενα

Σε αυτό το dataset είναι πιθανό να υπάρχουν κείμενα με OCR artifacts, παλιά τυπογραφικά σύμβολα, κομμένες φράσεις ή θόρυβο μορφοποίησης.

Σε αυτές τις περιπτώσεις:

* Αν το νόημα του κειμένου παραμένει σαφές, μπορείτε να κάνετε `Accept` ή `Edit`, ανάλογα με την ποιότητα του QA pair.
* Αν το νόημα είναι μόνο μερικώς σαφές, προτιμήστε `Edit` μόνο όταν η διόρθωση είναι βέβαιη.
* Αν το νόημα δεν είναι σαφές χωρίς εικασία, προτιμήστε `Reject`.
* Μην μαντεύετε ονόματα, αριθμούς, ημερομηνίες ή ορισμούς όταν το source text είναι αλλοιωμένο.

## Checklist για την ερώτηση

Πριν κάνετε submit, ελέγξτε αν η τελική ερώτηση:

* είναι μία και μόνο μία ερώτηση
* είναι σαφής και όχι διφορούμενη
* είναι απαντήσιμη από το `source_text`
* δεν απαιτεί εξωτερική γνώση
* δεν περιέχει μη τεκμηριωμένες παραδοχές
* είναι φυσική στα Ελληνικά

## Checklist για την απάντηση

Πριν κάνετε submit, ελέγξτε αν η τελική απάντηση:

* απαντά ακριβώς στην ερώτηση
* είναι σωστή με βάση το `source_text`
* δεν περιέχει hallucinated στοιχεία
* δεν παραλείπει κρίσιμη πληροφορία που χρειάζεται για να είναι πλήρης
* δεν είναι άσκοπα μακροσκελής
* είναι καθαρή και φυσική στα Ελληνικά

## Συνήθη λάθη που πρέπει να αποφεύγονται

* `Accept as-is` ενώ η απάντηση περιέχει μία λεπτομέρεια που δεν υπάρχει στο κείμενο.
* `Edit` μόνο και μόνο επειδή ο reviewer προτιμά διαφορετικό ύφος.
* `Edit` με κενά και τα δύο corrected fields.
* Αλλαγή της ερώτησης χωρίς έλεγχο ότι η απάντηση παραμένει σωστή.
* Αλλαγή της απάντησης χωρίς έλεγχο ότι εξακολουθεί να απαντά τη συγκεκριμένη ερώτηση.
* Χρήση εξωτερικής γνώσης για να διορθωθεί ένα record.
* `Reject` σε record που χρειαζόταν μόνο μικρή και καθαρή διόρθωση.

## Γρήγορος κανόνας απόφασης

* Αν το sample είναι ήδη σωστό και χρήσιμο, κάντε `Accept as-is`.
* Αν το sample σώζεται με σαφείς, περιορισμένες και τεκμηριωμένες αλλαγές, κάντε `Edit`.
* Αν το sample είναι αναξιόπιστο, αβέβαιο ή απαιτεί πλήρη αναδημιουργία, κάντε `Reject`.

## Παραδείγματα σκέψης

Παράδειγμα για `Accept as-is`:

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

Παράδειγμα για `Edit`:

* Η ερώτηση είναι καλή, αλλά η απάντηση προσθέτει μία λεπτομέρεια που δεν αναφέρεται ρητά στο κείμενο. Διορθώνετε μόνο το `corrected_answer`.

Παράδειγμα για `Reject`:

* Το `source_text` είναι τόσο αποσπασματικό ή θορυβώδες που δεν είστε βέβαιοι ποιο είναι το σωστό νόημα. Οποιαδήποτε διόρθωση θα απαιτούσε εικασία. Το record δεν πρέπει να περάσει στο training set.

## Τελικός έλεγχος πριν το submit

Πριν ολοκληρώσετε κάθε record, ελέγξτε τα εξής:

* Έχω επιλέξει το σωστό `review_action`.
* Αν έβαλα `Edit`, έχω συμπληρώσει τουλάχιστον ένα corrected field.
* Η τελική ερώτηση και η τελική απάντηση ταιριάζουν μεταξύ τους.
* Η τελική απάντηση στηρίζεται στο `source_text`.
* Δεν έχω κρατήσει πληροφορία που δεν μπορώ να υπερασπιστώ από το κείμενο.

## Αν υπάρχει αμφιβολία

Όταν έχετε αμφιβολία:

* μην κάνετε `Accept as-is` αν δεν είστε βέβαιοι για την τεκμηρίωση της απάντησης
* κάντε `Edit` μόνο αν ξέρετε ακριβώς ποια είναι η σωστή διόρθωση
* κάντε `Reject` όταν η αβεβαιότητα είναι δομική και όχι απλώς stylistic

Ο σωστός reviewer δεν προσπαθεί να “σώσει” κάθε sample. Προσπαθεί να διασφαλίσει ότι ό,τι μένει στο dataset είναι πραγματικά κατάλληλο για fine-tuning.

## Σωστά και λάθος παραδείγματα

Τα παρακάτω παραδείγματα είναι ενδεικτικά. Ο στόχος τους είναι να δείξουν όχι μόνο τι είναι σωστό, αλλά και ποιο είναι το συνηθισμένο λάθος reviewer decision σε κάθε περίπτωση.

### Παράδειγμα 1: Σωστό `Accept as-is`

`source_text`:

"Το νερό βράζει στους 100 βαθμούς Κελσίου σε κανονική ατμοσφαιρική πίεση."

`generated_question`:

"Σε ποια θερμοκρασία βράζει το νερό σε κανονική ατμοσφαιρική πίεση;"

`generated_answer`:

"Το νερό βράζει στους 100 βαθμούς Κελσίου σε κανονική ατμοσφαιρική πίεση."

Λάθος reviewer απόφαση:

* `Edit`, μόνο και μόνο για να αλλάξει τη διατύπωση σε κάτι πιο κομψό.

Σωστή reviewer απόφαση:

* `Accept as-is`

Γιατί:

* Η ερώτηση είναι σαφής.
* Η απάντηση είναι σωστή και πλήρως τεκμηριωμένη.
* Δεν υπάρχει κανένας ουσιαστικός λόγος παρέμβασης.

### Παράδειγμα 2: Λάθος `Accept as-is`, σωστό `Edit`

`source_text`:

"Η Αθήνα είναι η πρωτεύουσα της Ελλάδας."

`generated_question`:

"Ποια είναι η πρωτεύουσα της Ελλάδας;"

`generated_answer`:

"Η Αθήνα είναι η πρωτεύουσα της Ελλάδας και η μεγαλύτερη πόλη της χώρας."

Λάθος reviewer απόφαση:

* `Accept as-is`

Γιατί είναι λάθος:

* Το δεύτερο μισό της απάντησης δεν τεκμηριώνεται από το `source_text`.
* Ακόμη κι αν είναι αληθινό γενικά, εδώ είναι εξωτερική γνώση.

Σωστή reviewer απόφαση:

* `Edit`
* `corrected_answer`: "Η Αθήνα είναι η πρωτεύουσα της Ελλάδας."

Γιατί:

* Το sample σώζεται εύκολα.
* Η βασική ερώτηση είναι σωστή.
* Χρειάζεται μόνο αφαίρεση της μη τεκμηριωμένης προσθήκης.

### Παράδειγμα 3: Σωστό `Edit` μόνο στην ερώτηση

`source_text`:

"Ο ποιητής γεννήθηκε το 1911 στη Θεσσαλονίκη."

`generated_question`:

"Τι έγινε τότε;"

`generated_answer`:

"Ο ποιητής γεννήθηκε το 1911 στη Θεσσαλονίκη."

Λάθος reviewer απόφαση:

* `Accept as-is`

Γιατί είναι λάθος:

* Η ερώτηση είναι υπερβολικά ασαφής.
* Δεν είναι καλό training signal, παρότι η απάντηση είναι κοντά στο νόημα του κειμένου.

Σωστή reviewer απόφαση:

* `Edit`
* `corrected_question`: "Πότε και πού γεννήθηκε ο ποιητής;"

Γιατί:

* Η απάντηση ήδη καλύπτει σωστά την πληροφορία.
* Το πρόβλημα είναι μόνο η κακή ποιότητα της ερώτησης.

### Παράδειγμα 4: Σωστό `Edit` και στα δύο πεδία

`source_text`:

"Το μουσείο λειτουργεί από Τρίτη έως Κυριακή, από τις 09:00 έως τις 17:00."

`generated_question`:

"Πότε είναι ανοιχτό το μουσείο τη Δευτέρα;"

`generated_answer`:

"Το μουσείο είναι ανοιχτό από τις 09:00 έως τις 17:00."

Λάθος reviewer απόφαση:

* `Accept as-is`

Γιατί είναι λάθος:

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

Σωστή reviewer απόφαση:

* `Edit`
* `corrected_question`: "Ποιες ημέρες και ώρες λειτουργεί το μουσείο;"
* `corrected_answer`: "Το μουσείο λειτουργεί από Τρίτη έως Κυριακή, από τις 09:00 έως τις 17:00."

Γιατί:

* Το record μπορεί να σωθεί.
* Χρειάζεται ευθυγράμμιση και της ερώτησης και της απάντησης με το `source_text`.

### Παράδειγμα 5: Σωστό `Reject`

`source_text`:

"...Μακρ… 1821 … σχολ… αγών… πρόσωπ..."

`generated_question`:

"Ποιος ήταν ο βασικός στόχος του σχολείου κατά την Επανάσταση του 1821;"

`generated_answer`:

"Ο βασικός στόχος ήταν η εθνική αφύπνιση των μαθητών."

Λάθος reviewer απόφαση:

* `Edit`, προσπαθώντας να ξαναγράψετε από την αρχή ένα πιθανό σωστό pair.

Γιατί είναι λάθος:

* Το `source_text` είναι υπερβολικά θορυβώδες και αποσπασματικό.
* Δεν υπάρχει ασφαλής βάση για τεκμηριωμένη ερώτηση και απάντηση.

Σωστή reviewer απόφαση:

* `Reject`

Γιατί:

* Οποιαδήποτε διόρθωση θα βασιζόταν σε εικασία.
* Το sample δεν είναι αξιόπιστο για fine-tuning.

### Παράδειγμα 6: Λάθος `Reject`, σωστό `Edit`

`source_text`:

"Ο ήρωας επιστρέφει στο χωριό του μετά από δέκα χρόνια απουσίας."

`generated_question`:

"Μετά από πόσα χρόνια επιστρέφει ο ήρωας στο χωριό του;"

`generated_answer`:

"Ο ήρωας επιστρέφει στο χωριό του μετά από πολλά χρόνια."

Λάθος reviewer απόφαση:

* `Reject`

Γιατί είναι λάθος:

* Το sample δεν είναι κατεστραμμένο.
* Η σωστή πληροφορία υπάρχει καθαρά στο κείμενο.
* Χρειάζεται μόνο μικρή διόρθωση στην απάντηση.

Σωστή reviewer απόφαση:

* `Edit`
* `corrected_answer`: "Ο ήρωας επιστρέφει στο χωριό του μετά από δέκα χρόνια απουσίας."

Γιατί:

* Το record είναι πλήρως αξιοποιήσιμο μετά από απλή, σαφή διόρθωση.

---
© 2026 [glossAPI](https://glossapi.gr/) — GFOSS