بناء Private RAG Stack على PostgreSQL: ‏pgvector وBM25 وTEI عمليًا

Private RAG Architecture ممكن تتعقد بسرعة جدًا.

سهل تلاقي نفسك عندك Database للApplication Data، وVector Database منفصلة، Search Engine ثانية، Embedding API، Reranking API، Cache ومجموعة Sync Jobs ماسكة كل ده مع بعض.

أحيانًا Complexity دي مبررة.

وأحيانًا Architecture اتبنت قبل ما Workload تطلبها.

أثناء بناء CaBrain، الـlong-term memory وretrieval layer اللي بنيتها للـAI Agents، اخترت Center of Gravity مختلفة: PostgreSQL.

الStack تجمع Relational Data وVector Retrieval وBM25-style Lexical Retrieval وReranking وخدمات مستقلة للEmbeddings/Reranking. الهدف مش إثبات إن PostgreSQL تستبدل كل Specialized Search Product، لكن الحفاظ على System مفهومة مع أكثر من Retrieval Signal.

Architecture بشكل سريع

وقت Ingestion:

Documents/Memories → Normalization/Chunking → Embeddings → PostgreSQL

وقت Query:

Query → Vector Retrieval + Lexical/BM25 Retrieval → Fusion/Ranking → Reranking → Selected Context → Model/Agent

وحول ده Metadata وPermissions وNamespaces وEntity Relationships وMemory Lifecycle Logic.

Embeddings وReranking ممكن يشتغلوا خلف TEI (Text Embeddings Inference) Services، بحيث Model-serving تفضل منفصلة عن Application Database.

PostgreSQL تملك Durable Data وRetrieval Indexes، وInference Services تعمل Inference.

ليه PostgreSQL في المركز؟

CaBrain تحتاج Structured Information، مش Text Chunks فقط.

Memory أوKnowledge Item ممكن يكون لها Source/Provenance، Namespace، Entity Relationships، Timestamps، Salience/Lifecycle Metadata، Permissions، Structured Attributes، Vector Representation وLexical Representation.

ده يخلي Relational Database مكان طبيعي للDurable Record.

PostgreSQL كمان تعطي Transactions وConstraints وJoins وBackups وOperational Tooling بدل إعادة بناء الحاجات دي حول Vector-only Store.

الفكرة مش إن One Database دائمًا أفضل.

الفكرة إننا ما نضيفش Stateful System ثانية قبل ما Benefit تكون واضحة.

pgvector تضيف Semantic Retrieval بدون نقل Data بعيد

Semantic Retrieval مفيدة لما صياغة User تختلف عن Stored Text.

Embeddings تحول Query وContent إلى Vectors للمقارنة.

مع pgvector-compatible Storage/Indexing داخل PostgreSQL، Vector Representation تعيش جنب Record اللي بتمثلها.

Record → Metadata → Permissions → Vector تفضل جزء من نفس Durable Data Model.

مش محتاج Synchronization Pipeline هدفها الوحيد مزامنة Vector Database منفصلة مع Primary Database.

تقليل Moving Parts ده مهم بالنسبة لي.

لكن Vector Search وحدها مش كفاية

Semantic Similarity قوية، لكن Exact Language مهمة.

Repository Name، Package Name، Issue Key، Product Code، Person Name أوTechnical Term محددة ممكن تحتاج Exact Match أكثر من Semantically Nearest Passage.

علشان كده CaBrain تجمع Semantic Retrieval مع BM25-style Lexical Search.

الSignals الاثنين يعالجوا Failure Modes مختلفة.

BM25 تضيف إيه؟

Lexical Retrieval تكافئ Documents اللي تحتوي Terms مرتبطة بالQuery بناءً على Occurrence/Rarity بدل Embedding Proximity فقط.

لو Corpus فيها Notes كثيرة عن Databases لكن واحدة فقط تذكر VectorChord أوIssue Key محددة، Semantic Search قد ترجع Material مرتبطة بالDatabases عمومًا، بينما Lexical Retrieval ترفع Exact Term بقوة.

مش لازم نعلن Method واحدة Winner.

هات Candidates من الاثنين واجمعهم.

Hybrid Retrieval هدفها Candidate Diversity

Pipeline مبسطة:

1. Generate Query Embedding.
2. Retrieve Semantic Candidates.
3. Retrieve Lexical Candidates.
4. Combine Candidate Sets.
5. Apply Fusion/Ranking.
6. Rerank Strongest Candidates.
7. Return فقط Context اللي Downstream Model تحتاجها.

First Retrieval Stage هدفها زيادة احتمال إن Correct Evidence تدخل Candidate Pool.

Reranker بعدها تصرف Compute أكثر لتحدد Candidates الأفضل فعلًا.

ليه Rerank بعد Retrieval؟

Initial Retrieval Methods مصممة لاستخراج Candidates بكفاءة.

Reranker تقدر تفحص Query-document Relationship بشكل أدق على Set صغيرة.

فتصبح Architecture:

Fast Retrieval → More Expensive Relevance Judgment

بدل تشغيل Expensive Model على Corpus كلها.

وده مهم لأن Irrelevant Chunks تستهلك Context Tokens وقد تشتت Generation Model.

Better Retrieval هي Context Engineering كمان.

TEI تخلي Embedding Infrastructure خلف Service Boundary

في CaBrain، Embedding وReranking ممكن يتقدموا عبر TEI بدل دفنهم داخل Application Process.

Application → TEI Embedding Service → Vectors

و:

Candidate Pairs → TEI Reranking Service → Relevance Ordering

كده Application عندها Stable Interface مع Inference Infrastructure.

Embedding Model تتغير بدون تغيير Domain Model للApplication، ونفس المبدأ للReranking.

وده مفيد في Private AI لما Organization عايزة Inference Operations تشتغل داخل Infrastructure تحت سيطرتها.

Private RAG أكثر من Local Model

تشغيل LLM محليًا مش معناه إن Complete System أصبحت Private.

تتبع Data Path كلها: Application API، Authentication، Database، Embedding Model، Reranker، LLM، Logs/Traces، Object Storage وBackups.

لو Sensitive Text بتروح External Embedding Endpoint بينما Final LLM Local، Architecture مش Fully Private بالشكل اللي Business تتوقعه.

Privacy خاصية End-to-end للData Flow.

Ingestion لازم تحافظ على Provenance

RAG Quality تبدأ قبل Retrieval.

لما Content تدخل، احتفظ بما يكفي تعرف Source، Capture Time، Document/Version، Tenant/Namespace، Validity وPermissions.

بدون Provenance، Fluent Answer ممكن تكون مستحيل تعمل لها Audit.

وده أهم مع Knowledge Base تتغير مع الوقت.

Chunking قرار Domain

مفيش Universal Chunk Size تخلي كل RAG تشتغل.

Policy Document وSource Code وCustomer Ticket وLong-term Agent Memory عندهم Structures مختلفة.

Chunk Boundaries لازم تحافظ على Meaning مفيدة.

أحيانًا Headings/Sections Boundaries طبيعية. وأحيانًا Structured Records ما ينفعش تتحول Arbitrary Text Chunks أصلًا.

قبل Tuning للVector Index، اتأكد إن Retrieval Unit نفسها مفيدة.

Metadata Filtering تحصل بدري

لو Corpus فيها Tenants أوPermission Levels مختلفة، ما تعملش Global Retrieval وتطلب من LLM تتجاهل Results غير المسموحة.

Filter Search Space في Data/Retrieval Layer باستخدام Authorized Metadata: Tenant/Workspace، Corpus/Namespace، Document Type، Visibility، Language، Validity State.

ده يحسن Security وRetrieval Precision.

PostgreSQL تجعل Structured Filters طبيعية

Query نادرًا ما تكون “هات Nearest Vector” فقط.

غالبًا:

هات Relevant Memories في Corpus دي، للTenant ده، Visible للActor ده، Still Active، ثم Rank للQuery.

Relational Filters وRetrieval Signals يلتقوا طبيعيًا هنا.

Fusion مهمة

Vector وLexical Retrieval ترجع Ranked Lists مختلفة، ولازم نجمعهم.

Approach مثل Reciprocal Rank Fusion (RRF) يدمج Rankings بدل محاولة مقارنة Raw Scores من Retrieval Methods مختلفة في معناها.

Exact Strategy تختلف، لكن ما تفترضش Cosine Similarity Score وLexical Relevance Score قابلين للمقارنة مباشرة.

اعمل Fusion بشكل Deliberate واختبر على Queries الحقيقية.

Retrieval تحتاج Evaluation Set

Architecture ما تتقيمش من Demos مبهرة.

اعمل Real Questions مع Expected Evidence، واختبر: Correct Document دخل Candidate Set؟ Correct Passage Rank عالية؟ Hybrid أحسن من Vector-only في Exact-term Queries؟ Reranking حسنت Ordering؟ Metadata Filters شالت Evidence مطلوبة؟ Stale Documents سبقت Current Ones؟

الإجابات هي اللي تقود Architecture Changes.

Retrieval Evaluation غير Answer Evaluation

لو Correct Context ما وصلتش Generation Model، Prompt Tuning مش هتصلح Retrieval.

ولو Correct Context موجودة لكن Final Answer غلط، Retrieval ممكن تكون شغالة صح.

Log Stages منفصلة:

Query → Retrieved Candidates → Fused Ranking → Reranked Context → Generated Answer

ده يخلي Debugging أدق جدًا.

PostgreSQL لا تلغي Scaling Questions

Centering على PostgreSQL يبسط Architecture، لكنه لا يلغي Capacity Planning.

مع نمو Corpus فكر في Index Strategy، Query Latency، Concurrent Workload، Vector Dimensionality، Ingestion Throughput، Vacuum/Maintenance، Storage Growth، Connection Management، Replication/Backups.

عند Workload معينة Specialized System ممكن تصبح الاختيار الصحيح.

القرار يطلع من Measured Constraints، مش افتراض إن “AI لازم Vector Database Product”.

افصل Online عن Ingestion Workloads عند الحاجة

Embedding Document Batches Workload مختلفة عن Serving Queries.

استخدم Queues/Workers:

Source → Ingestion Queue → Parse/Chunk → Embedding Service → Transactional Write/Index

بينما Query:

Request → Retrieve → Rerank → Generate

ده يسهل Backpressure وRetries.

تغيير Embedding Model يحتاج Migration Strategy

Vectors Derived Data.

لو غيرت Embedding Model، Old/New Vectors قد لا تكون Compatible في نفس Similarity Space.

اعتبر Model/Version جزء من Indexed Representation.

Migration ممكن تحتاج New Vector Set ثم Traffic Switch بدل Overwrite أعمى.

Durable Source Content لازم تفضل موجودة لإعادة بناء Derived Indexes.

نفس الكلام للChunking

تغيير Chunking Logic يغير Retrieval Units.

علشان كده Source Documents وProvenance لازم تكون منفصلة عن Derived Chunks/Embeddings.

RAG Infrastructure لازم تكون Rebuildable.

Vector Index ما ينفعش تبقى النسخة الوحيدة من Knowledge.

Caching تساعد، لكن Freshness أهم

Unchanged Document Embeddings ما تتولدش كل Query، وبعض Intermediate Results ممكن تتReuse حسب Use Case.

لكن Cache لAnswers بدون فهم Source Freshness ممكن تعمل Stale Business Responses.

Cache Derived Computation بحذر وخلي Authority في Underlying Data.

RAG وLong-term Memory بينهم تداخل لكن مش نفس الحاجة

CaBrain تستخدم Retrieval كجزء من Agent Memory، وده يضيف Lifecycle Questions فوق Document RAG.

Document Knowledge Base تسأل: أنهي Source Passages تجاوب السؤال؟

Long-term Memory تسأل كمان: إيه يتRetain أوUpdate أوConsolidate أوForget مع الوقت؟

Retrieval Infrastructure ممكن تكون مشتركة، وMemory Lifecycle فوقها.

Entity Graph تكمل Text Retrieval

بعض الأسئلة Relational أكثر من Textual.

لو Agent محتاجة تعرف Company تستخدم Technology إيه، Repository تابعة لمين، أوEvent غيرت Entity، Graph Relationships قد تكون أكثر مباشرة من إعادة اكتشاف Links من Chunks كل مرة.

في CaBrain، Entity Graph تكمل Hybrid Recall بدل استبدالها.

Different Retrieval Abstractions لأسئلة مختلفة.

خلي Generation قابلة للاستبدال

RAG Architecture ما تربطش Knowledge Layer بـGeneration Provider واحدة.

Durable System تملك Documents وPermissions وRetrieval وProvenance.

Final Model مجرد Consumer للSelected Context.

كده تقدر Route بين Hosted/Local Models أوتغير Provider بدون Rebuild للKnowledge Base.

وده مفيد جدًا في Private AI لأن Privacy وQuality وCost Requirements تختلف حسب Workflow.

إيه اللي يعجبني في Architecture دي؟

أقوى Property مش Benchmark Number.

هي Separation of Concerns بدون Unnecessary Fragmentation.

PostgreSQL تفضل Durable Center.

Vector وLexical Retrieval يعطوا Complementary Signals.

Reranking تحسن Final Context Selection.

TEI تخلي Embedding/Reranking Inference خلف Service Boundaries واضحة.

Agent أوLLM تستقبل Selected Context فقط.

وMemory Lifecycle أوEntity Relationships تقدر تعيش فوق نفس Foundation.

Architecture دي لا تدعي إيه؟

مش بتقول PostgreSQL هتكسب كل Specialized Vector/Search Database عند كل Scale.

مش بتقول Hybrid Retrieval تحسن كل Corpus تلقائيًا.

ومش بتقول Reranking تستحق Latency دائمًا.

دي Workload-dependent Questions.

الميزة إن Components قابلة للقياس والاستبدال لما Evidence تقول إن ده مطلوب.

وده أهم عندي من اختيار Infrastructure بالTrend.

Checklist عملية

قبل Private RAG اسأل:

1. أنهي Data لازم تفضل Private؟
2. Embeddings هتتولد فين؟
3. Reranking هتشتغل فين؟
4. Final LLM هتشتغل فين؟
5. إيه Authoritative Source لكل Document؟
6. Tenant/Permission Boundaries تتفرض إزاي؟
7. Exact Terms مهمة بما يكفي لـLexical Retrieval؟
8. Vector/Lexical Rankings هتتجمع إزاي؟
9. Reranking فعلًا بتحسن Retrieval على Evaluation Set؟
10. نقدر Rebuild Embeddings/Chunks بعد Changes؟
11. Stale Content تتشال أوتتعمل لها Invalidation إزاي؟
12. عند أنهي Measured Constraint Specialized Retrieval Service تصبح مبررة؟

الأسئلة دي تحدد Architecture أفضل من سؤال “أنهي Vector Database أشهر؟”.

Private RAG المفروض تكون Boring حيث يمكن

AI Systems فيها Uncertainty أصلًا عند Model Boundary.

أفضل Infrastructure حولها تكون Explicit قدر الإمكان:

Durable Records في Proven Database.

Clear Permission Filters.

Rebuildable Derived Indexes.

Observable Retrieval Stages.

Bounded Inference Services.

Measurable Evaluation.

بالنسبة لـCaBrain، PostgreSQL مع Vector/Lexical Retrieval وخدمات TEI وReranking توفر Foundation دي مع إمكانية تطوير Components لاحقًا.

الهدف مش أقل Technology List لمجرد التقليل.

الهدف Architecture كل Component إضافية فيها عندها سبب واضح للوجود.

بتبني Private RAG System ومحتاج تحدد قد إيه Infrastructure فعلًا؟

أصمم Private AI وRetrieval Architectures حول Data Boundaries وHybrid Search وEvaluation وModel Portability وProduction Operations، من PostgreSQL-centered Systems لحد Specialized Components لما Workload تحتاجها فعلًا.

---

مرتبط: Private AI، Agent Memory with CaBrain، RAG vs Fine-Tuning vs AI Agents، Local LLM vs Hosted AI وRAG Chatbot vs Scripted Bot.