Graph Engineering เข้ามาแทนที่ RAG ที่ Microsoft, Stanford และ Anthropic แล้ว นี่คือวิธีการทำงาน

ตอนนี้ ใครๆ ก็สามารถสร้างระบบ AI ที่ตอบคำถามซับซ้อนได้แม่นยำกว่า 18% และต้นทุนต่ำกว่า RAG ทั่วไปถึง 85% โดยไม่ต้องมีปริญญาเอก ไม่ต้องมีงบประมาณล้านดอลลาร์ และไม่ต้องมีทีมนักวิจัย

สิ่งเดียวที่ขวางกั้นคุณจากผลลัพธ์นั้นคือแนวคิดหนึ่งที่ Microsoft, Stanford และ Anthropic ค้นพบโดยอิสระจากกัน—และนักพัฒนาส่วนใหญ่ยังตามไม่ทัน

RAG ทั่วไปค้นหาข้อความ Graph Engineering ค้นหาความสัมพันธ์ นี่คือระบบเบื้องหลังทั้งหมด

จดบุ๊กมาร์กนี้ไว้แล้วติดตาม

- ฉันคือ Sprytix นักพัฒนาที่สร้างระบบ AI และไปป์ไลน์อัตโนมัติที่เปลี่ยนเทคโนโลยีให้เป็นรายได้จริง เปิดรับ DM

ทำไม RAG ทั่วไปถึงมีขีดจำกัด

RAG ทั่วไปทำงานแบบนี้:

1คำถาม
2↓
3ค้นหาเอกสารที่ตรงกับข้อความ
4↓
5ส่งคืนชิ้นส่วนที่เกี่ยวข้องมากที่สุด
6↓
7โมเดลสร้างคำตอบจากชิ้นส่วนเหล่านั้น

วิธีนี้ใช้ได้ดีกับคำถามง่ายๆ แต่มันล้มเหลวโดยสิ้นเชิงกับคำถามที่ซับซ้อน

ถามว่า "ทำไมยอดขายสินค้าของเราถึงลดลงในเดือนมีนาคม?" RAG จะค้นหาเอกสารที่มีคำว่า "ยอดขาย" และ "มีนาคม" มันเจอเพียงเศษเสี้ยวของข้อมูล มันไม่พบสายโซ่แห่งสาเหตุ

1คำตอบจาก RAG:
2นี่คือ 5 เอกสารที่กล่าวถึงยอดขายในเดือนมีนาคม
3
4คำตอบจาก Graph Engineering:
5ยอดขายลดลงเพราะความล่าช้าในการเปิดตัว
6ที่เกิดจากการพึ่งพาซัพพลายเออร์
7ซึ่งมีสาเหตุจากปัญหาที่คลังสินค้า
8ทำให้เกิดรีวิวเชิงลบ
9ซึ่งลดอัตราการแปลงลง 23%

โมเดลเดียวกัน ข้อมูลเดียวกัน ผลลัพธ์ต่างกันโดยสิ้นเชิง—เพราะระบบหนึ่งค้นหาข้อความ อีกระบบหนึ่งค้นหาความเป็นจริง

นี่คือสิ่งที่ Microsoft, Stanford และ Anthropic ค้นพบโดยอิสระจากกัน และนี่คือเหตุผลที่ทั้งสามองค์กรหันมาใช้ Graph Engineering

เอกสาร 1 - Microsoft GraphRAG

1. github.com/microsoft/graphrag
2. github.com/microsoft/graphrag/blob/main/docs/index/architecture.md

Microsoft สร้าง GraphRAG และเปิดเผยซอร์สโค้ด ผลลัพธ์จากงานวิจัยของพวกเขาเป็นตัวเลขที่ชัดเจนที่สุดที่มีอยู่เกี่ยวกับสิ่งที่ Graph Engineering ส่งมอบได้จริงเมื่อเทียบกับ RAG ทั่วไป

สถาปัตยกรรมนี้แปลงข้อความที่ไม่มีโครงสร้างให้เป็นกราฟความรู้ที่สมบูรณ์:

1โหลดเอกสาร
2↓
3แบ่งเอกสารเป็นชิ้นส่วน
4↓
5แยกเอนทิตีและความสัมพันธ์
6↓
7สร้างกราฟ
8↓
9ตรวจจับชุมชน
10↓
11สร้างรายงานชุมชน
12↓
13ฝังเอนทิตีและรายงาน
14↓
15ค้นหาเฉพาะที่ / ค้นหาแบบทั่วโลก

ข้อมูลเชิงลึกสำคัญที่ Microsoft บันทึกไว้: RAG ทั่วไปตอบคำถามเฉพาะที่ได้ดี—หาข้อมูลเกี่ยวกับเอนทิตีนี้ให้หน่อย มันล้มเหลวกับคำถามระดับโลก—ธีมหลักในชุดข้อมูลทั้งหมดนี้คืออะไร มีรูปแบบอะไรที่เชื่อมโยงเอกสาร 10,000 ฉบับนี้เข้าด้วยกัน

Graph Engineering ตอบทั้งสองอย่างได้

1การค้นหาเฉพาะที่   |  เกิดอะไรขึ้นกับซัพพลายเออร์ X ในเดือนมีนาคม
2                  |  ค้นหาโหนดเฉพาะและการเชื่อมต่อของมัน
3
4การค้นหาแบบทั่วโลก |  รูปแบบความเสี่ยงหลักในความสัมพันธ์
5                  |  กับซัพพลายเออร์ทั้งหมดของเราคืออะไร
6                  |  ค้นหารูปแบบทั่วทั้งกราฟ

ผลลัพธ์เชิงปฏิบัติจากงานวิจัย GraphRAG ของ Microsoft:

1การปรับปรุงความแม่นยำ    |  สูงกว่าแนวทางเอกสารดิบ 18%
2การลดต้นทุนโทเค็น       |  ต่ำกว่าการโหลดไฟล์ที่มีโครงสร้างโดยตรง 85%
3ต้นทุนต่อภารกิจ         |  ประมาณ $0.004 ในการกำหนดค่าที่ทดสอบ

arxiv.org/abs/2603.22528

ตัวเลขเหล่านี้มาจากเอกสาร ChatP&ID—GraphRAG ที่ประยุกต์ใช้กับแผนผังทางวิศวกรรมอุตสาหกรรม หลักการเดียวกันนี้ใช้ได้กับทุกโดเมน

เอกสาร 2 - Stanford DSPy และการเชื่อมต่อกับกราฟ

1. github.com/stanfordnlp/dspy
2. arxiv.org/abs/2310.03714

เอกสาร DSPy ของ Stanford กำหนดว่าโมเดลเป็นโหนดหนึ่งในกราฟ—ไม่ใช่ศูนย์กลางของจักรวาล นี่คือรากฐานทางทฤษฎีที่เชื่อมโยงโดยตรงกับ Graph Engineering

DSPy ถือว่าไปป์ไลน์ AI เป็นกราฟของโมดูล:

1คำถาม
2↓
3ตัวดึงข้อมูล      - ค้นหาข้อมูลที่เกี่ยวข้อง
4↓
5การให้เหตุผล      - ประมวลผลและเชื่อมโยง
6↓
7ตัวตรวจสอบ       - ตรวจสอบผลลัพธ์
8↓
9คำตอบ

การเชื่อมต่อกับ Graph Engineering นั้นตรงไปตรงมา: DSPy ปรับแต่งกราฟไปป์ไลน์ให้เหมาะสม GraphRAG ปรับแต่งกราฟความรู้ให้เหมาะสม ทั้งสองมองว่าโมเดลเป็นองค์ประกอบหนึ่งในโครงสร้างที่ใหญ่กว่า ไม่ใช่ทางออกทั้งหมด

เอกสาร STORM ของ Stanford ไปไกลกว่านั้น:

1. github.com/stanford-oval/storm
2. arxiv.org/abs/2402.14207

STORM สร้างความรู้ตั้งแต่เริ่มต้นผ่านกราฟที่มีโครงสร้างของขั้นตอนการวิจัย ก่อนที่จะเขียนคำเดียว การวิจัย การรวบรวมแหล่งที่มา โครงร่าง การเขียน การตรวจสอบ การแก้ไข—แต่ละขั้นตอนได้รับข้อมูลจากความสัมพันธ์ที่ค้นพบในขั้นตอนก่อนหน้า

ข้อมูลเชิงลึกร่วมกันในงานวิจัยทั้งหมดของ Stanford: งานที่ซับซ้อนต้องการระบบของขั้นตอนที่เชื่อมต่อกัน ไม่ใช่การเรียกใช้โมเดลเพียงครั้งเดียว กราฟคือระบบ

เอกสาร 3 - กฎการสเกลของ Stanford สำหรับกราฟความรู้

arxiv.org/abs/2505.16276

เอกสารนี้เปรียบเทียบโมเดลโอเพนซอร์ส 26 ตัวในงานวิศวกรรมกราฟความรู้ บทสรุปเป็นหนึ่งในสิ่งที่สำคัญที่สุดในสาขานี้:

1โมเดลใหญ่ + กราฟไม่ดี   |  ผลลัพธ์แย่กว่า
2โมเดลเล็ก + กราฟดี     |  ผลลัพธ์ดีกว่า

กราฟที่ถูกต้องชนะโมเดลที่ใหญ่กว่า ทุกครั้ง

นี่คือบทสรุปเดียวกันกับที่ Microsoft ได้จาก GraphRAG และ Anthropic ได้จาก Claude Code—ระบบที่อยู่รอบๆ โมเดลกำหนดผลลัพธ์มากกว่าตัวโมเดลเอง Graph Engineering คือการนำหลักการนั้นไปปฏิบัติที่ชัดเจนที่สุด

เอกสาร 4 - งานวิจัยของ MIT Press เกี่ยวกับหน่วยความจำเชิงสัมพันธ์

direct.mit.edu/tacl/article/doi/10.1162/tacl_a_00476

เผยแพร่ใน Transactions of the Association for Computational Linguistics

งานวิจัยแสดงให้เห็นว่าเกิดอะไรขึ้นเมื่อคุณเชื่อมต่อโมเดลภาษากับหน่วยความจำเชิงสัมพันธ์—กราฟความรู้ของความสัมพันธ์ แทนที่จะเป็นเพียงชิ้นส่วนข้อความ

1บริบทข้อความ
2↓
3ดึงความสัมพันธ์ที่เกี่ยวข้องจากกราฟ
4↓
5หน่วยความจำเชิงสัมพันธ์
6↓
7โมเดลภาษา
8↓
9การสร้างที่สอดคล้องและแม่นยำมากขึ้น

ข้อค้นพบสำคัญ: โมเดลที่สามารถเข้าถึงโครงสร้างความสัมพันธ์ที่ชัดเจนจะสร้างข้อความที่สอดคล้องกันมากขึ้นและทำข้อผิดพลาดเชิงตรรกะน้อยกว่าโมเดลที่ทำงานจากข้อความเพียงอย่างเดียว

นี่คือคำอธิบายทางวิทยาศาสตร์ว่าทำไม Graph Engineering ถึงได้ผล โมเดลไม่ต้องอนุมานความสัมพันธ์จากข้อความอีกต่อไป ความสัมพันธ์ถูกกำหนดไว้อย่างชัดเจนในกราฟ โมเดลใช้มันโดยตรง

เอกสาร 5 - KEPLER

1. direct.mit.edu/tacl/article-abstract/doi/10.1162/tacl_a_00360/98089
2. github.com/THU-KEG/KEPLER

KEPLER รวมการฝึกโมเดลภาษาเข้ากับการฝังกราฟความรู้ แทนที่จะมองว่าความเข้าใจภาษาและความรู้เชิงข้อเท็จจริงเป็นปัญหาที่แยกจากกัน—KEPLER ปรับแต่งทั้งสองอย่างพร้อมกัน

1โมเดลภาษา
2+
3การฝังความรู้
4+
5กราฟความรู้
6=
7โมเดลที่เข้าใจทั้งภาษาและข้อเท็จจริง

ผลกระทบเชิงปฏิบัติ: โมเดลที่สามารถเข้าถึงกราฟความรู้ที่มีโครงสร้างอย่างเหมาะสมไม่จำเป็นต้องเดาความสัมพันธ์ระหว่างเอนทิตี มันค้นหามันได้เลย ความแตกต่างด้านความแม่นยำสำหรับคำถามเชิงข้อเท็จจริงมีนัยสำคัญ

เอกสาร 6 - Anthropic และ Claude ในกราฟ

1. www.anthropic.com/customers/graph
2. github.com/anthropics/anthropic-cookbook
3. github.com/modelcontextprotocol

Anthropic ไม่มีผลิตภัณฑ์ที่ชื่อ "Graph Engineering" สิ่งที่พวกเขามีคือสามเลเยอร์ที่ Claude ทำงานโดยตรงกับสถาปัตยกรรมกราฟ

เลเยอร์ 1 - Claude ดึงกราฟจากข้อความ

1เอกสาร
2↓
3Claude แยกเอนทิตีและความสัมพันธ์
4↓
5JSON triples:
6{
7  "subject": "Anthropic",
8  "relation": "created",
9  "object": "Claude"
10}
11↓
12กราฟความรู้

Claude จัดการการแยกเอนทิตี การแยกความสัมพันธ์ การขจัดข้อมูลซ้ำ การทำให้เป็นมาตรฐาน และการร่างออนโทโลยี งานที่เคยต้องใช้ไปป์ไลน์ NLP เฉพาะทาง ตอนนี้ทำงานผ่านการเรียก API เพียงครั้งเดียว

เลเยอร์ 2 - Claude ค้นหากราฟ

1คำถามผู้ใช้
2↓
3Claude
4↓
5คำค้นหา Cypher / SPARQL
6↓
7กราฟความรู้
8↓
9ผลลัพธ์
10↓
11คำอธิบายจาก Claude เป็นภาษาธรรมดา

Claude แปลภาษาธรรมชาติเป็นคำค้นหากราฟ รันกับ Neo4j หรือฐานข้อมูลกราฟใดๆ และอธิบายผลลัพธ์ ไม่ต้องมีความรู้เกี่ยวกับภาษาค้นหาจากผู้ใช้

เลเยอร์ 3 - MCP เชื่อมต่อ Claude กับกราฟ

github.com/modelcontextprotocol

1Claude
2↓
3โปรโตคอล MCP
4↓
5ฐานข้อมูลกราฟ
6↓
7เอนทิตี + ความสัมพันธ์
8↓
9Claude พร้อมบริบทกราฟเต็มรูปแบบ

MCP คือเลเยอร์การขนส่งที่ให้ Claude เข้าถึงกราฟความรู้ใดๆ ได้อย่างถาวร โดยไม่ต้องสร้างการเชื่อมต่อใหม่ทุกครั้ง

กรณีศึกษา LaunchNotes - ตัวเลขการผลิตจริง

www.anthropic.com/customers/graph

LaunchNotes สร้างผลิตภัณฑ์ที่ชื่อ Graph ซึ่งเชื่อมต่อ GitHub, Jira และ Linear Claude วิเคราะห์ความสัมพันธ์ระหว่างงานวิศวกรรมในทั้งสามระบบ

1การคอมมิตบน GitHub
2+
3ตั๋ว Jira
4+
5งาน Linear
6↓
7กราฟของงานวิศวกรรม
8↓
9Claude
10↓
11การตรวจจับเหตุการณ์ + ข้อมูลเชิงลึกของโครงการ

ผลลัพธ์จากกรณีศึกษาของ Anthropic:

1การตรวจจับเหตุการณ์     |  เร็วขึ้นถึง 5 เท่า
2เวลาในการประชุม        |  ลดลงประมาณ 50%
3บันทึกการเปิดตัว        |  สร้างโดยอัตโนมัติในไม่กี่วินาที

ตัวเลขเหล่านี้มาจากการเชื่อมต่อข้อมูลความสัมพันธ์ที่มีโครงสร้าง—ไม่ใช่แค่การค้นหาเอกสาร

กราฟความรู้คืออะไรกันแน่

ก่อนที่จะสร้างกราฟ—แนวคิดพื้นฐาน

กราฟความรู้จัดเก็บข้อมูลในรูปแบบสามส่วน:

1Subject → Relation → Object

ตัวอย่าง:

1Anthropic → สร้าง → Claude
2Claude → รองรับ → MCP
3MCP → เชื่อมต่อ → เครื่องมือภายนอก
4Microsoft → สร้าง → GraphRAG
5GraphRAG → ลดต้นทุนโทเค็นลง → 85%

ทุกชิ้นข้อมูลคือความสัมพันธ์ที่ชัดเจนระหว่างสองเอนทิตี ไม่ใช่ย่อหน้าข้อความที่อาจมีข้อมูลนี้—แต่เป็นข้อเท็จจริงที่ชัดเจน มีโครงสร้าง และสามารถค้นหาได้

1ฐานข้อมูลทั่วไป:
2ตารางบริษัท
3ตารางผลิตภัณฑ์
4ไม่มีความสัมพันธ์ที่ชัดเจนระหว่างกัน
5
6กราฟความรู้:
7บริษัท → สร้าง → ผลิตภัณฑ์
8ผลิตภัณฑ์ → แข่งขันกับ → ผลิตภัณฑ์อื่น
9ผลิตภัณฑ์อื่น → เป็นเจ้าของโดย → บริษัทอื่น
10บริษัท → ลงทุนใน → บริษัทอื่น

กราฟไม่เพียงจัดเก็บข้อเท็จจริง มันจัดเก็บว่าข้อเท็จจริงเชื่อมต่อกันอย่างไร นั่นคือสิ่งที่ทำให้การให้เหตุผลที่ซับซ้อนเป็นไปได้

ไปป์ไลน์ Graph Engineering เต็มรูปแบบ

1ขั้นตอน 1  |  รวบรวมเอกสารดิบ
2           |  PDF, อีเมล, รายงาน, ข้อมูลส่งออกจากฐานข้อมูล
3
4ขั้นตอน 2  |  แยกเอนทิตี
5           |  บุคคล, บริษัท, ผลิตภัณฑ์, เหตุการณ์, แนวคิด
6
7ขั้นตอน 3  |  แยกความสัมพันธ์
8           |  ใครทำอะไรกับใคร เมื่อไหร่ ทำไม อย่างไร
9
10ขั้นตอน 4  |  สร้างสคีมา
11           |  กำหนดประเภทเอนทิตีและประเภทความสัมพันธ์
12
13ขั้นตอน 5  |  ขจัดข้อมูลซ้ำและทำให้เป็นมาตรฐาน
14           |  "Microsoft Corp" และ "MSFT" คือเอนทิตีเดียวกัน
15
16ขั้นตอน 6  |  จัดเก็บในฐานข้อมูลกราฟ
17           |  Neo4j, Amazon Neptune, PostgreSQL พร้อมส่วนขยายกราฟ
18
19ขั้นตอน 7  |  สร้างเลเยอร์การดึงข้อมูล
20           |  การค้นหาเฉพาะที่สำหรับเอนทิตีเฉพาะ
21           |  การค้นหาแบบทั่วโลกสำหรับรูปแบบทั่วทั้งกราฟ
22
23ขั้นตอน 8  |  เชื่อมต่อโมเดล
24           |  Claude ค้นหากราฟผ่าน MCP หรือ API โดยตรง
25
26ขั้นตอน 9  |  ปรับปรุงอย่างต่อเนื่อง
27           |  เอกสารใหม่ขยายกราฟ
28           |  ความขัดแย้งถูกตั้งค่าสถานะเพื่อตรวจสอบ

เอกสาร LLM-assisted Knowledge Graph Engineering ที่ arxiv.org/abs/2307.06917 วัดประสิทธิภาพของโมเดลภาษาในแต่ละขั้นตอนเหล่านี้ ข้อค้นพบที่ตรงไปตรงมา: LLM เป็นผู้ช่วยที่ยอดเยี่ยมสำหรับการแยกและการทำให้เป็นมาตรฐาน แต่การสร้างกราฟแบบ zero-shot ยังไม่น่าเชื่อถือพอสำหรับการผลิตโดยไม่ต้องมีการตรวจสอบโดยมนุษย์ในขั้นตอนสคีมาและการขจัดข้อมูลซ้ำ

พรอมต์ห้าตัวที่ขับเคลื่อนไปป์ไลน์ทั้งหมด

Graph Engineering ไม่ได้กำจัดพรอมต์ มันใช้พรอมต์ในแต่ละขั้นตอนเฉพาะของไปป์ไลน์กราฟ

พรอมต์ 1 - การแยก

1แยกองค์กร บุคคล ผลิตภัณฑ์ และเหตุการณ์ทั้งหมด
2
3สำหรับแต่ละเอนทิตี ให้ส่งคืน:
4- canonical_name
5- type
6- description
7- source
8
9สำหรับแต่ละความสัมพันธ์ ให้ส่งคืน:
10- source_entity
11- relation_type
12- target_entity
13- evidence
14- confidence_score

พรอมต์ 2 - การทำให้เป็นมาตรฐาน

1เปรียบเทียบเอนทิตีต่อไปนี้
2พิจารณาว่ามันหมายถึง:
3- เอนทิตีเดียวกัน
4- เอนทิตีที่เกี่ยวข้องแต่แตกต่างกัน
5- เอนทิตีที่ไม่เกี่ยวข้องกัน
6
7ส่งคืนชื่อมาตรฐานและคำอธิบาย
8อย่ารวมเอนทิตีโดยไม่มีหลักฐานชัดเจน

พรอมต์ 3 - การค้นหากราฟ

1แปลคำถามผู้ใช้เป็นคำค้นหา Cypher
2ใช้เฉพาะความสัมพันธ์ที่มีอยู่ในสคีมา
3อย่าสร้างป้ายกำกับหรือคุณสมบัติใหม่
4ส่งคืนคำค้นหาและคำอธิบายสั้นๆ ของตรรกะ

พรอมต์ 4 - คำตอบที่มีหลักฐานยืนยัน

1ตอบโดยใช้เฉพาะเส้นทางกราฟที่ดึงมา
2สำหรับข้อสรุปทุกข้อ:
3- ระบุโหนดที่สนับสนุน
4- ระบุเส้นทางความสัมพันธ์
5- ระบุความไม่แน่นอนอย่างชัดเจน
6- อย่าอนุมานสาเหตุจากความสัมพันธ์

พรอมต์ 5 - การบำรุงรักษากราฟ

1เปรียบเทียบข้อเท็จจริงใหม่กับกราฟที่มีอยู่
2จัดประเภทแต่ละข้อเท็จจริงเป็น:
3- ใหม่
4- ซ้ำ
5- ขัดแย้ง
6- อัปเดต
7- ไม่แน่นอน
8
9อย่าเขียนทับข้อเท็จจริงที่มีอยู่โดยไม่มีหลักฐาน

ดังที่เอกสาร GraphRAG ของ Microsoft แสดงให้เห็น—พรอมต์จัดการการแยก การระบุความสัมพันธ์ การสรุป และการสร้างรายงานชุมชนภายใน วิศวกรรมพรอมต์เป็นกลไกภายในวิศวกรรมกราฟ ไม่ใช่คู่แข่ง

ห้าธุรกิจที่คุณสามารถสร้างบนกราฟความรู้

1 - แพลตฟอร์มตรวจสอบสถานะ

1รายงานบริษัท + ผู้ก่อตั้ง + นักลงทุน
2+ คดีความ + บริษัทย่อย + ธุรกรรม
3↓
4กราฟความรู้
5↓
6Claude
7↓
8การวิเคราะห์ความเสี่ยง + การเชื่อมต่อที่ซ่อนอยู่ + การตรวจจับความขัดแย้งทางผลประโยชน์

ลูกค้า: กองทุนการลงทุน, สำนักงานกฎหมาย, ธนาคาร, ที่ปรึกษาการควบรวมกิจการ ค่าธรรมเนียมรายเดือน $2,000-10,000 ต่อลูกค้า

2 - ข้อมูลเชิงลึกด้านการขาย

1ผู้ติดต่อ + บริษัท + บทบาท
2+ อีเมลก่อนหน้า + ปัญหาของบริษัท + ผลิตภัณฑ์
3↓
4กราฟความรู้
5↓
6ใครมีอิทธิพลต่อการตัดสินใจ
7ข้อโต้แย้งใดที่เกิดขึ้นซ้ำ
8ควรแสดงกรณีศึกษาใดให้ลูกค้าเฉพาะรายนี้
9ดีลถูกขัดขวางตรงไหน

3 - ข้อมูลเชิงลึกด้านวิศวกรรม

1การคอมมิตบน GitHub + ตั๋ว Jira + งาน Linear
2↓
3กราฟของงานวิศวกรรม
4↓
5ตรวจจับเหตุการณ์เร็วขึ้น 5 เท่า
6เวลาในการประชุมน้อยลง 50%
7บันทึกการเปิดตัวอัตโนมัติ

LaunchNotes ขายสิ่งนี้อยู่แล้ว ตลาดคือทุกทีมวิศวกรรมที่ใช้เครื่องมือการจัดการโครงการมากกว่าหนึ่งตัว

4 - ข้อมูลเชิงลึกด้านการวิจัย

1เอกสาร + ผู้แต่ง + สถาบัน
2+ วิธีการ + ชุดข้อมูล + ผลลัพธ์ + ความขัดแย้ง
3↓
4กราฟความรู้
5↓
6วิธี GraphRAG ใดใช้การตรวจจับชุมชน
7บนชุดข้อมูลใดที่พวกเขาถูกทดสอบ
8เอกสารใดที่ขัดแย้งกัน

5 - ระบบปฏิบัติการความรู้ส่วนบุคคล

1บันทึก Obsidian + อีเมล + ปฏิทิน
2+ PDF + ผู้ติดต่อ + งาน
3↓
4กราฟความรู้ส่วนบุคคล
5↓
6ฉันคุยเรื่องนี้กับใคร
7งานใดขึ้นอยู่กับการตอบกลับของบุคคลหนึ่ง
8การตัดสินใจใดขัดแย้งกับข้อตกลงก่อนหน้า
9ฉันสัญญาว่าจะทำอะไรในเดือนนี้

การเปลี่ยนแปลงที่เชื่อมโยง Microsoft, Stanford และ Anthropic

1วิศวกรรมพรอมต์   |  วิธีการถามคำถามที่ถูกต้อง
2RAG              |  เอกสารไหนที่จะค้นหา
3Graph Engineering |  มีเอนทิตีอะไรบ้าง
4                  |  พวกมันเชื่อมต่อกันอย่างไร
5                  |  เส้นทางไหนนำไปสู่คำตอบ
6                  |  จะเกิดอะไรขึ้นถ้าโหนดหนึ่งเปลี่ยนไป

LLM รู้คำศัพท์ กราฟความรู้รู้ความสัมพันธ์ ระบบ AI ที่ทรงพลังที่สุดปรากฏขึ้นเมื่อทั้งสองทำงานร่วมกัน

Microsoft พิสูจน์สิ่งนี้ในระดับการผลิตด้วย GraphRAG—ความแม่นยำดีขึ้น 18% ต้นทุนลดลง 85% Stanford พิสูจน์ในงานวิจัยด้วย DSPy, STORM และเอกสารกฎการสเกล Anthropic พิสูจน์ในกรณีศึกษา LaunchNotes—ตรวจจับเหตุการณ์เร็วขึ้น 5 เท่า เวลาประชุมน้อยลง 50%

สามองค์กร สามเส้นทางอิสระ หนึ่งบทสรุป

โมเดลค้นหาข้อความ กราฟค้นหาความเป็นจริง จงสร้างกราฟ

นักพัฒนาส่วนใหญ่จะยังคงปรับปรุงพรอมต์ของพวกเขาและสงสัยว่าทำไมคำถามที่ซับซ้อนยังคงให้คำตอบที่ไม่ดี มีเพียงไม่กี่คนที่จะใช้เวลาหนึ่งสุดสัปดาห์สร้างกราฟความรู้แรกของพวกเขาและจะไม่กลับไปค้นหาเอกสารอีกเลย

/ ถ้าสิ่งนี้มีประโยชน์—ติดตามไว้ ตอนต่อไปจะลงที่นี่ก่อนใคร