كيف يختلف تدقيق الجودة عن عمل profile لـ dataset؟

الـ profile يجيب عن "ماذا في هذا الملف؟" — توجيه سريع قبل أن تحلّل. تدقيق الجودة يجيب عن "هل تصلح هذه البيانات لتغذية قرار؟" — اختبار منهجي للاكتمال والصلاحية والتفرّد والتكامل المرجعي والحداثة والانحراف مقابل قواعد منصوص عليها، ينتهي بحكم بالمضيّ/التوقّف. تعمل profile لكل ملف جديد؛ وتدقّق حين تكون كلفة الرقم الخاطئ مرتفعة بما يكفي ألّا يصمد "بدا سليمًا" أمام اعتراض.

متى يستحقّ الأمر إجراء تدقيق كامل بدل فحص سريع؟

حين تكون البيانات على وشك تغذية شيء بمخاطر حقيقية — رقم لمجلس الإدارة، أو تقرير متكرّر تتراكم أخطاؤه، أو model، أو مُسلَّم خارجي. المخاطر تضبط المعيار: استكشاف داخلي تقريبي لا يحتاج هذا، لكن أي شيء سيتصرّف بناءً عليه صاحب مصلحة أو قد يشكّك فيه مدقّق يحتاجه. القاعدة العامة هي كلفة الخطأ — الكلفة المرتفعة تستحقّ الأربعين دقيقة.

هل سيصلح Claude مشاكل جودة البيانات التي يجدها؟

لا، ولا ينبغي له دون إذنك. مهمّة التدقيق إبراز المشاكل بدرجات خطورة وأمثلة؛ أما إصلاحها — إزالة تكرار مفتاح، أو إسقاط صفوف خارج النطاق، أو حلّ تناقض — فيغيّر البيانات وهو قرار يتّخذه المالك رسميًا. ينبّه Claude ويقترح؛ وإنسان يقرّر أي إصلاحات تُطبَّق، كي لا تصير بطاقة التقييم خضراء لأن شيئًا غُيّر بهدوء.

هل اجتياز التدقيق يعني أن الأرقام صحيحة؟

لا — يعني أن البيانات تلتزم بالقواعد التي وضعتها، وهو ضروري لكنه غير كافٍ. لا يستطيع التدقيق أن يخبرك بأن القواعد تلتقط ما يعنيه العمل فعلًا، أو أن رقمًا حسن التنسيق يعكس الواقع. هو يصطاد الإخفاقات القابلة للتجنّب — الصفوف الناقصة، والمفاتيح المكسورة، والتحميلات القديمة — كي لا تنتج إجابة خاطئة واثقة. ما زلت تراجع النتائج مقابل إجماليات معروفة؛ التدقيق فقط يزيل صنفًا كاملًا من أخطاء المدخلات أولًا.

دقّق جودة dataset قبل أن تثق به

متى تلجأ إلى هذا

ثمّة dataset على وشك أن يغذّي شيئًا مهمًّا — رقمًا لمجلس الإدارة، أو تقريرًا متكرّرًا، أو model، أو dashboard لأصحاب المصلحة — و"تبدو سليمة" ليست معيارًا. البيانات السيّئة لا تعلن عن نفسها أبدًا؛ بل تنتج بهدوء إجابة خاطئة واثقة تمرّ خلال المراجعة لأن لا أحد فحص المدخلات، بل المخرجات فقط. تدقيق الجودة هو النسخة المنهجية من ذلك الفحص: الاكتمال، والصلاحية، والتفرّد، والاتّساق، والتكامل المرجعي، والحداثة، والانحراف، كلٌّ منها مُختبَر مقابل قاعدة منصوص عليها، مُنتِجًا حكمًا بمدى الصلاحية للاستخدام مع درجات خطورة. إنه أداة أثقل من profile سريع — تلجأ إليه حين تكون كلفة الرقم الخاطئ مرتفعة بما يكفي ألّا يصمد معها "ألقيت نظرة فبدت جيدة".

جهّز هذا أولًا

الـ dataset كما سيُستخدَم — الملف أو الجدول الفعلي الذي سيغذّي التقرير أو الـ model، لا عيّنة منه، لأن المشاكل التي تهمّك كثيرًا ما تسكن في الصفوف التي لم تفحصها يدويًا.
ما الذي على وشك أن يغذّيه، لأن المخاطر هي التي تضبط المعيار — بيانات جيدة بما يكفي لنظرة داخلية تقريبية ليست جيدة بما يكفي لرقم لمجلس الإدارة أو model في production.
القواعد التي ينبغي أن تلتزم بها البيانات: أي column هو المفتاح الفريد، وما النطاقات والقيم المسموح بها الصالحة، وما الذي ينبغي أن يشير إليه foreign key، وما مدى الحداثة المطلوبة. والإصدار السابق إن أردت فحص الانحراف.

الـ workflow

حدّد ما يعنيه "الجيد" لهذه البيانات — القواعد

افتح المجلد الذي يضمّ الـ dataset (وآخر تحميل، إن كان لديك) في Claude Desktop واسأل في المحادثة — دون الحاجة إلى terminal. قبل اختبار أي شيء، دوّن التوقّعات. تدقيق بلا قواعد منصوص عليها ليس إلا profile آخر؛ القواعد هي ما يحوّل "تبدو سليمة" إلى نجاح/فشل.

أنت تطلب

أنا على وشك استخدام هذا الـ dataset لـ [تغذية تقرير مجلس الإدارة الشهري]. قبل فحص أي شيء، ساعدني في كتابة قواعد الجودة التي يجب أن يجتازها: أي column هو المفتاح الفريد، وأي columns لا يمكن أن تكون null أبدًا، والنطاقات والقيم المسموح بها الصالحة لكل column، وأي foreign key يجب أن يشير إلى جدول آخر، ومدى الحداثة المطلوب في البيانات. اقترح قواعد منطقية مما تراه، ونبّهني على أي قاعدة تخمّنها كي أؤكّدها.

ما تحصل عليه مجموعة قواعد مكتوبة — "order_id فريد ولا يكون null أبدًا؛ amount >= 0؛ status in {paid, pending, refunded}؛ customer_id يجب أن يوجد في customers؛ يجب أن تغطّي البيانات حتى أمس" — مع تنبيه على القواعد المخمَّنة لتصادق عليها. الآن صار هناك معيار تختبر مقابله.

القواعد هي التدقيق. بدونها تعود إلى التخمين بالنظر؛ ومعها، لكل فحص نجاح أو فشل واضح يثق به المراجِع.
افحص الاكتمال والصلاحية

ابدأ بأرخص بُعدين وأعلاهما مردودًا: هل ينقص شيء، وهل خرج شيء عن حدوده. هذان يصطادان الاستيراد الذي حُمّل نصفه، والـ column الذي يحمل قيمة لا ينبغي أن يحملها.

أنت تطلب

أجرِ فحوص الاكتمال والصلاحية مقابل القواعد. لكل column: عدد قيم الـ null ونسبتها (نبّه على أي column يكسر قاعدة 'لا يكون null أبدًا')؛ والنوع (نبّه على القيم التي لا تطابقه، كنصّ في column رقمي)؛ وأي قيمة خارج النطاق أو المجموعة المسموح بها (مبالغ سالبة، قيم status ليست في القائمة المسموح بها، تواريخ خارج النافذة المتوقّعة). أعطِني جدولًا بكل فشل مع عدّاد وبضعة صفوف كأمثلة.

ما تحصل عليه جدول إخفاقات: "amount: ‏31 قيمة سالبة (refunds؟ أكّد)؛ status: ‏12 صفًا = 'cancelled'، ليست في المجموعة المسموح بها؛ signup_date: ‏4 صفوف في 1970 (خطأ epoch-zero). region فيه null بنسبة 18% — مسموح به." كل فشل مع عدّاد وأمثلة كي تحكم عليه، لا أن تراه فقط.
افحص التفرّد والاتّساق والتكامل المرجعي

الآن الفحوص البنيوية — تلك التي تكسر الـ joins وتضاعف الإجماليات بصمت. المفاتيح المكرّرة، والـ foreign keys التي تشير إلى لا شيء، والحقول التي يناقض بعضها بعضًا داخل الصف الواحد.

أنت تطلب

افحص البنية: هل توجد قيم مكرّرة في عمود المفتاح (order_id)، وأي صفوف مكرّرة بالكامل؟ هل كل customer_id في هذا الملف موجود في customers.csv — اسرد اليتامى؟ وافحص الاتّساق داخل الصف: الصفوف التي يناقض منطقها نفسه (status = 'refunded' لكن amount > 0، و end_date قبل start_date، وإجمالي لا يساوي مجموع أجزائه). عُدّ وأظهِر أمثلة لكلٍّ منها.

ما تحصل عليه "‏47 قيمة order_id مكرّرة (محاولات إعادة — هل أزيل التكرار أم أبقي؟)؛ ‏130 قيمة customer_id بلا عميل مطابق (يتامى)؛ ‏9 صفوف فيها status='refunded' لكن amount موجب (تناقض)." المشاكل البنيوية التي كانت ستفسد أي join أو إجمالي بهدوء، أُبرِزت قبل أن تفعل.

المفاتيح المكرّرة والمراجع اليتيمة هي الأخطاء التي تنتج نتيجة نظيفة المظهر لكنها خاطئة لاحقًا. هي بالضبط ما يفوّته profile سريع ويرثه تقرير.
افحص الحداثة والانحراف مقابل آخر تحميل

قد يجتاز dataset كل قاعدة ثابتة ويظلّ خاطئًا إن كان قديمًا أو تغيّر شكله بصمت. قارن مقابل الإصدار السابق لاصطياد تغيّر الـ schema، أو الهبوط الحادّ في الحجم، أو الانزياح في التوزيع الذي لم يعلنه أحد.

أنت تطلب

قارن هذا التحميل مقابل ملف الشهر الماضي. هل هو حديث بما يكفي — هل يغطّي حتى التاريخ الذي أتوقّعه، بلا أيام حديثة ناقصة؟ هل تغيّر عدد الصفوف أكثر مما تتوقّع؟ هل ظهر أي column أو اختفى أو غيّر نوعه؟ وهل انزاح توزيع أي مفتاح بحدّة — فئة كانت 5% من الصفوف صارت 40%، أو معدّل null قفز؟ نبّه على أي شيء يوحي بتغيّر upstream لا بتغيّر تجاري حقيقي.

ما تحصل عليه "حديث حتى أمس. عدد الصفوف +12%، معقول. لكن ظهر column جديد experiment_id، و source فيه null بنسبة 40% من الصفوف مقابل 12% الشهر الماضي — على الأرجح تغيّر في الـ tracking عند الـ upstream، لا انزياح تجاري." تغيّر الـ pipeline الصامت اصطيد قبل أن يُقرأ كاتجاه.
أنتِج بطاقة تقييم الصلاحية للاستخدام وقرار المضيّ/التوقّف

اجمع كل ما تبيّن في بطاقة تقييم واحدة، ورتّبه حسب الخطورة، وافرض الحكم: هل تصلح هذه البيانات لتغذية ما هي على وشك تغذيته، كما هي، أم بإصلاحات، أم ليس بعد؟ قائمة بالمشاكل ليست قرارًا — الحكم هو القرار.

أنت تطلب

جمّع بطاقة تقييم لجودة البيانات في صفحة واحدة: كل فحص، نجاح أو فشل، مع درجة خطورة (blocker / warning / note) والعدّاد. ثم أعطِني حكمًا واضحًا لتغذية [تقرير مجلس الإدارة]: المضيّ، أو المضيّ-مع-إصلاحات (اسرد بالضبط ما يجب إصلاحه أولًا)، أو التوقّف (وسبب ذلك). افصِل الـ blockers التي يجب إصلاحها عن الـ notes التي لا بأس بالشحن معها. احفظها باسم data-quality-report.md.

ما تحصل عليه ملف data-quality-report.md يحوي بطاقة تقييم مرتّبة وحكمًا صريحًا: "المضيّ مع إصلاحات — blockers: أزِل تكرار 47 قيمة order_id، وحُلّ تناقضات الـ refund التسعة. warnings: العملاء اليتامى (متوقّع، حسابات محذوفة). بعدها آمنة لتقرير مجلس الإدارة." قرار يمكنك الدفاع عنه، لا كومة ممّا تبيّن.

تقسيم الخطورة هو المغزى. ليس كل null هو blocker — إجبار كل ما يتبيّن على أن يكون blocker / warning / note هو ما يمنع التدقيق من إطلاق إنذار كاذب أو تمرير مشاكل حقيقية.

اجعله ملكك

بوّابة لـ pipeline (Power Track): بمجرد أن تستقرّ القواعد، سلّمها إلى scheduled agent أو /audit command (انظر تبويب Features) يجري التدقيق على كل تحميل جديد ولا يخطرك إلا حين يظهر blocker — كي لا يجري التقرير المتكرّر على بيانات مكسورة بصمت أبدًا.
قبل عمل join مباشرة: أجرِ هذا على كل مُدخَل قبل حوّل ملفين فوضويين إلى dataset واحد جدير بالثقة — الـ join يرث كل مشكلة جودة في مدخلاته، فالتدقيق أولًا يعني أن اليتامى والمكرّرات معروفون، لا مُكتشَفون في الملف المدموج.
أعِد استخدام القواعد كعقد: مجموعة القواعد التي كتبتها في الخطوة الأولى هي data contract قابل لإعادة الاستخدام — احفظه بجوار الـ dataset كي تُفحَص التوقّعات نفسها في كل مرة، من أي شخص، ويصير لسؤال 'هل هذه البيانات جيدة؟' جواب موثّق.
تسليم ثنائي اللغة: إن كان مالك البيانات يقرأ العربية، فاكتب حكم بطاقة التقييم والـ blockers بالعربية كي يفهم من عليهم إصلاح مشكلة الـ upstream ما الذي فشل بالضبط — اكتبه بالعربية بدل تسليمهم checklist مترجَمة.

انتبه إلى

التدقيق يُبرِز المشاكل؛ ويجب ألّا يصلحها بصمت أبدًا. إزالة تكرار مفتاح أو إسقاط الصفوف خارج النطاق يغيّر البيانات — وهذا قرار يتّخذه المالك رسميًا، لا شيء يفعله Claude بهدوء كي تصير بطاقة التقييم خضراء. نبّه، ثم دع إنسانًا يقرّر الإصلاح.
الخطورة هي كل شيء، وإلا أطلق التدقيق إنذارًا كاذبًا. قد يكون region فيه null بنسبة 18% متوقّعًا تمامًا بينما مفتاح أساسي واحد مكرّر يكون blocker. إجبار كل ما يتبيّن على أن يكون blocker / warning / note هو ما يجعل الحكم جديرًا بالثقة بدل أن يكون جدارًا من الأحمر.
حديث ونظيف ليس كـ صحيح. التدقيق يفحص التزام البيانات بقواعدها — لا يستطيع أن يخبرك بأن القواعد تلتقط ما يعنيه العمل فعلًا، أو أن رقمًا مُنسَّقًا بإتقان يعكس الواقع. إنه بوّابة ضرورية، لا ضمانًا للحقيقة.
قواعد الجودة تحتاج مالكًا، كما تحتاج تعريفات المقاييس. مجموعة قواعد لا يملكها أحد تتقادم — 'النطاق الصالح' الذي كان صحيحًا العام الماضي يمرّر بيانات سيّئة بهدوء هذا العام. أبقِ الـ data contract بجوار قاموس المقاييس، مملوكًا ومراجَعًا، لا مدفونًا في دفتر محلّل واحد.

ستحصل في النهاية على ملف `data-quality-report.md` — كل بُعد جودة مفحوص مقابل قاعدة منصوص عليها، وما تبيّن مرتّب حسب الخطورة، وحكم صريح بالمضيّ / المضيّ-مع-إصلاحات / التوقّف — كي يكسب dataset حقّه في دخول تقرير أو قرار بناءً على أدلّة، ويُصطاد الـ blocker الذي كان سينتج رقمًا خاطئًا واثقًا عند المُدخَل، لا عند المُخرَج.

أسئلة يطرحها الناس

كيف يختلف تدقيق الجودة عن عمل profile لـ dataset؟: الـ profile يجيب عن "ماذا في هذا الملف؟" — توجيه سريع قبل أن تحلّل. تدقيق الجودة يجيب عن "هل تصلح هذه البيانات لتغذية قرار؟" — اختبار منهجي للاكتمال والصلاحية والتفرّد والتكامل المرجعي والحداثة والانحراف مقابل قواعد منصوص عليها، ينتهي بحكم بالمضيّ/التوقّف. تعمل profile لكل ملف جديد؛ وتدقّق حين تكون كلفة الرقم الخاطئ مرتفعة بما يكفي ألّا يصمد "بدا سليمًا" أمام اعتراض.
متى يستحقّ الأمر إجراء تدقيق كامل بدل فحص سريع؟: حين تكون البيانات على وشك تغذية شيء بمخاطر حقيقية — رقم لمجلس الإدارة، أو تقرير متكرّر تتراكم أخطاؤه، أو model، أو مُسلَّم خارجي. المخاطر تضبط المعيار: استكشاف داخلي تقريبي لا يحتاج هذا، لكن أي شيء سيتصرّف بناءً عليه صاحب مصلحة أو قد يشكّك فيه مدقّق يحتاجه. القاعدة العامة هي كلفة الخطأ — الكلفة المرتفعة تستحقّ الأربعين دقيقة.
هل سيصلح Claude مشاكل جودة البيانات التي يجدها؟: لا، ولا ينبغي له دون إذنك. مهمّة التدقيق إبراز المشاكل بدرجات خطورة وأمثلة؛ أما إصلاحها — إزالة تكرار مفتاح، أو إسقاط صفوف خارج النطاق، أو حلّ تناقض — فيغيّر البيانات وهو قرار يتّخذه المالك رسميًا. ينبّه Claude ويقترح؛ وإنسان يقرّر أي إصلاحات تُطبَّق، كي لا تصير بطاقة التقييم خضراء لأن شيئًا غُيّر بهدوء.
هل اجتياز التدقيق يعني أن الأرقام صحيحة؟: لا — يعني أن البيانات تلتزم بالقواعد التي وضعتها، وهو ضروري لكنه غير كافٍ. لا يستطيع التدقيق أن يخبرك بأن القواعد تلتقط ما يعنيه العمل فعلًا، أو أن رقمًا حسن التنسيق يعكس الواقع. هو يصطاد الإخفاقات القابلة للتجنّب — الصفوف الناقصة، والمفاتيح المكسورة، والتحميلات القديمة — كي لا تنتج إجابة خاطئة واثقة. ما زلت تراجع النتائج مقابل إجماليات معروفة؛ التدقيق فقط يزيل صنفًا كاملًا من أخطاء المدخلات أولًا.