تركيب المعارف

# تجميع المعرفة

الخطوة الأخيرة في البحث بالمؤسسات. تأخذ النتائج الخام من مصادر متعددة وتنتج إجابة متماسكة وموثوقة.

## الهدف

تحويل هذا: ``` ~~نتيجة الدردشة: "قالت سارة في #eng: 'دعونا نختار REST، GraphQL زائد عن الحاجة لحالتنا'" ~~نتيجة البريد الإلكتروني: "الموضوع: قرار API — بريد سارة يؤكد نهج REST مع المنطق" ~~نتيجة التخزين السحابي: "مستند تصميم API v3 — تم تحديث القسم 2 ليعكس قرار REST" ~~نتيجة متتبع المشروع: "المهمة: إضفاء الصيغة النهائية على نهج API — تم وضع علامة مكتملة بواسطة سارة" ```

إلى هذا: ``` قررت الفريق استخدام REST بدلاً من GraphQL لإعادة تصميم API. اتخذت سارة هذا القرار، مشيرة إلى أن GraphQL كان زائداً عن الحاجة للحالة الحالية. تمت مناقشة هذا في #engineering يوم الثلاثاء، وتم تأكيده عبر البريد الإلكتروني يوم الأربعاء، وتم تحديث مستند التصميم ليعكس القرار. تم وضع علامة على مهمة متتبع المشروع ذات الصلة كمكتملة.

المصادر: - ~~الدردشة: #engineering (14 يناير) - ~~البريد الإلكتروني: "قرار API" من سارة (15 يناير) - ~~التخزين السحابي: "مستند تصميم API v3" (تم التحديث 15 يناير) - ~~متتبع المشروع: "إضفاء الصيغة النهائية على نهج API" (مكتمل 15 يناير) ```

## إزالة التكرار

### إزالة التكرار عبر المصادر

غالباً ما تظهر نفس المعلومات في أماكن متعددة. حدد الحالات المكررة وادمجها:

**الإشارات التي تدل على أن النتائج تتعلق بنفس الموضوع:** - نفس أو محتوى نصي متشابه جداً - نفس المؤلف/المرسل - طوابع زمنية في نطاق ضيق (نفس اليوم أو أيام متتالية) - إشارات إلى نفس الكيان (اسم المشروع، المستند، القرار) - مصدر يشير إلى آخر ("كما تمت مناقشته في ~~الدردشة"، "وفقاً للبريد الإلكتروني"، "انظر المستند")

**كيفية الدمج:** - دمج في عنصر سردي واحد - الاستشهاد بجميع المصادر حيث ظهرت - استخدام النسخة الأكثر اكتمالاً كنص أساسي - إضافة التفاصيل الفريدة من كل مصدر

### أولويات إزالة التكرار

عند وجود نفس المعلومات في مصادر متعددة، فضّل: ``` 1. النسخة الأكثر اكتمالاً (السياق الأشمل) 2. المصدر الأكثر سلطة (المستند الرسمي > الدردشة) 3. النسخة الأحدث (أحدث تحديث يفوز للمعلومات المتطورة) ```

### ما لا يجب إزالة تكراره

احتفظ بعناصر منفصلة عندما: - يتم مناقشة نفس الموضوع لكن بخلاصات مختلفة - يعبر أشخاص مختلفون عن وجهات نظر مختلفة - تطورت المعلومات بشكل ذو معنى بين المصادر (v1 مقابل v2 من القرار) - يتم تمثيل فترات زمنية مختلفة

## الاستشهاد وإسناد المصدر

يجب أن تكون كل ادعاء في الإجابة المجمعة قابلاً للإرجاع إلى مصدر.

### صيغة الاستشهاد

مباشرة للإشارات المباشرة: ``` أكدت سارة نهج REST في بريدها الإلكتروني يوم الأربعاء. تم تحديث مستند التصميم ليعكس هذا (~~التخزين السحابي: "مستند تصميم API v3"). ```

قائمة المصادر في النهاية للاكتمال: ``` المصادر: - ~~الدردشة: مناقشة #engineering (14 يناير) — خيط القرار الأولي - ~~البريد الإلكتروني: "قرار API" من سارة تشن (15 يناير) — التأكيد الرسمي - ~~التخزين السحابي: "مستند تصميم API v3" آخر تعديل 15 يناير — المواصفات المحدثة ```

### قواعد الاستشهاد

- اذكر دائماً نوع المصدر (~~الدردشة، ~~البريد الإلكتروني، ~~التخزين السحابي، إلخ) - ضمّن الموقع المحدد (القناة، المجلد، الخيط) - ضمّن التاريخ أو الوقت النسبي - ضمّن المؤلف عند الصلة - ضمّن عناوين المستندات/الخيوط عند توفرها - للدردشة~~، اذكر اسم القناة - للبريد الإلكتروني~~، اذكر سطر الموضوع والمرسل - للتخزين السحابي~~، اذكر عنوان المستند

## مستويات الثقة

لا تتمتع جميع النتائج بنفس درجة الموثوقية. قيّم الثقة بناءً على:

### الطزاجة

| الحداثة | تأثير الثقة | |--------|-----------| | اليوم / الأمس | ثقة عالية للحالة الحالية | | هذا الأسبوع | ثقة جيدة | | هذا الشهر | ثقة معتدلة — قد تكون الأمور قد تغيرت | | أقدم من شهر | ثقة منخفضة — اشر إلى احتمالية عدم الحداثة |

لاستعلامات الحالة، أثقل الوزن على الحداثة. لاستعلامات السياسة/الحقائق، الحداثة أقل أهمية.

### السلطة

| نوع المصدر | مستوى السلطة | |-----------|-------------| | Wiki رسمي / قاعدة معرفة | الأعلى — منسقة ومدارة | | المستندات المشتركة (النسخ النهائية) | عالية — منشورة عن قصد | | إعلانات البريد الإلكتروني | عالية — تواصل رسمي | | ملاحظات الاجتماع | عالية معتدلة — قد تكون غير مكتملة | | رسائل الدردشة (خلاصات الخيط) | معتدلة — غير رسمية لكن فعلية | | رسائل الدردشة (في منتصف الخيط) | منخفضة — قد لا تعكس الموقف النهائي | | المستندات المسودة | منخفضة — غير نهائية | | تعليقات المهمة | سياقية — تعتمد على معلق |

### التعبير عن الثقة

عندما تكون الثقة عالية (مصادر متعددة جديدة وسلطوية تتفق): ``` قررت الفريق استخدام REST لإعادة تصميم API. [بيان مباشر] ```

عندما تكون الثقة معتدلة (مصدر واحد أو قديمة نوعاً ما): ``` بناءً على المناقشة في #engineering الشهر الماضي، كانت الفريق تميل نحو استخدام REST لإعادة تصميم API. قد يكون هذا قد تطور منذ ذلك الحين. ```

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