RAG από το Μηδέν: Pinecone vs Weaviate vs pgvector

Εισαγωγή: Γιατί το RAG άλλαξε τα πάντα

Το 2023 και το 2024, τα Μεγάλα Γλωσσικά Μοντέλα (LLMs) πέρασαν από ένα απλό tech demo σε κρίσιμο επιχειρηματικό εργαλείο. Όμως, μαζί με τις εντυπωσιακές τους ικανότητες, ήρθε και η συνειδητοποίηση ενός θεμελιώδους προβλήματος: τα LLMs παράγουν ψευδείς πληροφορίες με τρομακτική αυτοπεποίθηση. Αυτό το φαινόμενο, γνωστό ως hallucination, αποτελεί το μεγαλύτερο εμπόδιο για την υιοθέτηση της τεχνητής νοημοσύνης σε κρίσιμους τομείς όπως η νομική πληροφόρηση, η ιατρική διάγνωση και η χρηματοοικονομική ανάλυση.

Εδώ εισέρχεται το Retrieval Augmented Generation (RAG). Αντί να βασιζόμαστε αποκλειστικά στη στατική γνώση που έχει ενσωματωθεί στα βάρη του μοντέλου κατά την εκπαίδευση, το RAG επιτρέπει στο LLM να ανακαλεί δυναμικά πληροφορίες από εξωτερικές πηγές δεδομένων. Το αποτέλεσμα είναι απαντήσεις που είναι εξίσου ευφυείς αλλά επιπλέον επαληθεύσιμες, τρέχουσες και προσαρμοσμένες στα δικά σας ιδιωτικά δεδομένα.

Η καρδιά κάθε αρχιτεκτονικής RAG, ωστόσο, δεν βρίσκεται στο ίδιο το LLM. Βρίσκεται στη βάση δεδομένων διανυσμάτων — τον μηχανισμό αναζήτησης που καθορίζει αν θα βρούμε το σωστό έγγραφο σε χιλιοστά του δευτερολέπτου ή αν το σύστημα θα πνιγεί κάτω από το βάρος των δεδομένων σας. Σε αυτόν τον οδηγό, θα εξετάσουμε σε βάθος τις τρεις κορυφαίες λύσεις της αγοράς: το Pinecone, το Weaviate και το pgvector. Δεν θα μείνουμε στην επιφάνεια. Θα μπούμε στα θεμέλια της αρχιτεκτονικής, θα συγκρίνουμε αλγορίθμους ευρετηρίασης, θα αναλύσουμε οικονομικά μοντέλα και θα χτίσουμε πλήρες pipelines με πραγματικό κώδικα.

Κεφάλαιο 1: Τα Μαθηματικά Πίσω από τα Embeddings

Πριν μπούμε σε συγκρίσεις προϊόντων, πρέπει να κατανοήσουμε την υπολογιστική γεωμετρία που καθιστά δυνατή την αναζήτηση διανυσμάτων. Κάθε κομμάτι κειμένου, εικόνας, ή ήχου μετατρέπεται από ένα μοντέλο embedding σε έναν διάνυσμα σε έναν υψηλοδιάστατο χώρο. Για παράδειγμα, το text-embedding-3-large της OpenAI παράγει διανύσματα 3,076 διαστάσεων, ενώ τα μοντέλα της Cohere ή της Google μπορεί να φτάσουν έως και 4,096 διαστάσεις.

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

Το αποτέλεσμα κυμαίνεται μεταξύ $$-1$$ και $$1$$. Στην πράξη, για embeddings κειμένου, σχεδόν πάντα λαμβάνουμε θετικές τιμές, με τα πιο σχετικά αποτελέσματα να πλησιάζουν το $$1.0$$. Άλλες μετρικές απόστασης περιλαμβάνουν την ευκλείδεια απόσταση ($$L2$$) και την απόσταση Manhattan ($$L1$$), αν και για κανονικοποιημένα embeddings (όπου $$\|\mathbf{A}\| = 1$$), η ευκλείδεια απόσταση και η ομοιότητα συνημιτόνου είναι μονοσήμαντα συσχετισμένες, καθιστώντας την επιλογή μεταξύ τους συχνά θέμα υλοποίησης παρά ακρίβειας.

Το Πρόβλημα της Κατάρασης της Διάστασης

Σε χώρους χαμηλών διαστάσεων (2D ή 3D), μπορούμε εύκολα να οπτικοποιήσουμε την εγγύτητα. Σε χώρους 3,000+ διαστάσεων, όμως, η ευκλείδεια γεωμετρία συμπεριφέρεται αντιδιintuitively. Η κατάρα της διάστασης (curse of dimensionality) σημαίνει ότι καθώς ο αριθμός διαστάσεων αυξάνεται, η απόσταση μεταξύ οποιωνδήποτε δύο σημείων τείνει να συγκλίνει. Μια brute force αναζήτηση που υπολογίζει την απόσταση προς κάθε διάνυσμα στη βάση δεδομένων γίνεται απαγορευτικά αργή όταν οι συλλογές φτάνουν τα εκατομμύρια ή δισεκατομμύρια εγγραφές.

Γι' αυτόν ακριβώς τον λόγο χρειαζόμαστε προσεγγιστικούς αλγορίθμους γειτονικής αναζήτησης (ANN - Approximate Nearest Neighbor). Αυτοί οι αλγόριθμοι θυσιάζουν μια μικρή ποσότητα ανακλησιμότητας (recall) — συνήθως κάτω από 1% — για να επιταχύνουν την αναζήτηση κατά αρκετες τάξεις μεγέθους.

Οι Τρεις Οικογένειες Αλγορίθμων ANN

Οι vector databases που συγκρίνουμε χρησιμοποιούν διαφορετικές προσεγγίσεις για την ευρετηρίαση:

1. Trees και Graph-based: Οι αλγόριθμοι HNSW (Hierarchical Navigable Small World) και NSG (Navigating Spreading-out Graph) κατασκευάζουν γράφους όπου κάθε κόμβος (διάνυσμα) συνδέεται με γειτονικούς κόμβους. Η αναζήτηση ξεκινά από έναν τυχαίο κόμβο και «πηδάει» σε όλο και κοντινότερους γείτονες. Το HNSW είναι ο πιο δημοφιλής αλγόριθμος το 2026, προσφέροντας εξαιρετικό συμβιβασμό μεταξύ ταχύτητας, ακρίβειας και κατανάλωσης μνήμης.
2. Hashing (LSH): Η Τοπικά Ευαίσθητη Κατακερματισμός (Locality Sensitive Hashing) χαρτογραφεί διανύσματα σε buckets χρησιμοποιώντας συναρτήσεις κατακερματισμού που διατηρούν την εγγύτητα. Δύο κοντινά διανύσματα έχουν υψηλή πιθανότητα να καταλήξουν στο ίδιο bucket. Είναι αρκετά αποδοτικό σε χώρο αλλά συνήθως προσφέρει χαμηλότερη ακρίβεια από τα γραφήματα.
3. Quantization: Προσεγγιστικές μέθοδοι όπως το Product Quantization (PQ) και το Scalar Quantization (SQ) συμπιέζουν τα διανύσματα σε αναπαραστάσεις χαμηλότερης ακρίβειας. Αυτό μειώνει δραματικά τη χρήση μνήμης και επιταχύνει τους υπολογισμούς απόστασης, αλλά εισάγει σφάλματα κβαντοποίησης.

Καθώς εξετάζουμε το Pinecone, το Weaviate και το pgvector, θα δούμε πώς κάθε πλατφόρμα εκμεταλλεύεται αυτούς τους αλγορίθμους με διαφορετικό τρόπο, ανάλογα με τη φιλοσοφία σχεδίασής της.

Κεφάλαιο 2: Τι είναι ένα Vector Database και τι το διαφοροποιεί;

Ένα vector database δεν είναι απλώς μια κλασική σχεσιακή βάση δεδομένων με μια στήλη που αποθηκεύει arrays. Η διαφορά είναι αρχιτεκτονική και λειτουργική. Ένα πραγματικό vector DB χρειάζεται:

• Εγγενή υποστήριξη ANN indexing: Η ευρετηρίαση πρέπει να είναι ενσωματωμένη στον μηχανισμό αποθήκευσης, όχι προστεθείσα ως afterthought.
• Hybrid search capabilities: Η δυνατότητα συνδυασμού vector similarity με παραδοσιακά φίλτρα (π.χ. WHERE status = 'active' AND category IN ('tech', 'science')) χωρίς να καταρρεύσει η απόδοση.
• Metadata filtering: Η αναζήτηση διανυσμάτων σπάνια γίνεται σε κενό. Συνήθως θέλουμε να περιορίσουμε την αναζήτηση σε ένα υποσύνολο δεδομένων βάσει επιχειρησιακών κανόνων.
• Scalability για writes: Η εισαγωγή νέων διανυσμάτων δεν πρέπει να απαιτεί πλήρη αναδόμηση του ευρετηρίου, ή τουλάχιστον όχι σε βαθμό που να διακόπτει την υπηρεσία.
• Multi-tenancy και απομόνωση: Σε SaaS εφαρμογές, κάθε πελάτης πρέπει να βλέπει μόνο τα δικά του δεδομένα.

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

Κεφάλαιο 3: Pinecone — Το Managed Βασίλειο

import pinecone
from openai import OpenAI

# Αρχικοποίηση
pc = pinecone.Pinecone(api_key="YOUR_API_KEY")
index = pc.Index("rag-docs")

# Δημιουργία embedding
client = OpenAI()
response = client.embeddings.create(
    input="Πώς λειτουργεί το RAG;",
    model="text-embedding-3-large"
)
embedding = response.data[0].embedding

# Αναζήτηση με metadata filtering
results = index.query(
    vector=embedding,
    top_k=5,
    namespace="tenant_42",
    filter={
        "category": {"$eq": "tutorial"},
        "published": {"$gte": 2024}
    },
    include_metadata=True
)

# Hybrid search
hybrid_results = index.query(
    vector=embedding,
    sparse_vector={
        "indices": [1024, 2048],
        "values": [0.5, 0.8]
    },
    top_k=5,
    namespace="tenant_42"
)

Κεφάλαιο 4: Weaviate — Το Vector-native Γράφημα

{
  Get {
    Article(
      hybrid: {
        query: "τεχνολογίες vector databases"
        alpha: 0.75
      }
      limit: 10
      where: {
        path: ["category"]
        operator: Equal
        valueText: "AI"
      }
    ) {
      title
      content
      _additional {
        distance
        score
        explainScore
      }
    }
  }
}

import weaviate
from weaviate.classes.config import Configure, Property, DataType

# Σύνδεση
client = weaviate.connect_to_weaviate_cloud(
    cluster_url="https://your-cluster.weaviate.network",
    auth_credentials=weaviate.AuthApiKey("YOUR_API_KEY")
)

# Ορισμός schema
client.collections.create(
    name="Documentation",
    vectorizer_config=Configure.Vectorizer.text2vec_openai(),
    properties=[
        Property(name="title", data_type=DataType.TEXT),
        Property(name="content", data_type=DataType.TEXT),
        Property(name="category", data_type=DataType.TEXT)
    ],
    multi_tenancy_config=Configure.multi_tenancy(enabled=True)
)

# Εισαγωγή δεδομένων
docs = client.collections.get("Documentation")
docs.config.add_tenant("tenant_42")

with docs.batch.dynamic() as batch:
    batch.add_object(
        properties={"title": "RAG Guide", "content": "...", "category": "AI"},
        tenant="tenant_42"
    )

# Hybrid αναζήτηση
response = docs.query.hybrid(
    query="vector databases σύγκριση",
    alpha=0.75,
    tenant="tenant_42",
    limit=10,
    return_metadata=["score", "explain_score"]
)

Κεφάλαιο 5: pgvector — Η Ισχύς της PostgreSQL

-- Ενεργοποίηση extension
CREATE EXTENSION IF NOT EXISTS vector;

-- Δημιουργία πίνακα με vector στήλη
CREATE TABLE documents (
    id bigserial PRIMARY KEY,
    title text,
    content text,
    embedding vector(3072),
    category text,
    created_at timestamp DEFAULT now()
);

-- HNSW Index για γρήγορη σημασιολογική αναζήτηση
CREATE INDEX ON documents 
USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);

-- Παραδοσιακό B-tree index για metadata filtering
CREATE INDEX idx_category ON documents(category);

-- Hybrid αναζήτηση: vector similarity + exact SQL filters
SELECT id, title, content,
       1 - (embedding <=> '[-0.02, 0.03, ...]'::vector) AS cosine_similarity
FROM documents
WHERE category = 'AI' AND created_at > '2024-01-01'
ORDER BY embedding <=> '[-0.02, 0.03, ...]'::vector
LIMIT 10;

SELECT u.name, u.email, p.preference_vector <=> query_vec AS distance
FROM users u
JOIN user_preferences_embeddings p ON u.id = p.user_id
WHERE u.subscription = 'premium'
ORDER BY p.preference_vector <=> query_vec
LIMIT 20;

Κεφάλαιο 6: Head-to-Head Σύγκριση σε Βάθος

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

Εγκατάσταση και Time-to-First-Query

Το Pinecone είναι αναμφισβήτητα ο νικητής εδώ. Με ένα API key και μια κλήση pip install pinecone-client, μπορείτε να έχετε έναν πλήρως λειτουργικό vector index σε λιγότερο από πέντε λεπτά. Δεν υπάρχει Docker, δεν υπάρχει provisioning, δεν υπάρχει tuning του λειτουργικού συστήματος.

Το Weaviate είναι δεύτερο. Με το Docker compose αρχείο της εταιρείας, μπορείτε να έχετε local instance σε 10 λεπτά. Ωστόσο, το GraphQL schema και ο ορισμός των classes απαιτούν λίγο περισσότερη σκέψη σε σχέση με το «δώσε vectors» μοντέλο του Pinecone.

Το pgvector απαιτεί μια εγκατεστημένη PostgreSQL. Αν ήδη την έχετε, η ενεργοποίηση είναι μια εντολή (CREATE EXTENSION). Αν όχι, η εγκατάσταση Postgres + tuning για vector workloads (shared_buffers, work_mem, maintenance_work_mem) μπορεί να πάρει μια ώρα ή περισσότερο.

Query Performance και Latency

Σε επίπεδο millisecond latency, και οι τρεις πλατφόρμες είναι εξαιρετικές για workloads μέχρι εκατοντάδες εκατομμύρια διανυσμάτων. Το Pinecone, λόγω της αρχιτεκτονικής του και του optimized hardware layer, προσφέρει πολύ συνεπή P99 latency που σπάνια ξεπερνά τα 50ms, ακόμη και με complex metadata filtering.

Το Weaviate με HNSW είναι εξίσου γρήγορο, αλλά η απόδοση μπορεί να επηρεαστεί από το μέγεθος του schema και τα nested cross-references. Σε extremely high throughput, το Weaviate μπορεί να χρειαστεί horizontal scaling με το Raft-based cluster του (Weaviate Cluster Service).

Το pgvector εξαρτάται άμεσα από τον υλισμικό πόρο. Με HNSW σε έναν ισχυρό server (16+ cores, γρήγορους NVMe δίσκους και πολύ RAM), μπορεί να εξυπηρετήσει χιλιάδες QPS με sub-20ms latency. Ωστόσο, σε under-provisioned instance, το IO bottleneck γίνεται αμέσως αντιληπτό.

Ενημέρωση Δεδομένων (Upserts/Deletes)

Ένα κοινό λάθος είναι να υποθέτουμε ότι vector databases είναι read-only. Σε πραγματικές RAG εφαρμογές, τα δεδομένα αλλάζουν συνεχώς. Το Pinecone υποστηρίζει real-time updates χωρίς αναδόμηση, με την εγγύηση ότι τα νέα διανύσματα είναι άμεσα queryable. Ομοίως, το Weaviate επιτρέπει CRUD operations χωρίς downtime.

Το pgvector υποστηρίζει εγγενώς INSERT, UPDATE και DELETE ως μέρος του SQL standard. Υπάρχει, ωστόσο, ένα caveat: τα HNSW indexes στην PostgreSQL δεν είναι βελτιστοποιημένα για μαζικά sequential inserts. Αν εισάγετε εκατομμύρια γραμμές σε έναν πίνακα με ενεργό HNSW index, η εισαγωγή θα επιβραδυνθεί σημαντικά. Η βέλτιστη πρακτική είναι να αφαιρέσετε προσωρινά το index, να κάνετε το bulk insert, και να το ξαναδημιουργήσετε.

Metadata Filtering

Το Pinecone προσφέρει προ-φιλτράρισμα που είναι τόσο γρήγορο όσο και η ίδια η vector search, υποστηρίζοντας συγκρίσεις ($eq, $ne, $gt, $gte, $lt, $lte, $in), λογικούς τελεστές ($and, $or), και ακόμη και φιλτράρισμα πάνω σε arrays.

Το Weaviate υποστηρίζει παρόμοια φίλτρα μέσω του where argument στο GraphQL, με πρόσθετη υποστήριξη για geo-coordinates και tokenization.

Το pgvector, φυσικά, κερδίζει σε ευελιξία: μπορείτε να χρησιμοποιήσετε οποιαδήποτε SQL συνθήκη, κοιτάζοντας πολλαπλούς πίνακες, χρησιμοποιώντας subqueries, CTEs, window functions και οτιδήποτε άλλο υποστηρίζει η Postgres. Αν το query σας είναι «βρες προϊόντα όμοια με αυτό, που ανήκουν σε κατηγορίες όπου ο μέσος όρος αξιολογήσεων είναι πάνω από 4.5 και το stock > 0», μόνο το pgvector μπορεί να το εκτελέσει native σε ένα query.

Deployment Options και Vendor Lock-in

Αυτή είναι η πιο σημαντική κατηγορία για πολλές επιχειρήσεις. Το Pinecone είναι αποκλειστικά SaaS. Αν σταματήσετε να πληρώνετε ή αν αλλάξουν τις τιμές, πρέπει να κάνετε migrate. Η migration από Pinecone σε άλλη λύση είναι εφικτή (export ως Parquet ή direct fetch), αλλά απαιτεί downtime και rewriting του application code.

Το Weaviate προσφέρει τον καλύτερο συμβιβασμό: ξεκινήστε με WCS (managed), και αν χρειαστεί, φέρτε το on-prem. Το API παραμένει το ίδιο. Αυτή η portability είναι σημαντική για compliance (GDPR, HIPAA) και cost control.

Το pgvector κερδίζει απόλυτα εδώ. Τα δεδομένα σας βρίσκονται σε open format (PostgreSQL tables). Μπορείτε να μετακινηθείτε από self-hosted σε AWS RDS, σε Google Cloud SQL, σε Azure, ή σε οποιονδήποτε managed Postgres provider που υποστηρίζει extensions, χωρίς να αλλάξετε μια γραμμή κώδικα.

«Η επιλογή vector database δεν είναι τεχνολογική απόφαση μόνο· είναι απόφαση προϊόντος και οργανωτικής κουλτούρας.» — RAG Architecture Patterns, 2026

Κεφάλαιο 7: Hands-on Tutorial — Χτίζοντας RAG από το Μηδέν

Ας βάλουμε όλη τη θεωρία σε πράξη. Θα χτίσουμε ένα πλήρες RAG pipeline χρησιμοποιώντας Python, LangChain (προαιρετικά) και τις τρεις βάσεις. Το παράδειγμά μας θα είναι ένα σύστημα FAQ για μια τεχνολογική εταιρεία.

Βήμα 1: Προετοιμασία των Εγγράφων και Chunking

Το πρώτο βήμα σε κάθε RAG σύστημα είναι η επεξεργασία των raw documents. Τα LLMs έχουν περιορισμένο context window, άρα δεν μπορούμε να στείλουμε ένα βιβλίο 500 σελίδων. Πρέπει να το σπάσουμε σε chunks (τμήματα). Η στρατηγική chunking είναι κρίσιμη: πολύ μικρά chunks χάνουν context, πολύ μεγάλα μειώνουν την ακρίβεια της ανάκτησης.

from langchain.text_splitter import RecursiveCharacterTextSplitter

text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,
    chunk_overlap=50,
    separators=["\n\n", "\n", ". ", " ", ""]
)

documents = load_your_documents()  # δική σας συνάρτηση
chunks = text_splitter.split_documents(documents)

Βήμα 2: Δημιουργία Embeddings

Χρησιμοποιούμε το text-embedding-3-large επειδή προσφέρει εξαιρετική απόδοση σε ελληνικά και αγγλικά, σε συνδυασμό με καλό compression. Εναλλακτικά, για fully on-prem λύσεις, τα BAAI/bge-large ή intfloat/multilingual-e5-large είναι εξαιρετικές open-source επιλογές.

import openai

def get_embedding(text: str, model="text-embedding-3-large") -> list[float]:
    text = text.replace("\n", " ")
    return openai.embeddings.create(
        input=[text], 
        model=model
    ).data[0].embedding

# Batch processing για ταχύτητα
embeddings = [get_embedding(chunk.page_content) for chunk in chunks]

Βήμα 3: Αποθήκευση σε Pinecone

from pinecone import Pinecone, ServerlessSpec

pc = Pinecone(api_key="YOUR_KEY")
index_name = "faq-system"

if index_name not in pc.list_indexes().names():
    pc.create_index(
        name=index_name,
        dimension=3072,
        metric="cosine",
        spec=ServerlessSpec(cloud="aws", region="us-east-1")
    )

index = pc.Index(index_name)

vectors = []
for i, (chunk, emb) in enumerate(zip(chunks, embeddings)):
    vectors.append({
        "id": f"chunk_{i}",
        "values": emb,
        "metadata": {
            "source": chunk.metadata.get("source", "unknown"),
            "page": chunk.metadata.get("page", 0),
            "text": chunk.page_content[:1000]  # truncate για metadata limits
        }
    })

index.upsert(vectors=vectors, namespace="tenant_prod")

Βήμα 4: Αποθήκευση σε Weaviate

import weaviate
from weaviate.classes.config import Configure, Property, DataType

client = weaviate.connect_to_weaviate_cloud(
    cluster_url="https://...",
    auth_credentials=weaviate.AuthApiKey("YOUR_KEY")
)

client.collections.create(
    name="FAQ",
    vectorizer_config=Configure.Vectorizer.none(),  # φέρνουμε δικά μας embeddings
    properties=[
        Property(name="text", data_type=DataType.TEXT),
        Property(name="source", data_type=DataType.TEXT),
        Property(name="category", data_type=DataType.TEXT),
    ]
)

faq = client.collections.get("FAQ")

with faq.batch.dynamic() as batch:
    for chunk, emb in zip(chunks, embeddings):
        batch.add_object(
            properties={
                "text": chunk.page_content,
                "source": chunk.metadata.get("source"),
                "category": "technical"
            },
            vector=emb
        )

Βήμα 5: Αποθήκευση σε pgvector

import psycopg2

conn = psycopg2.connect("dbname=rag user=postgres password=...")
cur = conn.cursor()

cur.execute("CREATE EXTENSION IF NOT EXISTS vector;")
cur.execute("""
    CREATE TABLE IF NOT EXISTS faq_chunks (
        id SERIAL PRIMARY KEY,
        text TEXT,
        source TEXT,
        category TEXT,
        embedding vector(3072)
    );
""")

# Bulk insert με executemany για απόδοση
data = [
    (c.page_content, c.metadata.get("source"), "technical", emb) 
    for c, emb in zip(chunks, embeddings)
]

cur.executemany("""
    INSERT INTO faq_chunks (text, source, category, embedding)
    VALUES (%s, %s, %s, %s)
""", data)

conn.commit()

# Δημιουργία index μετά το insert
cur.execute("""
    CREATE INDEX ON faq_chunks 
    USING hnsw (embedding vector_cosine_ops)
    WITH (m = 16, ef_construction = 64);
""")
conn.commit()

Βήμα 6: Retrieval και Generation

Το τελευταίο βήμα είναι η σύνδεση του retriever με το LLM. Εδώ δείχνουμε την υλοποίηση με καθαρό Python, ανεξάρτητα από orchestration framework:

def answer_question(question: str, db_type="pinecone"):
    # 1. Embed την ερώτηση
    q_embedding = get_embedding(question)
    
    # 2. Ανάκτηση top-k chunks
    if db_type == "pinecone":
        results = index.query(
            vector=q_embedding, top_k=5, 
            namespace="tenant_prod", include_metadata=True
        )
        contexts = [r["metadata"]["text"] for r in results["matches"]]
    
    elif db_type == "weaviate":
        response = faq.query.near_vector(
            near_vector=q_embedding, limit=5
        )
        contexts = [obj.properties["text"] for obj in response.objects]
    
    elif db_type == "pgvector":
        cur.execute("""
            SELECT text FROM faq_chunks
            ORDER BY embedding <=> %s::vector
            LIMIT 5;
        """, (q_embedding,))
        contexts = [row[0] for row in cur.fetchall()]
    
    # 3. Build prompt
    context_text = "\n\n---\n\n".join(contexts)
    prompt = f"""Βασισμένο αποκλειστικά στο παρακάτω κείμενο, απάντησε στην ερώτηση.
Αν δεν ξέρεις, πες 'Δεν το γνωρίζω'.

ΚΕΙΜΕΝΟ:
{context_text}

ΕΡΩΤΗΣΗ: {question}
ΑΠΑΝΤΗΣΗ:"""

    # 4. Generate
    response = openai.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": prompt}],
        temperature=0.1
    )
    return response.choices[0].message.content

Αυτός ο κώδικας λειτουργεί για και τις τρεις βάσεις. Η διαφορά βρίσκεται αποκλειστικά στο retrieval layer. Το generation layer παραμένει πανομοιότυπο, κάτι που αποδεικνύει την ευελιξία του RAG pattern.

Κεφάλαιο 8: Advanced RAG — Πέρα από τα Βασικά

Η βασική υλοποίηση RAG είναι μόνο η αρχή. Σε παραγωγικά περιβάλλοντα, αντιμετωπίζετε γρήγορα προβλήματα όπως:

Re-ranking

Η αρχική ανάκτηση (retrieval) με ANN είναι γρήγορη αλλά προσεγγιστική. Για να βελτιώσουμε την ακρίβεια, χρησιμοποιούμε ένα δεύτερο μοντέλο — τον re-ranker. Ο re-ranker παίρνει το query και τα 50-100 κοντινότερα chunks, και υπολογίζει μια πιο ακριβή σημασιολογική ομοιότητα (συνήθως cross-attention). Τα μοντέλα όπως το BAAI/bge-reranker-large ή το Cohere Rerank μπορούν να βελτιώσουν το recall@10 κατά 15-25%.

Η ροή γίνεται: ANN Retrieval (γρήγορο, χαμηλής ακρίβειας) → Re-ranking (αργό, υψηλής ακρίβειας) → Top-5 στο LLM.

Query Expansion και HyDE

Συχνά, η ερώτηση του χρήστη είναι ασαφής ή πολύ σύντομη. Τεχνικές όπως το Query Expansion (χρήση LLM για να γράψει 3-4 παραλλαγές της ερώτησης) ή το Hypothetical Document Embeddings (HyDE) (χρήση LLM για να δημιουργήσει μια υποθετική ιδανική απάντηση, embed αυτήν, και αναζήτησε κοντά της) μπορούν να βελτιώσουν δραστικά τα αποτελέσματα.

Parent Document Retrieval

Όταν κάνουμε chunking, χάνουμε ευρύτερο context. Στην τεχνική Parent Document Retrieval, αποθηκεύουμε μικρά chunks για embedding/ανάκτηση, αλλά όταν βρίσκουμε ένα match, ανακτούμε το μεγαλύτερο parent document για να στείλουμε στο LLM. Αυτό δίνει το καλύτερο και των δύο κόσμων: ακριβή retrieval και πλούσιο context.

Multi-modal RAG

Πλέον, τα embeddings δεν περιορίζονται σε κείμενο. Με μοντέλα όπως το CLIP, μπορούμε να ενσωματώσουμε εικόνες, και με audio embeddings να ενσωματώσουμε ήχο. Όλες οι βάσεις που εξετάζουμε υποστηρίζουν multi-modal vectors — απλώς το chunking και το preprocessing αλλάζει. Στο Weaviate, υπάρχει εγγενής υποστήριξη για multi-modal modules. Στο Pinecone, αποθηκεύετε το image vector όπως ακριβώς και το text vector. Στο pgvector, μια στήλη vector(512) μπορεί να κρατήσει οποιοδήποτε embedding.

Κεφάλαιο 9: Πότε να Διαλέξετε Τι;

Ας συνοψίσουμε με έναν πρακτικό οδηγό απόφασης:

Η πραγματικότητα είναι ότι πολλές επιχειρήσεις καταλήγουν σε hybrid architectures. Χρησιμοποιούν pgvector για transactional data που ήδη ζουν στη Postgres (προφίλ χρηστών, προϊόντα) και Pinecone ή Weaviate για massive document stores (τεκμηρίωση, knowledge base). Η επιλογή δεν χρειάζεται να είναι δυαδική.

Κεφάλαιο 10: Monitoring, Observability και Production Checklist

Ένα RAG σύστημα σε παραγωγή απαιτεί monitoring πέρα από το «λειτουργεί η βάση;». Πρέπει να παρακολουθείτε:

• Retrieval Accuracy: Μετρήστε το Mean Reciprocal Rank (MRR) και το Normalized Discounted Cumulative Gain (NDCG) σε labeled datasets. Αν το MRR πέφτει, ίσως χρειάζεστε re-embedding ή fine-tuning του chunking strategy.
• Context Relevance: Χρησιμοποιήστε LLM-as-a-judge για να βαθμολογήσετε αν τα retrieved chunks αποτελούν χρήσιμο context για την ερώτηση. Οι μετρικές όπως το Context Precision και Context Recall από frameworks όπως το RAGAS είναι ανεκτίμητες.
• Answer Faithfulness: Μετρήστε πόσο «πιστή» είναι η απάντηση του LLM στα retrieved chunks. Αν το LLM αρχίζει να παραθέτει πληροφορίες που δεν υπάρχουν στα chunks, έχετε πρόβλημα prompt engineering ή temperature setting.
• Latency Budgets: Καταγράψτε ξεχωριστά το embedding time (συνήθως 100-500ms), το retrieval time (5-50ms για Pinecone/Weaviate, 10-100ms για pgvector), και το generation time (1-10s ανάλογα με το μοντέλο).

Για το infrastructure monitoring, το Pinecone προσφέρει built-in metrics dashboard. Το Weaviate εκθέτει Prometheus metrics. Το pgvector κληρονομεί ολόκληρο το οικοσύστημα monitoring της PostgreSQL — Prometheus exporters, pg_stat_statements, slow query logs και άλλα.