ساخت گراف دانش از متن خام؛ از انبوه سند تا شبکه‌ای که می‌شود از آن پرسید

در یک شرکت پیمانکاری در تهران، پرسش ساده‌ای روی میز مدیر پروژه مانده است: «از میان پیمانکارانی که در فاز دوم پالایشگاه با ما کار کردند، کدام‌ها در پروژه‌های دیگرمان هم حضور داشته‌اند و با چه نقشی؟» جواب این سوال، جایی در آرشیو شرکت هست: میان هشتصد قرارداد، صورت‌جلسه، نامهٔ اداری و گزارش پیشرفت. اما هیچ‌کس آن را «نمی‌داند»، چون جواب در یک سند واحد نیست؛ تکه‌تکه در ده‌ها سند پخش شده و فقط وقتی معنا پیدا می‌کند که تکه‌ها به هم وصل شوند.

راه‌حل اول که همه امتحان می‌کنند این است که کل آرشیو را به یک سامانهٔ جست‌وجوی معنایی بدهند و سوال را بپرسند. نتیجه معمولاً چند تکهٔ مرتبط است که هر کدام بخشی از جواب را دارند و هیچ‌کدام کل آن را. جست‌وجو برای «این سند چه می‌گوید» ساخته شده، نه برای «این دو نفر چه ربطی به هم دارند». سوال‌هایی که باید دو یا سه پرش میان موجودیت‌ها انجام دهند، ساختار می‌خواهند؛ و ساختن آن ساختار از متن خام، دقیقاً کاری است که کوک‌بوک رسمی آنتروپیک در راهنمای ساخت گراف دانش پله‌پله نشان می‌دهد. این درس، همان مسیر است.

آنچه در این درس یاد می‌گیرید

• تفاوت بنیادی سوال چندپرشی با سوال بازیابی، و این‌که چرا گراف جای جست‌وجو را نمی‌گیرد بلکه کنارش می‌نشیند
• استخراج موجودیت و رابطه با خروجی ساختاریافته، بدون هیچ دادهٔ برچسب‌خورده و بدون آموزش مدل
• چرا «توصیف یک‌خطی» هر موجودیت، مهم‌ترین ستون کل خط تولید است
• یکسان‌سازی موجودیت‌ها: چرا شباهت متنی شکست می‌خورد و قضاوت معنایی جواب می‌دهد
• مونتاژ گراف جهت‌دار و پرسیدن سوال از زیرگراف، با جوابی که می‌توان ردش را گرفت
• سه حالت شکست واقعی این خط تولید و کاری که برای هر کدام باید بکنید

چرا این سوال از جنس بازیابی نیست

سوال مدیر پروژه، یک زنجیره است: از «فاز دوم پالایشگاه» به «پیمانکاران آن» و از آنجا به «قراردادهای دیگر همان پیمانکاران». هر حلقهٔ این زنجیره ممکن است در سندی جدا نوشته شده باشد. سامانهٔ بازیابی، تکه‌های شبیه به متن سوال را برمی‌گرداند، اما زنجیره را نمی‌سازد؛ چون رابطه‌ها را به‌عنوان چیزی مستقل از متن نگه نمی‌دارد. گراف دانش همین کار را می‌کند: موجودیت‌ها را گره، رابطه‌ها را یال، و سوال را به پیمایش تبدیل می‌کند. اگر با بازیابی زمینه‌مند آشنا هستید، گراف را رقیب آن ندانید؛ این دو مکمل‌اند و در عمل کنار هم می‌نشینند.

گام اول: استخراج موجودیت و رابطه

خط تولید با یک پاس روی هر سند شروع می‌شود. از مدل می‌خواهیم موجودیت‌های محوری و رابطه‌های میانشان را بیرون بکشد، اما نه به‌صورت متن آزاد؛ خروجی باید مطابق یک شِمای مشخص باشد تا لازم نباشد بعداً با عبارت باقاعده از دل جواب بیرونش بکشیم. ساختار پیشنهادی راهنما ساده و عامدانه کم‌تعداد است: پنج نوع موجودیت، و رابطه‌ای که فقط سه فیلد دارد.

EntityType = Literal["PERSON", "ORGANIZATION", "LOCATION", "EVENT", "ARTIFACT"]

class Entity(BaseModel):
    name: str
    type: EntityType
    description: str

class Relation(BaseModel):
    source: str
    predicate: str
    target: str

class ExtractedGraph(BaseModel):
    entities: list[Entity]
    relations: list[Relation]

پرامپت استخراج هم به همان اندازه ساده است، اما چهار قید داخلش هر کدام دلیلی دارد:

یک گراف دانش از سند زیر استخراج کن.

<document>
{text}
</document>

قواعد:
- فقط موجودیت‌هایی را بردار که سند دربارهٔ آن‌هاست؛ اشارهٔ گذرا را رد کن.
- برای هر موجودیت یک توصیف یک‌جمله‌ای بنویس که ریشه‌اش در همین سند باشد.
- گزاره‌ها عبارت فعلی کوتاه باشند («امضا کرد»، «بخشی از»، «پیمانکار»).
- هر رابطه باید دو موجودیتِ استخراج‌شده را به هم وصل کند.

قید سوم کل کیفیت گراف را تعیین می‌کند. اگر گزاره‌ها آزاد باشند، برای یک رابطهٔ واحد ده صورت مختلف می‌گیرید و یال‌ها دیگر قابل جمع‌بستن نیستند. قید چهارم هم جلوی یالِ معلق را می‌گیرد: رابطه‌ای که یک سرش موجودیتی است که هرگز استخراج نشده.

توصیف یک‌خطی؛ کم‌توجه‌ترین فیلد، مهم‌ترین اثر

فیلد description در نگاه اول تزئینی به نظر می‌رسد. در واقع سوخت گام بعدی است. وقتی در مرحلهٔ یکسان‌سازی می‌خواهیم بفهمیم «شرکت ساخت و نصب فلان» و نام مخفف همان شرکت یک چیزند یا دو چیز، تنها چیزی که این تصمیم را ممکن می‌کند همان یک جملهٔ گرفته‌شده از متن است. پس اگر جایی باید در پرامپت سخت‌گیر باشید، همین‌جاست: توصیف باید مشخص، متکی به سند و غیرکلی باشد.