Οδηγός GraphRAG: Πότε οι γράφοι γνώσης κερδίζουν το διανυσματικό RAG (και πότε όχι)

Οδηγός GraphRAG: Πότε οι γράφοι γνώσης κερδίζουν το διανυσματικό RAG (και πότε όχι)

Το GraphRAG δεν πέθανε, αλλά δεν είναι πια η προεπιλογή. Το microsoft/graphrag κυκλοφόρησε την v3.1.1 στις 2026-07-18 με 35.088 αστέρια στο GitHub και τρία papers benchmark του 2026 αναφέρουν πλέον ανοιχτά ότι χάνει συχνά από την απλή διανυσματική ανάκτηση. Έτσι, αυτός ο οδηγός GraphRAG απαντά στο μοναδικό ερώτημα που απομένει: αξίζει ένας γράφος γνώσης το κόστος ευρετηρίασης;

Να χρησιμοποιήσετε το GraphRAG; Η σύντομη απάντηση

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

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

Η σύντομη εκδοχή:

• Το GraphRAG κερδίζει στις ερωτήσεις πολλαπλών βημάτων και σε όλο το σώμα· το απλό RAG κερδίζει στις αναζητήσεις ενός βήματος.
• Τα benchmark του 2026 είναι αντικρουόμενα: οι γράφοι βοηθούν στη συνάθροιση, αλλά μπορούν να βλάψουν τη λεπτομερή περίληψη.
• Το κόστος εμφανίζεται κατά την ευρετηρίαση, στις κλήσεις εξαγωγής του LLM, όχι κατά τον χρόνο ερωτήματος.
• Τρέξτε το Basic Search ως σημείο ελέγχου στο δικό σας σώμα κειμένων πριν χτίσετε οτιδήποτε.

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

Τι είναι πραγματικά το GraphRAG: Από τμήματα σε κοινότητες

Το GraphRAG είναι επαυξημένη δημιουργία με ανάκτηση (retrieval-augmented generation) πάνω σε έναν γράφο γνώσης αντί για αποσυνδεδεμένα τμήματα. Κατά την ευρετηρίαση, ένα LLM εξάγει οντότητες και σχέσεις από τα έγγραφά σας, ο αλγόριθμος Leiden ομαδοποιεί αυτές τις οντότητες σε κοινότητες και κάθε κοινότητα αποκτά μια περίληψη. Κατά τον χρόνο ερωτήματος, ο γράφος μαζί με αυτές τις περιλήψεις απαντούν σε ερωτήσεις που ένα παράθυρο top_k πάνω από τμήματα δεν μπορεί δομικά να απαντήσει.

Το pipeline, από άκρη σε άκρη:

Documents
  |
  v
Chunks --> LLM entity + relationship extraction
  |
  v
Knowledge graph (entities = nodes, relations = edges)
  |
  v
Leiden community detection --> community summaries
  |
  v
Vector index over entity + community descriptions

Δύο φάσεις κάνουν τη δουλειά. Η φάση ευρετηρίασης είναι η ακριβή: κάθε τμήμα κοστίζει μια κλήση LLM για την εξαγωγή οντοτήτων και σχέσεων, και οι περιλήψεις κοινοτήτων κοστίζουν επιπλέον κλήσεις από πάνω. Η φάση ερωτήματος είναι εκεί που φαίνεται η απόσβεση. Επειδή ο γράφος αποθηκεύει τις σχέσεις ρητά, μια ερώτηση όπως «σε ποιους προμηθευτές πουλάει επίσης ο μεγαλύτερος πελάτης μας;» γίνεται μια διάσχιση, αντί για μια ελπίδα ότι τα δύο σωστά τμήματα θα πέσουν στο ίδιο παράθυρο top_k.

Οι περιλήψεις έχουν σημασία επειδή είναι αυτό που διαβάζει πραγματικά το Global Search: ερωτήσεις που αφορούν όλο το σώμα απαντώνται από προγραμμένες περιλήψεις κοινοτήτων, όχι από ακατέργαστα τμήματα. Και κάθε ακμή είναι μια κρίση του LLM, αποθηκευμένη ως τριάδα που θα μπορούσατε να ερωτήσετε σε Cypher σε μια πραγματική βάση δεδομένων γράφων. Αυτός ο σχεδιασμός εξηγεί επίσης γιατί η ευρετηρίαση κυριαρχεί στο κόστος, κάτι που τα παρακάτω νούμερα κάνουν συγκεκριμένο.

Η διατύπωση που αξίζει τη θέση της: το απλό RAG ανακτά αποσπάσματα, και το GraphRAG ανακτά δομή. Η επιλογή του μοντέλου ενσωμάτωσης εξακολουθεί να μετράει για το διανυσματικό επίπεδο, και η βάση διανυσμάτων εξακολουθεί να αποθηκεύει τις περιγραφές, αλλά ο γράφος είναι το νέο κομμάτι που σηκώνει το βάρος. Η επίσημη τεκμηρίωση Index Overview περιγράφει κάθε στάδιο πλήρως.

Ποιες είναι οι τέσσερις μέθοδοι ερωτημάτων του GraphRAG;

Η μηχανή ερωτημάτων του GraphRAG περιλαμβάνει τέσσερις μεθόδους: Local Search, Global Search, DRIFT Search και Basic Search. Το Local Search συλλογίζεται προς τα έξω από συγκεκριμένες οντότητες, το Global Search κάνει συνάθροιση περιλήψεων κοινοτήτων σε όλο το σώμα, το DRIFT Search αναμειγνύει τα δύο αναδρομικά και το Basic Search είναι μια απλή διανυσματική γραμμή βάσης. Μια πέμπτη λειτουργία, η δημιουργία ερωτήσεων (Question Generation), κάθεται πάνω από τη μηχανή, όχι δίπλα της.

Ελέγξαμε τη ζωντανή τεκμηρίωση στο microsoft.github.io/graphrag/query/overview/ στις 2026-07-30 και το πλήθος είναι τέσσερις. Οι περισσότεροι οδηγοί κατάταξης αναφέρουν δύο ή τρεις. Ο ίδιος έλεγχος βρήκε τη λέξη «lazy» μηδέν φορές τόσο στις σελίδες επισκόπησης Index όσο και Query, κάτι που μετράει για την ενότητα κόστους παρακάτω.

Η γραμμή που αξίζει την προσοχή σας είναι η τελευταία. Το Basic Search είναι η ενσωματωμένη απλή διανυσματική γραμμή βάσης και υπάρχει για να μπορείτε να κάνετε A/B τον γράφο εναντίον της απλής ανάκτησης στο δικό σας σώμα κειμένων και να ανακαλύψετε αν ο γράφος αξίζει το κόστος του. Αυτό δεν είναι λεπτομέρεια· είναι ολόκληρη η διαδικασία απόφασης αυτού του οδηγού σε μία λειτουργία. Τρέξτε πρώτα το Basic Search. Αν το Local, το Global ή το DRIFT search δεν το νικά στις ερωτήσεις που πραγματικά δέχεστε, ο γράφος είναι κόστος, όχι αναβάθμιση.

Τι βρήκαν πραγματικά τα benchmark του 2026;

Τρία papers benchmark του 2026 διαπιστώνουν ότι το GraphRAG βοηθά σε εργασίες συνάθροισης πολλαπλών βημάτων και πολλαπλών γεγονότων, αλλά συχνά υπολείπεται του απλού RAG αλλού. Ένα από αυτά φτιάχνει ένα benchmark ειδικά για να βρει πού χάνουν οι γράφοι. Και τα τρία συμφωνούν ότι η νίκη εξαρτάται από τον τύπο ερώτησης, όχι από το μέγεθος του σώματος. Τα τεκμήρια λένε ότι το GraphRAG είναι καθαρά θέμα περίστασης, όχι προεπιλογή.

Μια τέταρτη προσπάθεια, το GraphRAG-Bench (αποθετήριο), αξιολογεί εννέα μεθόδους GraphRAG σε 16 κλάδους και 20 εγχειρίδια, και καταλήγει στο ίδιο συμπέρασμα από ευρύτερη γωνία.

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

Η δική μας ανάγνωση: ο κύκλος hype έκανε τη ζημιά και αυτά τα papers είναι η διόρθωση. Κανένα τους δεν λέει ότι οι γράφοι είναι άχρηστοι. Αυτό που λένε, σταθερά, είναι ότι το βήμα συνάθροισης που κάνει το GraphRAG καλό στα θέματα ολόκληρου του σώματος είναι το ίδιο βήμα που θολώνει τις λεπτομέρειες. Το WildGraphBench είναι το πιο καθαρό παράδειγμα: οι γράφοι βοήθησαν τη συνάθροιση πολλαπλών γεγονότων από μέτριο αριθμό πηγών και έβλαψαν την ακρίβεια περίληψης στην ίδια αξιολόγηση. Αυτό δεν είναι αντίφαση· είναι ένας μηχανισμός που εμφανίζεται δύο φορές.

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

Πόσο κοστίζει το GraphRAG; (Και η επιφύλαξη για το LazyGraphRAG που όλοι επαναλαμβάνουν λάθος)

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

Τα μόνα στέρεα δημόσια νούμερα προέρχονται από τη Microsoft Research. Στις 2024-11-25 η ομάδα ανέφερε ότι το κόστος ευρετηρίασης του LazyGraphRAG ήταν πανομοιότυπο με του διανυσματικού RAG και ίσο με το 0,1% του κόστους του πλήρους GraphRAG, και ότι με 4% του κόστους ερωτήματος του global search του GraphRAG ξεπέρασε τις ανταγωνιστικές μεθόδους που δοκιμάστηκαν, τόσο σε τοπικούς όσο και σε παγκόσμιους τύπους ερωτημάτων (Microsoft Research). Αυτά είναι τα νούμερα της Microsoft, από το blog της Microsoft, και τα αναφέρουμε ως τέτοια· δεν έχουμε τρέξει οι ίδιοι ευρετηρίαση με τιμολόγηση.

Ορίστε η διόρθωση που χάνουν τα περισσότερα άρθρα. Το LazyGraphRAG δεν είναι επιλογή pip install. Σύμφωνα με τη δική της σημείωση συντάκτη της Microsoft στις 2025-06-06, κυκλοφόρησε στο Microsoft Discovery και στο Azure Local, όχι στο πακέτο ανοιχτού κώδικα. Ελέγξαμε τις επίσημες σελίδες Index Overview και Query Overview στις 2026-07-30: η λέξη «lazy» εμφανίζεται μηδέν φορές και στις δύο. Άρα αν ένας οδηγός παραθέτει το LazyGraphRAG ως παραλλαγή που μπορείτε να σηκώσετε σήμερα το απόγευμα, επαναλαμβάνει έναν ισχυρισμό που σταμάτησε να ισχύει στον κόσμο του ανοιχτού κώδικα.

Τι μπορείτε να κάνετε σήμερα: τρέξτε το μοντέλο εξαγωγής τοπικά. Αν στρέψετε το βήμα ευρετηρίασης σε ένα τοπικό μοντέλο μέσω Ollama, αφαιρείτε τα τέλη API ανά token από την ακριβότερη φάση, και αν το συνδυάσετε με μια ιδιόκτητη αποθήκη διανυσμάτων κρατάτε το υπόλοιπο του λογαριασμού κοντά στο μηδέν.

Ποια βιβλιοθήκη GraphRAG συντηρείται πραγματικά;

Δύο από τις έξι πιο αναφερόμενες βιβλιοθήκες GraphRAG δεν έχουν δεχτεί push εδώ και έξι και εννέα μήνες. Αντλήσαμε αυτά τα στοιχεία από το GitHub API στις 2026-07-30, και η παρακάτω απογραφή είναι ο έλεγχος που τα παλαιότερα αφιερώματα παραλείπουν, μαζί με την εντολή για να τον ξανατρέξετε πριν δεσμευτείτε σε μία. Το LightRAG και το microsoft/graphrag είναι οι ενεργές· το nano-graphrag και το fast-graphrag ολισθαίνουν προς την εγκατάλειψη.

for r in HKUDS/LightRAG microsoft/graphrag getzep/graphiti neo4j/neo4j-graphrag-python gusye1234/nano-graphrag circlemind-ai/fast-graphrag; do gh api "repos/$r" --jq '.full_name,.stargazers_count,.pushed_at,.open_issues_count'; done

Η δική μας ανάγνωση: τα αστέρια είναι ματαιόδοξη μετρική· η ημερομηνία push είναι το νούμερο που μετράει. Το LightRAG και το microsoft/graphrag συντηρούνται και τα δύο ενεργά, με το Graphiti να ακολουθεί από κοντά με τη γωνία του χρονικού γράφου. Το nano-graphrag και το fast-graphrag είναι τα δύο που παλαιότερα άρθρα εξακολουθούν να προτείνουν με βάση τη φήμη τους μόνο, και κανένα από τα δύο δεν έχει κυκλοφορήσει κάτι εδώ από μισό χρόνο.

Πώς να διαλέξετε: επιλέξτε microsoft/graphrag αν θέλετε την υλοποίηση αναφοράς με τις τέσσερις επίσημες μεθόδους ερωτημάτων, LightRAG αν θέλετε το πιο ενεργό έργο και ελαφρύτερο αποτύπωμα, και μια βιβλιοθήκη συντηρούμενη από πάροχο όπως η neo4j-graphrag-python αν τρέχετε ήδη τη βάση δεδομένων αυτού του παρόχου. Αποφύγετε οτιδήποτε έχει τελευταίο push παλαιότερο από μισό χρόνο πριν από το έργο σας.

Το Graphiti αξίζει μία στοχευμένη σημείωση: ο σχεδιασμός χρονικού γράφου του είναι φτιαγμένος για ανάκτηση πάνω σε δεδομένα με επίγνωση χρόνου, και επικαλύπτεται με τη μνήμη πρακτόρων, την οποία καλύπτουμε ξεχωριστά στον οδηγό μας για το Graphiti και τη χρονική μνήμη γράφων. Για το ευρύτερο πεδίο, δείτε το ευρύτερο τοπίο εργαλείων RAG.

Τι σπάει μετά την ημέρα 200: Παρέκκλιση γράφου και επανεξαγωγή

Η παρέκκλιση γράφου (graph drift) είναι ο φόρος που πληρώνετε μετά την κυκλοφορία, και είναι η νούμερο ένα ένσταση των ασκούμενων για λόγο. Κάθε σεμινάριο αντιμετωπίζει τον γράφο ως κάτι που χτίζεις μία φορά. Οι πραγματικές ομάδες κολλάνε την ημέρα 200.

Τρία πράγματα φθείρονται. Πρώτον, η επαναευρετηρίαση στις ενημερώσεις εγγράφων. Όταν αλλάζουν 40 έγγραφα, δεν μπορείτε απλά να τα ξαναενσωματώσετε· πρέπει να ξανατρέξετε την εξαγωγή LLM στα αλλαγμένα τμήματα, να συμφιλιώσετε τις νέες οντότητες με τον παλιό γράφο και να ξαναυπολογίσετε τις επηρεασμένες κοινότητες και τις περιλήψεις τους. Ένας οδηγός στο Medium αποκαλεί εύκολη την αυξητική ενημέρωση. Οι ασκούμενοι στο r/Rag διαφωνούν. Ο συντάκτης ενός νήματος της 2026-04-25 που τρέχει BM25 συν BGE-M3 σε περίπου 600 έγγραφα το έθεσε καθαρά: «Η εξαγωγή οντοτήτων/σχέσεων με LLM είναι θορυβώδης και η επαναευρετηρίαση στις ενημερώσεις εγγράφων φαίνεται επώδυνη.»

Δεύτερον, η φθορά της ταυτοποίησης οντοτήτων. Οι «Acme Corp», «Acme» και «ACME Corporation» φτάνουν σε διαφορετικά έγγραφα μήνες μεταξύ τους και σπάνε σε τρεις κόμβους που θα έπρεπε να είναι ένας. Τίποτα δεν τα συγχωνεύει αυτόματα.

Τρίτον, σχέσεις που ίσχυαν κατά την εξαγωγή και σταμάτησαν σιωπηλά να ισχύουν. Κανείς δεν παίρνει ειδοποίηση όταν μια ακμή reports_to μπαγιατεύει.

def on_documents_changed(changed_docs):
    stale = find_affected_nodes(changed_docs)
    re_extract(changed_docs)
    reconcile_entities(stale)
    recompute_communities(affected_only=True)
    re_summarize(affected_communities)

Μια βάση κώδικα είναι η χειρότερη περίπτωση, και η πιο ενδιαφέρουσα. Η αυτόματη συμπλήρωση πλέον προτείνει «graphrag for codebase», «graphrag claude code» και «graphrag mcp server», και μια βάση κώδικα είναι ένας γράφος που αλλάζει κάθε ώρα: κάθε commit ξαναγράφει ακμές κλήσεων, μετακινεί σύμβολα και διαγράφει συναρτήσεις. Αυτή είναι παρέκκλιση γράφου με πρόγραμμα που καμία νυχτερινή επαναευρετηρίαση δεν μπορεί να παρακολουθήσει πλήρως. Είναι επίσης ο λόγος που τα σοβαρά εργαλεία γράφων κώδικα στηρίζονται σε ντετερμινιστικούς parsers όπως το tree-sitter και το LSP για τις ακμές και κρατούν το LLM για το κείμενο γύρω τους: docstrings, μηνύματα commit, νήματα αξιολόγησης. Αν φτιάχνετε γράφο ενός αποθετηρίου, γραφώστε το αργά κινούμενο επίπεδο με το LLM και το γρήγορα κινούμενο με έναν parser.

Τι λένε πραγματικά οι προγραμματιστές για το GraphRAG;

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

Ο σκεπτικισμός είναι πραγματικός. Στο νήμα του r/Rag το 2024 «Would you always recommend (knowledge) graph RAG over normal RAG?» (10 πόντοι, 86% θετικοί), ο u/EncartaIt έγραψε: «Όλα τα σεμινάρια που βρήκα είναι υπερβολικά απλουστευτικά και δεν κάνουν πραγματικά ισχυρή περίπτωση για το μοτίβο του γράφου γνώσης.» Ο u/Prestigious_Run_4049 ήταν πιο κοφτός: «Νομίζω ότι το graph rag είναι απλά hype. Ο κόσμος λατρεύει να μιλάει γι' αυτό και ακούγεται κουλ, αλλά κανείς δεν το χρησιμοποιεί πραγματικά σε πραγματικές περιπτώσεις χρήσης.» Δεν συμφωνούν όλοι. Ο u/pytheryx, μιλώντας από την παραγωγή, σημείωσε ότι η ανάκτηση γράφου κερδίζει σε ερωτήσεις τύπου λίστας που χρειάζονται συμφραζόμενα από περισσότερα τμήματα από όσα επιστρέφει το top_k· το σώμα λευκών βίβλων του χρειάζεται περίπου 50 τμήματα για μια πλήρη απάντηση.

Το νήμα του 2026 είναι πιο μετρημένο. Ο u/Popular_Sand2773: «Οι περισσότερες εγκαταστάσεις graph rag απλά κλέβουν στην κλίμακα. Τρέχεις μια τυπική διανυσματική αναζήτηση ή αναζήτηση μεταδεδομένων για να βρεις σπόρους κόμβων και μετά περπατάς τριγύρω.» Ο u/ggone20, που τρέχει ένα σύστημα περίπου 300 εκατομμυρίων αντικειμένων: «Σε κλίμακα κυριολεκτικά δεν μπορείς να ζήσεις χωρίς αυτά για να απαντήσεις πραγματικές ερωτήσεις.»

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

Πώς το προσεγγίζει η Techsy

Ορίστε η αλληλουχία που χρησιμοποιούμε σε έργα πελατών, και είναι σκόπιμα βαρετή.

Πρώτον, αποδείξτε το ταβάνι της υβριδικής ανάκτησης. Τα περισσότερα αιτήματα «χρειαζόμαστε γράφο» που ακούμε είναι στην πραγματικότητα ένα πρόβλημα τεμαχισμού ή αναδιάταξης μεταμφιεσμένο. Ένα pipeline BM25 συν διανύσματα με έναν αξιοπρεπή αναδιατάκτη (reranker) απαντά περισσότερα από όσα περιμένουν οι ομάδες.

Δεύτερον, τρέξτε το Basic Search ως σημείο ελέγχου στο δικό σας σώμα κειμένων πριν χτίσετε οτιδήποτε. Για αυτό ακριβώς υπάρχει η τέταρτη μέθοδος ερωτημάτων: μια απλή διανυσματική γραμμή βάσης για να κάνετε A/B τον γράφο, στα δικά σας δεδομένα, με τις δικές σας ερωτήσεις.

Τρίτον, χτίστε τον γράφο μόνο όταν μια μετρημένη κλάση ερωτήσεων αποτυγχάνει σε αυτόν τον έλεγχο. Αν τα ερωτήματα πολλαπλών βημάτων ή ολόκληρου του σώματος αστοχούν, έχετε πραγματική περίπτωση. Αν όχι, μόλις γλιτώσατε τον λογαριασμό ευρετηρίασης και ένα πρόβλημα παρέκκλισης.

Θέλετε ένα δεύτερο ζευγάρι μάτια στη στοίβα ανάκτησής σας; Πάρτε μια δωρεάν συμβουλευτική.

Σχετικά με τον συγγραφέα

Ο Mert Batur είναι συνιδρυτής του Techsy.io, όπου η ομάδα παραδίδει πράκτορες AI, συστήματα αυτοματισμού και pipelines φωνής/SDR για πελάτες B2B. Γράφει για τη στοίβα εργαλείων LLM που η ομάδα της Techsy χρησιμοποιεί πραγματικά στην παραγωγή. Σε έργα πελατών παίρνει τις αποφάσεις αρχιτεκτονικής ανάκτησης: πότε η υβριδική αναζήτηση αρκεί και πότε ένα σώμα κειμένων χρειάζεται πραγματικά γράφο. Συνδεθείτε μαζί του στο LinkedIn.

Συχνές Ερωτήσεις

Πώς λειτουργεί το GraphRAG;

Το GraphRAG ευρετηριάζει τα έγγραφά σας σε έναν γράφο γνώσης. Ένα LLM εξάγει οντότητες και σχέσεις από κάθε τμήμα, ο αλγόριθμος Leiden ομαδοποιεί αυτές τις οντότητες σε κοινότητες και κάθε κοινότητα αποκτά μια περίληψη. Κατά τον χρόνο ερωτήματος, η μηχανή ψάχνει τον γράφο και αυτές τις περιλήψεις, ώστε να μπορεί να συνδέσει γεγονότα που βρίσκονται σε διαφορετικά τμήματα.

Πώς διαφέρει το GraphRAG από το RAG;

Το τυπικό RAG ανακτά τα top-k πιο όμοια τμήματα και τα δίνει στο μοντέλο. Το GraphRAG ανακτά δομή: οντότητες, τις σχέσεις μεταξύ τους και προγραμμένες περιλήψεις κοινοτήτων. Αυτή η επιπλέον δομή είναι που του επιτρέπει να απαντά ερωτήσεις πολλαπλών βημάτων και ερωτήσεις ολόκληρου του σώματος, και είναι επίσης αυτό που κάνει την ευρετηρίαση πιο αργή και πιο ακριβή.

Πότε πρέπει να χρησιμοποιήσω το GraphRAG;

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

Το GraphRAG πέθανε;

Όχι, αλλά δεν είναι ούτε η προεπιλογή. Τα benchmark του 2026 δείχνουν ότι συχνά υπολείπεται του απλού RAG σε καθημερινές εργασίες, κάτι που σκότωσε το hype, ενώ εξακολουθεί να κερδίζει στις ερωτήσεις πολλαπλών βημάτων και συνάθροισης. Η ειλικρινής διατύπωση είναι θέμα περίστασης: το GraphRAG κερδίζει το κόστος του για τους σωστούς τύπους ερωτήσεων και χάνει χρήματα για τους υπόλοιπους.

Ποιες είναι οι μέθοδοι ερωτημάτων του GraphRAG;

Η επίσημη μηχανή ερωτημάτων περιλαμβάνει τέσσερις: Local Search για ερωτήσεις γύρω από οντότητες, Global Search για συνάθροιση σε όλο το σώμα, DRIFT Search για μια αναδρομική ανάμειξη και των δύο, και Basic Search για απλή διανυσματική ανάκτηση. Μια πέμπτη λειτουργία, η δημιουργία ερωτήσεων, κάθεται από πάνω. Το Basic Search μετράει περισσότερο: είναι το σημείο ελέγχου για το A/B με τον γράφο.

Πόσο κοστίζει η ευρετηρίαση του GraphRAG;

Το κόστος εμφανίζεται κατά την ευρετηρίαση, στις κλήσεις LLM που εξάγουν οντότητες και σχέσεις από κάθε τμήμα μαζί με την περίληψη κοινοτήτων. Η Microsoft Research ανέφερε ευρετηρίαση LazyGraphRAG στο 0,1% του κόστους του πλήρους GraphRAG και πανομοιότυπη με το διανυσματικό RAG, αλλά αυτή η παραλλαγή κυκλοφόρησε σε προϊόντα της Microsoft, όχι στη βιβλιοθήκη ανοιχτού κώδικα. Δεν έχουμε τρέξει οι ίδιοι ευρετηρίαση με τιμολόγηση.

Μπορώ να τρέξω το GraphRAG τοπικά με το Ollama;

Ναι. Η βιβλιοθήκη microsoft/graphrag σάς επιτρέπει να στρέψετε την ευρετηρίαση και τα ερωτήματα σε ένα τοπικό μοντέλο που σερβίρει το Ollama, κάτι που αφαιρεί τα τέλη API ανά token από το βήμα εξαγωγής. Ανταλλάσσετε ταχύτητα και ποιότητα με κόστος: τα τοπικά μοντέλα είναι πιο αδύναμα στην εξαγωγή οντοτήτων, οπότε περιμένετε πιο θορυβώδεις γράφους και μεγαλύτερους χρόνους ευρετηρίασης σε μέτριο υλισμικό.

Τι είναι καλύτερο: LightRAG ή Microsoft GraphRAG;

Βελτιστοποιούν για διαφορετικά πράγματα. Το LightRAG (38.353 αστέρια, push 2026-07-30) είναι το πιο ενεργό και ελαφρύτερο στη λειτουργία· το microsoft/graphrag (35.088 αστέρια, v3.1.1) είναι η υλοποίηση αναφοράς με τις τέσσερις επίσημες μεθόδους ερωτημάτων. Επιλέξτε LightRAG για έναν αποδοτικό γράφο παραγωγής, της Microsoft για συμπεριφορά πιστή στις προδιαγραφές και τον έλεγχο Basic Search.

Ποιος δημιούργησε το GraphRAG και πότε;

Η Microsoft Research δημιούργησε το GraphRAG. Η ομάδα δημοσίευσε το paper το 2024 και συντηρεί το αποθετήριο ανοιχτού κώδικα microsoft/graphrag υπό την άδεια MIT, με τεκμηρίωση στο microsoft.github.io/graphrag. Η βιβλιοθήκη αναφοράς έφτασε την v3.1.1 στις 2026-07-18, και ένα ενεργό οικοσύστημα υλοποιήσεων τρίτων, συμπεριλαμβανομένων των LightRAG και Graphiti, έχει αναπτυχθεί γύρω της.

Η ετυμηγορία: Πότε ένας γράφος αξίζει το κόστος του

Τα τεκμήρια δείχνουν προς μία κατεύθυνση, οπότε ορίστε η θέση.

• Το GraphRAG δεν πέθανε. Είναι θέμα περίστασης, και τα benchmark του 2026 το λένε ανοιχτά.
• Κερδίζει το κόστος ευρετηρίασης στις ερωτήσεις οντοτήτων πολλαπλών βημάτων και στη συνάθροιση ολόκληρου του σώματος. Χάνει χρήματα στις αναζητήσεις ενός βήματος.
• Το κόστος είναι λογαριασμός ευρετηρίασης, και η φθηνή παραλλαγή που όλοι παραθέτουν, το LazyGraphRAG, δεν έφτασε ποτέ στη βιβλιοθήκη ανοιχτού κώδικα.
• Ο γράφος φθείρεται μετά την κυκλοφορία: η ταυτοποίηση οντοτήτων παρεκκλίνει και οι σχέσεις μπαγιατεύουν, οπότε προϋπολογίστε επαναευρετηρίαση.
• Τρέξτε το Basic Search ως σημείο ελέγχου στο δικό σας σώμα κειμένων πριν χτίσετε οτιδήποτε.

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