trustgraph/docs/tech-specs/extraction-time-provenance.ar.md

أصل البيانات في وقت الاستخراج: الطبقة المصدر

نظرة عامة

يوثق هذا المستند ملاحظات حول أصل البيانات في وقت الاستخراج لأعمال المواصفات المستقبلية. يسجل أصل البيانات في وقت الاستخراج "الطبقة المصدر" - من أين أتت البيانات في الأصل، وكيف تم استخراجها وتحويلها.

هذا يختلف عن أصل البيانات في وقت الاستعلام (انظر query-time-provenance.md) الذي يسجل استنتاجات الوكيل.

بيان المشكلة

التنفيذ الحالي

يعمل أصل البيانات حاليًا على النحو التالي: يتم تخزين بيانات وصف المستند كـ RDF triples في الرسم البياني المعرفي. يربط معرف المستند البيانات الوصفية بالمستند، بحيث يظهر المستند كعقدة في الرسم البياني. عند استخراج الحواف (العلاقات/الحقائق) من المستندات، تربط علاقة subjectOf الحافة المستخرجة بالمستند المصدر.

المشاكل في النهج الحالي

1. تحميل البيانات الوصفية المتكرر: يتم تجميع بيانات وصف المستند وتحميلها بشكل متكرر مع كل مجموعة من الـ triples المستخرجة من هذا المستند. هذا مضيعة ويزيد من التكرار - نفس البيانات الوصفية تنتقل كحمولة مع كل مخرج استخراج.

2. أصل بيانات سطحي: تربط العلاقة subjectOf الحالية الحقائق مباشرة بالمستند ذي المستوى الأعلى فقط. لا توجد رؤية لسلسلة التحويل - أي الصفحة التي جاءت منها الحقيقة، أو الجزء، أو طريقة الاستخراج المستخدمة.

الحالة المرغوبة

1. تحميل البيانات الوصفية مرة واحدة: يجب تحميل بيانات وصف المستند مرة واحدة وإرفاقها بعقدة المستند ذات المستوى الأعلى، وليس تكرارها مع كل مجموعة من الـ triples.

2. رسم بياني كامل لأصل البيانات: التقاط سلسلة التحويل الكاملة من المستند المصدر عبر جميع القطع الأثرية الوسيطة وصولاً إلى الحقائق المستخرجة. على سبيل المثال، تحويل مستند PDF:

   PDF file (source document with metadata)
     → Page 1 (decoded text)
       → Chunk 1
         → Extracted edge/fact (via subjectOf)
         → Extracted edge/fact
       → Chunk 2
         → Extracted edge/fact
     → Page 2
       → Chunk 3
         → ...
   

3. التخزين الموحد: يتم تخزين الرسم البياني للأصل (provenance DAG) في نفس الرسم البياني للمعرفة كما يتم تخزين المعرفة المستخرجة. يتيح ذلك الاستعلام عن الأصل بنفس الطريقة التي يتم بها الاستعلام عن المعرفة - من خلال تتبع الحواف صعودًا في السلسلة من أي حقيقة إلى موقع مصدرها الدقيق.

4. معرفات مستقرة: لكل قطعة أثرية وسيطة (صفحة، جزء) معرف مستقر كعقدة في الرسم البياني.

5. الربط بين الأب والطفل: يتم ربط المستندات المشتقة بآبائها وصولاً إلى المستند المصدر الرئيسي باستخدام أنواع علاقات متسقة.

6. تخصيص الحقائق بدقة: تشير العلاقة subjectOf في الحواف المستخرجة إلى الأصل الفوري (الجزء)، وليس المستند الرئيسي. يتم استعادة الأصل الكامل من خلال التنقل عبر الرسم البياني للأصل.

حالات الاستخدام

UC1: تحديد مصدر المعلومات في استجابات GraphRAG

السيناريو: يقوم المستخدم بتشغيل استعلام GraphRAG ويتلقى استجابة من الوكيل.

التدفق:

1. يرسل المستخدم استعلامًا إلى وكيل GraphRAG.
2. يسترجع الوكيل الحقائق ذات الصلة من الرسم البياني للمعرفة لصياغة استجابة.
3. وفقًا لمواصفات الأصل في وقت الاستعلام، يقوم الوكيل بالإبلاغ عن الحقائق التي ساهمت في الاستجابة.
4. يربط كل حقيقة بمصدره (الجزء) عبر الرسم البياني للأصل.
5. ترتبط الأجزاء بالصفحات، وترتبط الصفحات بمستندات المصدر.

النتيجة في تجربة المستخدم: يعرض الواجهة استجابة نموذج اللغة الكبير (LLM) جنبًا إلى جنب مع تحديد مصدر المعلومات. يمكن للمستخدم: رؤية الحقائق التي دعمت الاستجابة. النزول من الحقائق إلى الأجزاء إلى الصفحات إلى المستندات. مراجعة المستندات المصدر الأصلية للتحقق من صحة الادعاءات. فهم بالضبط من أين في المستند (في أي صفحة، في أي قسم) نشأت الحقيقة.

القيمة: يمكن للمستخدمين التحقق من صحة الاستجابات التي تم إنشاؤها بواسطة الذكاء الاصطناعي مقابل المصادر الأولية، مما يعزز الثقة ويمكن المستخدمين من التحقق من الحقائق.

UC2: تصحيح جودة الاستخراج

تبدو حقيقة خاطئة. تتبعها من خلال الجزء إلى الصفحة إلى المستند لمعرفة النص الأصلي. هل كان استخراجًا سيئًا، أم أن المصدر نفسه كان خاطئًا؟

UC3: إعادة استخراج تدريجي

يتم تحديث مستند المصدر. ما هي الأجزاء/الحقائق التي تم اشتقاقها منه؟ قم بإبطالها وإعادة إنشائها فقط لتلك الأجزاء، بدلاً من إعادة معالجة كل شيء.

UC4: حذف البيانات / الحق في النسيان

يجب إزالة مستند المصدر (بسبب اللائحة العامة لحماية البيانات، أو لأسباب قانونية، إلخ). تتبع الرسم البياني للأصل للعثور على جميع الحقائق المشتقة وإزالتها.

UC5: حل النزاعات

تتناقض حقائق مع بعضها البعض. تتبع كلتا الحالتين إلى مصادرها لفهم السبب واتخاذ قرار بشأن أي منهما يجب الوثوق به (المصدر الأكثر موثوقية، أو الأحدث، إلخ).

UC6: وزن سلطة المصدر

بعض المصادر أكثر موثوقية من غيرها. يمكن ترجيح الحقائق أو تصفيتها بناءً على سلطة/جودة مستندات الأصل.

UC7: مقارنة مسار الاستخراج

قارن المخرجات من طرق/إصدارات استخراج مختلفة. أي أداة استخراج أنتجت حقائق أفضل من نفس المصدر؟

نقاط التكامل

أمين المكتبة

يوفر مكون أمين المكتبة بالفعل تخزين المستندات بمعرفات مستندات فريدة. يتكامل نظام التتبع مع هذه البنية التحتية الحالية.

القدرات الحالية (تم تنفيذها بالفعل)

ربط المستندات من الأب إلى الابن: parent_id الحقل في DocumentMetadata - يربط المستند الابن بالمستند الأب document_type الحقل - القيم: "source" (أصلي) أو "extracted" (مشتق) واجهة برمجة تطبيقات add-child-document - لإنشاء مستند ابن بمعرف document_type = "extracted" تلقائيًا واجهة برمجة تطبيقات list-children - لاسترداد جميع المستندات الابناء لمستند أب معين الحذف المتتالي - يؤدي إزالة مستند الأب تلقائيًا إلى حذف جميع مستندات الأبناء

تحديد المستند: معرفات المستندات محددة من قبل العميل (وليس تم إنشاؤها تلقائيًا) المستندات مفهرسة باستخدام (user, document_id) المركب في Cassandra يتم إنشاء معرفات الكائنات (UUIDs) داخليًا لتخزين الكائنات الثنائية

دعم البيانات الوصفية: metadata: list[Triple] الحقل - ثلاثيات RDF للبيانات الوصفية المنظمة title، comments، tags - بيانات وصفية أساسية للمستند time - الطابع الزمني، kind - نوع MIME

هيكل التخزين: يتم تخزين البيانات الوصفية في Cassandra (مساحة مفاتيح librarian، جدول document) يتم تخزين المحتوى في تخزين الكائنات الثنائية MinIO/S3 (دلو library) تسليم محتوى ذكي: يتم تضمين المستندات الأقل من 2 ميجابايت، ويتم بث المستندات الأكبر حجمًا

الملفات الرئيسية

trustgraph-flow/trustgraph/librarian/librarian.py - العمليات الأساسية لأمين المكتبة trustgraph-flow/trustgraph/librarian/service.py - معالج الخدمة، تحميل المستند trustgraph-flow/trustgraph/tables/library.py - تخزين جدول Cassandra trustgraph-base/trustgraph/schema/services/library.py - تعريفات المخططات

الثغرات التي يجب معالجتها

يحتوي أمين المكتبة على اللبنات الأساسية ولكن حاليًا:

1. الربط من الأب إلى الابن ذو مستوى واحد فقط - لا توجد أدوات مساعدة لتصفح الرسوم البيانية متعددة المستويات
2. لا يوجد مفردات قياسية لأنواع العلاقات (مثل derivedFrom، extractedFrom)
3. بيانات التتبع الوصفية (طريقة الاستخراج، والثقة، وموضع الجزء) غير موحدة
4. لا توجد واجهة برمجة تطبيقات للاستعلام للتنقل عبر سلسلة التتبع الكاملة من حقيقة إلى المصدر

تصميم التدفق الشامل

يتبع كل معالج في خط الأنابيب نمطًا متسقًا: استقبال معرف المستند من البنية التحتية جلب المحتوى من أمين المكتبة إنتاج القطع الأثرية الفرعية لكل قطعة أثرية فرعية: حفظ في أمين المكتبة، وإصدار حافة إلى الرسم البياني، وتمرير المعرف إلى البنية التحتية

تدفقات المعالجة

هناك تدفقان اعتمادًا على نوع المستند:

تدفق مستند PDF

┌─────────────────────────────────────────────────────────────────────────┐
│ Librarian (initiate processing)                                         │
│   1. Emit root document metadata to knowledge graph (once)              │
│   2. Send root document ID to PDF extractor                             │
└─────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────────┐
│ PDF Extractor (per page)                                                │
│   1. Fetch PDF content from librarian using document ID                 │
│   2. Extract pages as text                                              │
│   3. For each page:                                                     │
│      a. Save page as child document in librarian (parent = root doc)   │
│      b. Emit parent-child edge to knowledge graph                       │
│      c. Send page document ID to chunker                                │
└─────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────────┐
│ Chunker (per chunk)                                                     │
│   1. Fetch page content from librarian using document ID                │
│   2. Split text into chunks                                             │
│   3. For each chunk:                                                    │
│      a. Save chunk as child document in librarian (parent = page)      │
│      b. Emit parent-child edge to knowledge graph                       │
│      c. Send chunk document ID + chunk content to next processor        │
└─────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
          ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
          Post-chunker optimization: messages carry both
          chunk ID (for provenance) and content (to avoid
          librarian round-trip). Chunks are small (2-4KB).
          ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────────┐
│ Knowledge Extractor (per chunk)                                         │
│   1. Receive chunk ID + content directly (no librarian fetch needed)   │
│   2. Extract facts/triples and embeddings from chunk content            │
│   3. For each triple:                                                   │
│      a. Emit triple to knowledge graph                                  │
│      b. Emit reified edge linking triple → chunk ID (edge pointing     │
│         to edge - first use of reification support)                     │
│   4. For each embedding:                                                │
│      a. Emit embedding with its entity ID                               │
│      b. Link entity ID → chunk ID in knowledge graph                   │
└─────────────────────────────────────────────────────────────────────────┘

تدفق مستندات النص

تتجاوز مستندات النص أداة استخراج ملفات PDF وتنتقل مباشرةً إلى وحدة التقسيم:

┌─────────────────────────────────────────────────────────────────────────┐
│ Librarian (initiate processing)                                         │
│   1. Emit root document metadata to knowledge graph (once)              │
│   2. Send root document ID directly to chunker (skip PDF extractor)    │
└─────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────────┐
│ Chunker (per chunk)                                                     │
│   1. Fetch text content from librarian using document ID                │
│   2. Split text into chunks                                             │
│   3. For each chunk:                                                    │
│      a. Save chunk as child document in librarian (parent = root doc) │
│      b. Emit parent-child edge to knowledge graph                       │
│      c. Send chunk document ID + chunk content to next processor        │
└─────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────────┐
│ Knowledge Extractor                                                     │
│   (same as PDF flow)                                                    │
└─────────────────────────────────────────────────────────────────────────┘

الرسم البياني الموجه الناتج أقصر بمستوى واحد:

PDF:  Document → Pages → Chunks → Triples/Embeddings
Text: Document → Chunks → Triples/Embeddings

التصميم يتكيف مع كل من المصدر والصفحة لأن وحدة التقسيم تعالج مدخلاتها بشكل عام - فهي تستخدم أي معرف مستند تتلقاه كمعرف رئيسي، بغض النظر عما إذا كان ذلك مستند مصدر أم صفحة.

مخطط البيانات الوصفية (PROV-O)

تستخدم البيانات الوصفية المتعلقة بالأصل علم الوجود W3C PROV-O. يوفر هذا مفردات قياسية ويمكن أن يمكّن التوقيع/المصادقة المستقبلية لنتائج الاستخراج.

المفاهيم الأساسية في PROV-O

نوع PROV-O	استخدام TrustGraph
prov:Entity	مستند، صفحة، جزء، ثلاثي، تضمين
prov:Activity	حالات عمليات الاستخراج
prov:Agent	مكونات TG (مثل أداة استخراج PDF، ووحدة التقسيم، إلخ) مع الإصدارات

علاقات PROV-O

الرابط	المعنى	مثال
prov:wasDerivedFrom	كيان مشتق من كيان آخر	الصفحة مشتقة من المستند
prov:wasGeneratedBy	كيان تم إنشاؤه بواسطة نشاط	الصفحة تم إنشاؤها بواسطة نشاط استخراج PDF
prov:used	نشاط استخدم كيانًا كمدخل	نشاط استخراج PDF استخدم المستند
prov:wasAssociatedWith	نشاط تم تنفيذه بواسطة وكيل	نشاط استخراج PDF مرتبط بـ tg:PDFExtractor

البيانات الوصفية في كل مستوى

المستند المصدر (يتم إصداره بواسطة Librarian):

doc:123 a prov:Entity .
doc:123 dc:title "Research Paper" .
doc:123 dc:source <https://example.com/paper.pdf> .
doc:123 dc:date "2024-01-15" .
doc:123 dc:creator "Author Name" .
doc:123 tg:pageCount 42 .
doc:123 tg:mimeType "application/pdf" .

الصفحة (تم إنشاؤها بواسطة مُستخرج PDF):

page:123-1 a prov:Entity .
page:123-1 prov:wasDerivedFrom doc:123 .
page:123-1 prov:wasGeneratedBy activity:pdf-extract-456 .
page:123-1 tg:pageNumber 1 .

activity:pdf-extract-456 a prov:Activity .
activity:pdf-extract-456 prov:used doc:123 .
activity:pdf-extract-456 prov:wasAssociatedWith tg:PDFExtractor .
activity:pdf-extract-456 tg:componentVersion "1.2.3" .
activity:pdf-extract-456 prov:startedAtTime "2024-01-15T10:30:00Z" .

الجزء (يتم إصداره بواسطة وحدة التجميع):

chunk:123-1-1 a prov:Entity .
chunk:123-1-1 prov:wasDerivedFrom page:123-1 .
chunk:123-1-1 prov:wasGeneratedBy activity:chunk-789 .
chunk:123-1-1 tg:chunkIndex 1 .
chunk:123-1-1 tg:charOffset 0 .
chunk:123-1-1 tg:charLength 2048 .

activity:chunk-789 a prov:Activity .
activity:chunk-789 prov:used page:123-1 .
activity:chunk-789 prov:wasAssociatedWith tg:Chunker .
activity:chunk-789 tg:componentVersion "1.0.0" .
activity:chunk-789 tg:chunkSize 2048 .
activity:chunk-789 tg:chunkOverlap 200 .

ثلاثي (تم إصداره بواسطة مُستخلص المعرفة):

# The extracted triple (edge)
entity:JohnSmith rel:worksAt entity:AcmeCorp .

# Subgraph containing the extracted triples
subgraph:001 tg:contains <<entity:JohnSmith rel:worksAt entity:AcmeCorp>> .
subgraph:001 prov:wasDerivedFrom chunk:123-1-1 .
subgraph:001 prov:wasGeneratedBy activity:extract-999 .

activity:extract-999 a prov:Activity .
activity:extract-999 prov:used chunk:123-1-1 .
activity:extract-999 prov:wasAssociatedWith tg:KnowledgeExtractor .
activity:extract-999 tg:componentVersion "2.1.0" .
activity:extract-999 tg:llmModel "claude-3" .
activity:extract-999 tg:ontology <http://example.org/ontologies/business-v1> .

التضمين (يتم تخزينه في مخزن المتجهات، وليس في مخزن الثلاثيات):

يتم تخزين التضمينات في مخزن المتجهات مع البيانات الوصفية، وليس كـ RDF triples. يحتوي كل سجل تضمين على:

الحقل	الوصف	مثال
vector	متجه التضمين	[0.123, -0.456, ...]
entity	عنوان URI للعقدة التي يمثلها التضمين	entity:JohnSmith
chunk_id	الجزء المصدر (الأصل)	chunk:123-1-1
model	نموذج التضمين المستخدم	text-embedding-ada-002
component_version	إصدار مُحسِّن التضمين (TG embedder)	1.0.0

يربط الحقل entity التضمين بالرسم البياني المعرفي (عنوان URI للعقدة). يوفر الحقل chunk_id معلومات عن الأصل إلى الجزء المصدر، مما يتيح التنقل صعودًا في الرسم البياني الموجه (DAG) إلى المستند الأصلي.

امتدادات مساحة اسم TrustGraph

محددات مخصصة ضمن مساحة الاسم tg: لبيانات وصفية خاصة بالاستخراج:

المحدد	النطاق	الوصف
tg:contains	Subgraph	يشير إلى ثلاثية موجودة في هذا الرسوم البيانية الفرعية للاستخراج
tg:pageCount	Document	العدد الإجمالي لصفحات المستند المصدر
tg:mimeType	Document	نوع MIME للمستند المصدر
tg:pageNumber	Page	رقم الصفحة في المستند المصدر
tg:chunkIndex	Chunk	فهرس الجزء داخل الأصل
tg:charOffset	Chunk	الإزاحة الحرفية في النص الأصل
tg:charLength	Chunk	طول الجزء بالأحرف
tg:chunkSize	Activity	حجم الجزء المُكوَّن
tg:chunkOverlap	Activity	التداخل المُكوَّن بين الأجزاء
tg:componentVersion	Activity	إصدار مكون TG
tg:llmModel	Activity	نموذج LLM المستخدم للاستخراج
tg:ontology	Activity	عنوان URI للأنطولوجيا المستخدم لتوجيه الاستخراج
tg:embeddingModel	Activity	النموذج المستخدم للتضمينات
tg:sourceText	Statement	النص الدقيق الذي تم استخراج ثلاثية منه
tg:sourceCharOffset	Statement	الإزاحة الحرفية داخل الجزء حيث يبدأ النص المصدر
tg:sourceCharLength	Statement	طول النص المصدر بالأحرف

تهيئة المفردات (لكل مجموعة)

الرسم البياني المعرفي محايد للأنطولوجيا ويبدأ فارغًا. عند كتابة بيانات سلالة PROV-O إلى مجموعة لأول مرة، يجب تهيئة المفردات باستخدام تسميات RDF لجميع الفئات والمحددات. يضمن ذلك عرضًا قابلاً للقراءة بواسطة الإنسان في الاستعلامات وواجهة المستخدم.

فئات PROV-O:

prov:Entity rdfs:label "Entity" .
prov:Activity rdfs:label "Activity" .
prov:Agent rdfs:label "Agent" .

المُتَعَدِّيات (Predicates) الخاصة بـ PROV-O:

prov:wasDerivedFrom rdfs:label "was derived from" .
prov:wasGeneratedBy rdfs:label "was generated by" .
prov:used rdfs:label "used" .
prov:wasAssociatedWith rdfs:label "was associated with" .
prov:startedAtTime rdfs:label "started at" .

عبارات TrustGraph:

tg:contains rdfs:label "contains" .
tg:pageCount rdfs:label "page count" .
tg:mimeType rdfs:label "MIME type" .
tg:pageNumber rdfs:label "page number" .
tg:chunkIndex rdfs:label "chunk index" .
tg:charOffset rdfs:label "character offset" .
tg:charLength rdfs:label "character length" .
tg:chunkSize rdfs:label "chunk size" .
tg:chunkOverlap rdfs:label "chunk overlap" .
tg:componentVersion rdfs:label "component version" .
tg:llmModel rdfs:label "LLM model" .
tg:ontology rdfs:label "ontology" .
tg:embeddingModel rdfs:label "embedding model" .
tg:sourceText rdfs:label "source text" .
tg:sourceCharOffset rdfs:label "source character offset" .
tg:sourceCharLength rdfs:label "source character length" .

ملاحظة حول التنفيذ: يجب أن يكون هذا الإطار اللغوي ذاتي الإعادة - آمنًا للتشغيل عدة مرات دون إنشاء تكرارات. يمكن تشغيله في معالجة المستند الأول في المجموعة، أو كخطوة منفصلة لتهيئة المجموعة.

أصل الجزء الفرعي (طموح)

للحصول على معلومات تفصيلية حول الأصل، سيكون من المفيد تسجيل المكان الدقيق داخل جزء معين حيث تم استخراج الثلاثي. هذا يسمح بـ:

تسليط الضوء على النص المصدر الدقيق في واجهة المستخدم. التحقق من دقة الاستخراج مقابل المصدر. تصحيح جودة الاستخراج على مستوى الجملة.

مثال مع تتبع الموضع:

# The extracted triple
entity:JohnSmith rel:worksAt entity:AcmeCorp .

# Subgraph with sub-chunk provenance
subgraph:001 tg:contains <<entity:JohnSmith rel:worksAt entity:AcmeCorp>> .
subgraph:001 prov:wasDerivedFrom chunk:123-1-1 .
subgraph:001 tg:sourceText "John Smith has worked at Acme Corp since 2019" .
subgraph:001 tg:sourceCharOffset 1547 .
subgraph:001 tg:sourceCharLength 46 .

مثال مع نطاق نص (بديل):

subgraph:001 tg:contains <<entity:JohnSmith rel:worksAt entity:AcmeCorp>> .
subgraph:001 prov:wasDerivedFrom chunk:123-1-1 .
subgraph:001 tg:sourceRange "1547-1593" .
subgraph:001 tg:sourceText "John Smith has worked at Acme Corp since 2019" .

اعتبارات التنفيذ:

قد لا توفر استخراج البيانات باستخدام نماذج اللغة الكبيرة (LLM) بشكل طبيعي مواقع الأحرف. يمكن توجيه نموذج اللغة الكبيرة لإرجاع الجملة/العبارة المصدرية بالإضافة إلى الثلاثيات المستخرجة. بدلاً من ذلك، يمكن إجراء معالجة لاحقة لمطابقة الكيانات المستخرجة بشكل تقريبي مع النص المصدر. يوجد مقايضة بين تعقيد الاستخراج ودقة تتبع المصدر. قد يكون من الأسهل تحقيق ذلك باستخدام طرق الاستخراج المنظمة بدلاً من استخراج البيانات المجردة باستخدام نماذج اللغة الكبيرة.

هذا الأمر مصنف على أنه طموح - يجب تنفيذ تتبع المصدر على مستوى المقطع أولاً، مع تتبع المقطع الفرعي كتحسين مستقبلي إذا كان ذلك ممكنًا.

نموذج التخزين المزدوج

يتم بناء رسم بياني لتتبع المصدر بشكل تدريجي أثناء تدفق المستندات عبر مسار العمل:

التخزين	ما يتم تخزينه	الغرض
أمين المكتبة	محتوى المستند + روابط الأبناء	استرجاع المحتوى، حذف متسلسل
الرسم البياني للمعرفة	حواف الأبناء، وبيانات وصفية	استعلامات تتبع المصدر، إسناد الحقائق

تحتفظ كلا التخزينين بنفس هيكل الرسم البياني. يحتوي أمين المكتبة على المحتوى، بينما يحتوي الرسم البياني على العلاقات ويمكنه تمكين استعلامات التصفح.

المبادئ الأساسية للتصميم

1. معرف المستند كوحدة تدفق - تمرر المعالجات المعرفات، وليس المحتوى. يتم استرداد المحتوى من أمين المكتبة عند الحاجة.

2. الإرسال مرة واحدة من المصدر - يتم كتابة البيانات الوصفية في الرسم البياني مرة واحدة عند بدء المعالجة، وليس بشكل متكرر في المراحل اللاحقة.

3. نمط معالج متسق - يتبع كل معالج نفس النمط: الاستقبال/الاسترداد/الإنتاج/الحفظ/الإرسال/التوجيه.

4. بناء تدريجي للرسم البياني - يضيف كل معالج مستواه إلى الرسم البياني. يتم بناء سلسلة تتبع المصدر الكاملة بشكل تدريجي.

5. تحسين ما بعد التقطيع - بعد التقطيع، تحمل الرسائل كلاً من المعرف والمحتوى. تكون القطع صغيرة (2-4 كيلوبايت)، لذلك يؤدي تضمين المحتوى إلى تجنب عمليات الذهاب والإياب غير الضرورية إلى أمين المكتبة مع الحفاظ على تتبع المصدر عبر المعرف.

مهام التنفيذ

تغييرات أمين المكتبة

الحالة الحالية

يبدأ معالجة المستند عن طريق إرسال معرف المستند إلى المعالج الأول. لا يوجد اتصال بمخزن الثلاثيات - يتم تجميع البيانات الوصفية مع مخرجات الاستخراج. add-child-document ينشئ روابط الأبناء من مستوى واحد. list-children يُرجع فقط الأبناء المباشرين.

التغييرات المطلوبة

1. واجهة جديدة: اتصال بمخزن الثلاثيات

يحتاج أمين المكتبة إلى إرسال حواف بيانات وصفية للمستند مباشرة إلى الرسم البياني للمعرفة عند بدء المعالجة. إضافة عميل/ناشر مخزن الثلاثيات إلى خدمة أمين المكتبة. عند بدء المعالجة: إرسال بيانات وصفية للمستند الجذر كحواف في الرسم البياني (مرة واحدة).

2. مفردات أنواع المستندات

توحيد قيم document_type لأبناء المستند: source - المستند الذي تم تحميله أصلاً. page - صفحة مستخرجة من المصدر (PDF، إلخ). chunk - جزء نصي مشتق من الصفحة أو المصدر.

ملخص تغييرات الواجهة

الواجهة	التغيير
مخزن الثلاثيات	اتصال صادر جديد - إرسال حواف بيانات وصفية للمستند
بدء المعالجة	إرسال البيانات الوصفية إلى الرسم البياني قبل توجيه معرف المستند

تغييرات مستخرج PDF

الحالة الحالية

يتلقى محتوى المستند (أو يتدفق المستندات الكبيرة). يستخرج النص من صفحات PDF. يوجه محتوى الصفحة إلى وحدة التقطيع. لا يوجد تفاعل مع أمين المكتبة أو مخزن الثلاثيات.

التغييرات المطلوبة

1. واجهة جديدة: عميل أمين المكتبة

يحتاج مستخرج PDF إلى حفظ كل صفحة كمستند تابع في أمين المكتبة. إضافة عميل أمين المكتبة إلى خدمة مستخرج PDF. لكل صفحة: استدعاء add-child-document مع parent = معرف المستند الجذر.

2. واجهة جديدة: اتصال بمخزن الثلاثيات

يحتاج مستخرج PDF إلى إرسال حواف الأبناء إلى الرسم البياني للمعرفة. إضافة عميل/ناشر مخزن الثلاثيات. لكل صفحة: إرسال حافة تربط مستند الصفحة بالمستند الأصل.

3. تغيير تنسيق الإخراج

بدلًا من إرسال محتوى الصفحة مباشرةً، أرسل مُعرّف مستند الصفحة. سيقوم المقطع (Chunker) بجلب المحتوى من أمين المكتبة (librarian) باستخدام المعرّف.

ملخص التغييرات في الواجهة

الواجهة	التغيير
أمين المكتبة (Librarian)	واجهة تصدير جديدة - حفظ المستندات الفرعية
قاعدة البيانات الثلاثية (Triple store)	واجهة تصدير جديدة - إرسال علاقات الأبناء والبنات
رسالة الإخراج	تغيير من المحتوى إلى مُعرّف المستند

تغييرات المقطع (Chunker)

الحالة الحالية

يستقبل محتوى الصفحة/النص يقسم إلى أجزاء (chunks) يرسل محتوى الجزء إلى المعالجات اللاحقة لا يوجد تفاعل مع أمين المكتبة أو قاعدة البيانات الثلاثية

التغييرات المطلوبة

1. تغيير طريقة معالجة الإدخال

استقبل مُعرّف المستند بدلًا من المحتوى، وجلبه من أمين المكتبة. أضف عميل أمين المكتبة إلى خدمة المقطع. جلب محتوى الصفحة باستخدام مُعرّف المستند.

2. واجهة جديدة: عميل أمين المكتبة (للكتابة)

احفظ كل جزء كمستند فرعي في أمين المكتبة. لكل جزء: استدعِ add-child-document مع parent = page document ID

3. واجهة جديدة: اتصال بقاعدة البيانات الثلاثية

أرسل علاقات الأبناء والبنات إلى الرسم البياني المعرفي. أضف عميل/ناشر قاعدة البيانات الثلاثية. لكل جزء: أرسل علاقة تربط مستند الجزء بمستند الصفحة.

4. تغيير تنسيق الإخراج

أرسل كلاً من مُعرّف مستند الجزء ومحتوى الجزء (تحسين لاحق للمقطع). تستقبل المعالجات اللاحقة المعرّف لأغراض التتبع + المحتوى للعمل به.

ملخص التغييرات في الواجهة

الواجهة	التغيير
رسالة الإدخال	تغيير من المحتوى إلى مُعرّف المستند
أمين المكتبة (Librarian)	واجهة تصدير جديدة (قراءة وكتابة) - جلب المحتوى، حفظ المستندات الفرعية
قاعدة البيانات الثلاثية (Triple store)	واجهة تصدير جديدة - إرسال علاقات الأبناء والبنات
رسالة الإخراج	تغيير من المحتوى فقط إلى المعرّف + المحتوى

تغييرات مُستخرج المعرفة (Knowledge Extractor)

الحالة الحالية

يستقبل محتوى الجزء يستخرج الثلاثيات والتضمينات يرسل إلى قاعدة البيانات الثلاثية ومخزن التضمينات subjectOf تشير العلاقة إلى المستند ذي المستوى الأعلى (وليس الجزء)

التغييرات المطلوبة

1. تغيير طريقة معالجة الإدخال

استقبل مُعرّف مستند الجزء بالإضافة إلى المحتوى. استخدم مُعرّف الجزء لأغراض الربط (المحتوى مدرج بالفعل كتحسين).

2. تحديث أثر الثلاثيات

اربط الثلاثيات المستخرجة بالجزء (وليس المستند ذي المستوى الأعلى). استخدم التجريد لإنشاء حافة تشير إلى الحافة subjectOf العلاقة: ثلاثية → مُعرّف مستند الجزء الاستخدام الأول للدعم الحالي للتجريد

3. تحديث أثر التضمينات

اربط معرفات كيانات التضمين بالجزء. أرسل حافة: معرف كيان التضمين → مُعرّف مستند الجزء

ملخص التغييرات في الواجهة

الواجهة	التغيير
رسالة الإدخال	توقع مُعرّف الجزء + المحتوى (وليس المحتوى فقط)
قاعدة البيانات الثلاثية	استخدم التجريد لأثر الثلاثية → الجزء
أثر التضمين	اربط معرف الكيان → معرف الجزء

المراجع

أثر وقت الاستعلام: docs/tech-specs/query-time-provenance.md معيار PROV-O لنمذجة الأثر البيانات الوصفية المصدر الحالية في الرسم البياني المعرفي (تحتاج إلى تدقيق)