البحث الدلالي مقابل البحث النصي

في سطر واحد: ما الفرق بين semantic_search وsearch_content، وأي سؤال يخصّ أيّ أداة.

ما الذي يحلّه هذا

في MCP أكثر من طريقة للعثور على الأشياء، وهي تجيب عن أسئلة مختلفة.

search_content يجد الكلمات التي كتبتها. تتذكّر أنك كتبت «فرن الحروف»، فيسرد لك كل موضع ورد فيه، مع المسار والأسطر المحيطة.

semantic_search يجد المعنى الذي قصدته. اسأل: «أين يطفو حنق الأم إلى السطح؟» فيعيد لك المشهد ولو لم ترد فيه أيٌّ من هاتين الكلمتين.

ومعظم ما تثيره مخطوطة طويلة من أسئلة من النوع الثاني. تتذكّر أن هناك مقطعًا كهذا، ولا تتذكّر بأي كلمات كتبته وقتها.

أيّهما تستخدم

ما تريده	استخدم
كل ملف يرد فيه «ميناء لينزه»	search_content
كل ذكر لشخصية قبل تغيير اسمها	search_content
المشهد الذي تبدأ فيه العلاقة بالتعكّر	semantic_search
هل سبق للكتاب أن فسّر حظر الإبحار	semantic_search
تلك الاستعارة عن المدّ الذي يمحو الحروف، من قبل إعادة الكتابة	semantic_search
هل تناولت قاعدة معرفة الفريق هذه الحالة من قبل	semantic_search

search_content: مطابقة حرفية

search_content({
  "book_token": "bk_...",
  "query": "فرن الحروف",
  "file_types": ["md"],
  "limit": 20
})

لا يفرّق بين الحروف الكبيرة والصغيرة، ويعيد مسار كل ملف مطابق مع الأسطر المحيطة بالنتيجة.

في كتب 4.0، وسيط file_types أهمّ مما يبدو. الملفات المهيكلة (.beats و.timeline و.script و.map و.geomap) تُبحث هي الأخرى، لكن بصيغتها الخام JSON. لذلك قد تعود كلمة شائعة مثل name أو title بصفحة كاملة من أسماء الحقول بدل المحتوى. اكتب file_types: ["md"] حين تريد النثر وحده.

كتب استوديو السيناريو القديمة تعمل بالعكس: الملفات المهيكلة فيها مستثناة افتراضيًا، وتضيف include_structured: true لتشملها. انظر أدوات تسلك سلوكًا مختلفًا مع ملفات بعينها.

semantic_search: مطابقة بالمعنى

semantic_search({
  "book_token": "bk_...",
  "query": "المشهد الذي تشكّ فيه شن يان في أبيها لأول مرة",
  "limit": 10
})

ثلاثة وسائط: الكتاب، وسؤال بلغة طبيعية، وعدد النتائج (10 افتراضيًا، بحدّ أقصى 50).

كل نتيجة تحمل أربعة عناصر: رقم الفقرة بعلامة §، ورمز الملف، والمقطع نفسه، ودرجة التشابه. ورقم § مرساة قابلة للاقتباس، فيقول لك الـ AI «هذا في الفصل 3، §4» بدل أن يشير بيده إلى منتصف الكتاب.

من أين يأتي الفهرس

عند أول بحث، يقسّم Slima محتوى آخر commit في الكتاب إلى فقرات ويفهرسها. وبعدها لا يعيد الحساب إلا لما تغيّر، فالملفات الثابتة لا تكلّف شيئًا. لذلك يكون البحث الأول في كتاب ضخم أبطأ مما يليه.

الكتاب الكبير الذي لم يُفهرس قط يُحال إلى بناء في الخلفية. ذلك البحث يعود فارغًا — لا بمعنى «لا نتائج» بل بمعنى «لم يُبنَ بعد». ابحث مرة أخرى بعد قليل وستجد النتائج.

يكلّف قليلًا

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

ثلاثة أمور لا يقدر عليها

• إيجاد سلسلة نصية بعينها. للكلمة الدقيقة أو علامة الترقيم، استخدم search_content.
• إيجاد نصّ لم يدخل commit بعد. الفهرس مبني من الـ commits. الفقرة التي كتبها المؤلف في التطبيق قبل ثوانٍ ولم تُحفظ في commit ليست هناك.
• الوصول إلى ملفات المهارات السرّية في الفريق. تلك لا تُفهرس أصلًا، فالتشابه الدلالي ليس بابًا خلفيًا إليها.

أين يثبت جدواه: قاعدة معرفة الفريق

قاعدة معرفة الفريق قد تضمّ عشرات القواعد الداخلية والقرارات المستقرّة وتفاصيل أعمال سابقة. وهناك تحديدًا، الفرق بين البحث الحرفي والبحث الدلالي هو الفرق بين التصفّح والسؤال: لم تعد بحاجة إلى معرفة الملف الذي كُتب فيه الأمر ولا العنوان الذي وُضع تحته. يكفي أن تسأل: «هل ثبّتنا اسم العملة في هذا العالم؟»

ذات صلة

• Docs: أدوات الملفات
• Docs: أدوات الملاحظات والتعليقات
• Docs: أدوات تسلك سلوكًا مختلفًا مع ملفات بعينها
• Docs: البحث والاستبدال