สวนลับของนักพัฒนา: ออนโทโลยีเชิงพื้นที่จัดแนว LLM ได้อย่างไรโดยไม่ต้องใช้ Prompt Engineering
เผยแพร่เมื่อ 30 April 2026
- ข้อสังเกต: Prompt Engineering เป็นปราสาททราย
- สี่วงกลมแห่งความไว้วางใจ: ภววิทยาเชิงพื้นที่
- ข้อดี/ข้อเสีย : การจัดแนวเชิงพื้นที่ เทียบกับ การจัดแนวด้วยพรอมต์
- พีชคณิตเชิงสัมพันธ์ของเวิร์กสเปซและเดลตาที่สังเกตได้
- เวกเตอร์ผสมของบริบท: RAG + pgvector + Graphify
- การจำแนกประเภท RGPD อัตโนมัติ: LLM ในฐานะเราเตอร์
- แผนงาน : จาก AsciiDoc ถึง LangGraph4j
- สิ่งที่สถาปัตยกรรมนี้แก้ไข (และสิ่งที่มันไม่ได้แก้ไข)
- บทสรุป: สถาปัตยกรรมในฐานะวาทกรรม
- ข้อมูลอ้างอิง
Prompt engineering นั้นเปราะบาง เมื่อถึง 80,000 โทเคน กฎการจัดแนวของคุณจะจมอยู่ในเสียงรบกวน และ LLM จะลืมสิ่งที่คุณขอไว้เมื่อต้นบทสนทนา ทางแก้ของฉัน? คือไม่จัดแนวด้วยข้อความ แต่ด้วย…พื้นที่. ฉันได้จัดโครงสร้างเวิร์กสเปซสำหรับการพัฒนาของฉันเป็นวงความไว้วางใจแบบซ้อนกันสี่วง — ตั้งแต่สวนลับส่วนตัวไปจนถึงโรงหลอมสาธารณะ — และแต่ละวงคือพื้นที่ทางกายภาพของระบบไฟล์ LLM ไม่จำเป็นต้องมีใครคอยเตือนกฎ เพราะเส้นทางของไฟล์มีกฎเหล่านั้นอยู่ในตัว นี่คือวิธีการทำงาน และเหตุใดสถาปัตยกรรมการจัดแนวด้วยพื้นที่นี้จึงทนทานกว่าหนึ่ง`system prompt`จำนวน 500 บรรทัด
นี่เป็นบทความยาว
เชิญนั่งตามสบาย
ข้อสังเกต: Prompt Engineering เป็นปราสาททราย
เป็นเวลาสามสัปดาห์ ฉันพัฒนาปลั๊กอิน Gradle ด้วย Opencode โดยใช้ LLM สามตัวที่แตกต่างกัน — Kimi K2.6, GLM-5.1 และ DeepSeek-V4-Pro (ตัวเดียวที่รอดชีวิต แต่นั่นเป็นอีกเรื่องหนึ่งได้กล่าวถึงแล้วที่นี่) วิธีการกำกับดูแลเอเจนต์ของฉันฉันได้บันทึกไว้อย่างละเอียดในบทความก่อนหน้า อาศัยไฟล์ AsciiDoc —AGENT.adoc, INDEX.adoc, PROMPT_REPRISE.adoc— ซึ่งโหลดกฎ แบ็กล็อก และประวัติราว 30,000 โทเค็นในทุกต้นเซสชัน
และแม้จะมีโครงสร้างพื้นฐานด้านเอกสารนี้ สองสิ่งก็ทำให้ฉันประหลาดใจ:
-
LLM ลืม แม้จะมีกฎเด็ดขาดอยู่ที่ด้านบนของแต่ละไฟล์ EAGER เมื่อเกิน 60,000 โทเคนสะสม (บริบทเริ่มต้น + บทสนทนา) Kimi K2.6 เริ่มเสนอ`Write`เขียนทับไฟล์กำหนดค่า GLM-5.1 เข้าใจโทเคน Firebase ผิดว่าเป็น placeholder ที่ต้องแทนที่ กฎถูกเขียนไว้ — แต่ LLM ไม่ มองเห็น กฎเหล่านั้นอีกต่อไป
-
การกำกับดูแลเองก็กลายเป็นปัญหา. หลังจากนำกลไก Hot/Warm/Coldบทความเกี่ยวกับการหมุนเวียนแบ็กอัป มาใช้เพื่อหลีกเลี่ยงการระเบิดของบริบท ไฟล์ EAGER ของฉันยังคงมี 1414 บรรทัดฉันได้บันทึกการตรวจสอบนี้ไว้ที่นี่ การกำกับดูแล — ซึ่งออกแบบมาเพื่อปกป้อง LLM จากความอิ่มตัว — กลับทำให้ LLM อิ่มตัว
ฉันต้องการกลไกการจัดแนวที่ไม่ขึ้นอยู่กับจำนวนโทเค็นในพรอมต์
คำตอบ: หยุดจัดแนวตามข้อความ และเริ่มจัดแนวด้วย…พื้นที่.
สี่วงกลมแห่งความไว้วางใจ: ภววิทยาเชิงพื้นที่
แฟ้มของฉัน`workspace/(ใน~/workspace/`) ไม่ใช่ รีโพซิทอรี Git นี่คือรากฐานของงานทั้งหมดของฉัน — โค้ด เอกสาร การฝึกอบรม โครงสร้างพื้นฐาน และมันถูกจัดโครงสร้างเป็นสี่โซนที่ไม่ใช่ข้อกำหนดในการจัดเก็บ แต่เป็นวงกลมแห่งความไว้วางใจที่มีศูนย์กลางร่วมกันPlease provide the French text you’d like me to translate.
ระดับ |
ป้ายกำกับ |
พื้นที่ทางกายภาพ |
CVS |
การมองเห็น |
0 |
สวนลับ |
`workspace/`ราก |
ไม่มี |
ความเป็นส่วนตัว — ความคิดเสรี ไม่มีการคอมมิต ไม่มีการเผยแพร่ |
1 |
ตู้เซฟ |
|
Git ส่วนตัว (โซโล) |
ความลับ, โทเค็น, คลังเก็บการมองเห็น เพียงคนเดียวเท่านั้น |
2 |
ห้องสมุด |
|
Git ส่วนตัว (ขยาย) |
ข้อมูลทางการเรียนการสอน, SPG/SPD, สคีมา JSON วงแหวนความไว้วางใจที่ระบุแล้ว |
4 |
โรงตีเหล็ก (ของรัฐ) |
|
Git สาธารณะ (Apache 2.0) |
ซอร์สโค้ด, ปลั๊กอิน, การทดสอบ, เอกสารทางเทคนิค |
หมายเหตุ: ไม่มีระดับ 3 ในตาราง ระดับ 3 เป็นระดับ ชั่วคราว : เป็นเนื้อหาของ`office/`ซึ่งได้รับการทำให้ไม่ระบุตัวตนและพร้อมที่จะเผยแพร่เป็นข้อมูลเปิดแล้ว ไม่มีพื้นที่ทางกายภาพเป็นของตนเอง — มันเป็นสภาวะของข้อมูล ไม่ใช่ตำแหน่งที่ตั้ง
แต่ละระดับตอบคำถามที่เฉพาะเจาะจงข้อหนึ่ง:
-
จะเก็บไอเดียที่ยังไม่พร้อมจะแบ่งปัน แม้แต่กับคนกลุ่มเล็ก ๆ ไว้ที่ไหน? → สวนลับ ไม่มี Git ไม่มีความกดดัน
-
จะเก็บโทเค็น API ไว้ที่ไหนโดยไม่ให้รั่วไหล? → ตู้เซฟ (
configuration/). แยกโดดเดี่ยวทางกายภาพ ไม่มีคลังอื่นใดสามารถอ้างอิงถึงได้โดยผิดพลาด -
จะร่วมสร้างแคตตาล็อกการฝึกอบรมกับ OF นำร่องได้ที่ไหน → ห้องสมุด (
office/). มีการควบคุมเวอร์ชัน ทำงานร่วมกัน แต่เป็นส่วนตัว -
จะทำให้ปลั๊กอิน Gradle โอเพนซอร์สเป็นอุตสาหกรรมที่ไหน ? → ฟอร์จ (
foundry/). สาธารณะ สามารถ fork ได้ ทดสอบใน CI
ภววิทยานี้เป็นที่ LLM นำไปใช้ได้. เมื่อเขาอ่านไฟล์ใน`foundry/plantuml-gradle/src/`, เขารู้โดยปริยายว่า “ฉันอยู่ในวงกลมที่ 4 — โค้ดสาธารณะ การทดสอบบังคับ ไม่มีความลับ ไม่มีข้อมูลการสอน” เขาไม่จำเป็นต้องมีพรอมต์ที่คอยเตือนเขาถึงเรื่องนี้
สวนลับ : พื้นที่นอก CVS
นี่คือแนวคิดที่สำคัญที่สุด — และเป็นแนวคิดที่ขัดกับสามัญสำนึกที่สุด
ราก`workspace/ไม่มี.git/. เอกสารที่อาศัยอยู่ที่นั่น (`WORKSPACE_VISION.adoc, WORKSPACE_AS_PRODUCT.adoc, WORKSPACE_ORGANIZATION.adoc— และฉบับที่คุณกำลังอ่านอยู่ในขณะนี้ ซึ่งมาจากสิ่งนั้น) ไม่ได้มีไว้เพื่อถูกทำเวอร์ชัน แชร์ หรือแม้แต่ถูกอ่านซ้ำโดยใครอื่นนอกจากฉัน สิ่งเหล่านี้เป็นความคิดที่กำลังงอกงาม.
|
สวนลับเป็น out-of-CVS โดยธรรมชาติ การไม่มีระบบจัดการเวอร์ชันคือเงื่อนไขของเสรีภาพในการคิด เราไม่เขียนที่นั่นเพื่อให้มีคนอ่าน — เราเขียนเพื่อทำให้วิสัยทัศน์ของตนเองชัดเจนขึ้น |
แต่เสรีภาพนี้มีราคาที่ต้องจ่าย: หนึ่ง`rm`โดยบังเอิญ และนั่นคือหลายเดือนแห่งการคิดเชิงกลยุทธ์ที่หายไป ทางแก้ไม่ใช่การทำเวอร์ชันสวน (นั่นจะเป็นการทำลายมัน) — แต่คือการมิเรอร์ในวงที่แคบที่สุด
.gitignore` ในฐานะการกำหนดค่าการกำกับดูแล
ที่รากของ`workspace/, ไฟล์หนึ่ง.gitignore`มินิมอลประกาศมันนโยบายการเก็บประวัติไฟล์ของสวนลับ:
.goosehints
.gooseCe .gitignore`ไม่มีฟังก์ชัน Git แบบมาตรฐาน (ไม่มี.git/`ที่ราก) มันทำหน้าที่เป็นไฟล์การกำหนดค่าการกำกับดูแลซึ่งตอบคำถามที่เจาะจงว่า: อาร์ติแฟกต์ใดในสวนลับที่ควรค่าแก่การบันทึกเป็นประวัติศาสตร์ และอาร์ติแฟกต์ใดเป็นเพียงสิ่งชั่วคราว?
-
ไฟล์ที่ระบุไว้ใน`.gitignore`Please provide the French text you’d like me to translate into Thai.
.goosehints,.goose— เป็นอาร์ติแฟกต์ชั่วคราวที่สร้างโดยเอเจนต์ ไม่มีคุณค่าทางกลยุทธ์ ไม่มีการจัดเก็บประวัติ -
ไฟล์`.adoc`ของราก —
WORKSPACE_VISION.adoc,WORKSPACE_ORGANIZATION.adoc,WORKSPACE_AS_PRODUCT.adoc,WHAT_THE_GAMES_BEEN_MISSING.adoc,depots_implementes_strategie.adoc,synthese-LLMs-long-contexte.adoc— ไม่ใช่ก้าวใน`.gitignore`. สิ่งเหล่านี้คืออาร์ติแฟกต์ที่ต้องทำให้เป็นประวัติศาสตร์
Le `.gitignore`คือแผนภาพการกำกับดูแล: ทุกสิ่งที่ไม่ได้ระบุไว้ในนั้นถือเป็นตัวเลือกสำหรับสแนปช็อต และ LLM เมื่ออ่านไฟล์นี้จะรู้อย่างแม่นยำว่าอะไรควรถูกเก็บถาวรและอะไรสามารถละเว้นได้ — โดยไม่ต้องเตือนมันในพรอมป์ต์
กลไกสแนปช็อต
ฉันได้สร้าง`configuration/vision-archive/: สแนปช็อตที่ระบุวันที่ของทั้งหมด.adoc`ของราก ซึ่งถูกคอมมิตในรีโพซิทอรีส่วนตัว`configuration/`. แต่ละเซสชันการระดมสมองจะสร้างสแนปช็อต:
DATE=$(date +%Y-%m-%d)
mkdir -p /home/cheroliv/workspace/configuration/vision-archive/$DATE
cp /home/cheroliv/workspace/*.adoc /home/cheroliv/workspace/configuration/vision-archive/$DATE/
cd /home/cheroliv/workspace/configuration && git add vision-archive/ && \
git commit -m "vision-archive: snapshot $DATE"กระบวนการนี้ถูกกระตุ้นเมื่อสิ้นสุดเซสชันโดยตัว LLM เอง ซึ่งดำเนินงานการกำหนดเส้นทางโดยรวมนี้ แต่ละสแนปช็อตบันทึกสถานะทั้งหมดของความคิดเชิงกลยุทธ์ ณ จุดเวลา T
ประวัติ Git ของ`configuration/`กลายเป็นชีวประวัติความคิดเชิงกลยุทธ์ของฉัน. ฉันสามารถทำ`git log — vision-archive/`และดูการเปลี่ยนแปลงของการมองเห็นของฉัน ทีละเซสชัน ทีละวันที่
ตัวอย่างจริงของประวัติหลังจากวันทำงานหนึ่งวัน:
$ git -C configuration log --oneline -- vision-archive/
1089d1b vision-archive: fin de session finale 2026-05-03
6b21eaf vision-archive: fin de session 2026-05-03-1300
1690f82 vision-archive: post-article 2026-05-03
28e6593 vision-archive: post-migration 2026-05-03
3707b78 vision-archive: snapshot 2026-05-03 — jardin secret initialห้าสแนปช็อตในหนึ่งวัน แต่ละอันคือจุดกู้คืน แต่ละอันคือหมุดหมายในกำเนิดของกลยุทธ์
แฟ้ม`configuration/vision-archive/latest/`มี…อย่างถาวรสำเนาการทำงานของสแนปช็อตล่าสุด ซึ่งใช้เป็นข้อมูลอ้างอิงด่วนโดยไม่ต้องนำทางผ่านประวัติ Git
และสำหรับ LLM นั้น มันเป็นออราเคิลแห่งความสอดคล้อง: เมื่อเขาสังเกตเห็นความขัดแย้งระหว่างการนำไปใช้ในปัจจุบันกับวิสัยทัศน์ที่ถูกเก็บถาวร ณ วันที่ก่อนหน้า เขาสามารถรายงานความขัดแย้งนั้นได้
ตู้เซฟ: configuration/ ในฐานะ Spring Cloud Config
`configuration/`ไม่ได้มีเพียงคลังเก็บแห่งนิมิตเท่านั้น หน้าที่หลัก — และในอนาคต — ของมันคือการเป็นเซิร์ฟเวอร์ Spring Cloud Config. ความลับทั้งหมด โทเค็น ข้อมูลรับรอง และคำอธิบายโครงสร้างพื้นฐานอยู่ที่นี่ ในที่เก็บ Git ส่วนตัวที่เข้าถึงได้เฉพาะเจ้าของเท่านั้น
ทำไมต้องเป็นรีโพแยกต่างหากแทนที่จะเป็นไฟล์`.env`ในแต่ละโปรเจกต์ ?
-
การ push ความลับโดยไม่ตั้งใจ : เป็นไปไม่ได้ ความลับอยู่ใน private repository ที่โปรเจกต์สาธารณะไม่สามารถอ้างอิงได้โดยผิดพลาด
-
Audit : ประวัติ Git ให้ร่องรอยของการเปลี่ยนแปลงการกำหนดค่าทุกครั้ง ใครเปลี่ยนอะไร เมื่อใด ด้วยแฮช SHA ใด
-
ย้อนกลับ :`git revert`บนการกำหนดค่าที่เสียหาย ทันที โดยไม่ต้องสำรองข้อมูลด้วยตนเอง
ห้องสมุด: office/ ในฐานะข้อมูลที่ใช้สอยได้
`office/`เป็นส่วนเอกสารคู่ขนานของงานพัฒนา ประกอบด้วยบทความบล็อก ข้อกำหนดทางเทคนิค สื่อการฝึกอบรม (ไดเรกทอรีหลักสูตร FPA 38 ไดเรกทอรี, SPG/SPD, สคีมา JSON, อนุกรมวิธาน Bloom/Harrow/Krathwohl) — ทุกสิ่งที่ประกอบเป็นสื่อการสอน.
แต่`office/`ไม่ใช่แค่ลิ้นชักเก็บเอกสาร มันคือแหล่งข้อมูลที่มีโครงสร้างว่าปลั๊กอิน Gradle ของ`foundry/`บริโภค บทความบล็อกใน`office/`เป็นรายการที่ปลั๊กอินจะแปลงเป็น HTML SPG AsciiDoc ใน`office/metiers/FPA/`เป็นอาร์ติแฟกต์ที่ออร์เคสเตรเตอร์จะพาร์สเพื่อสร้างสไลด์ ควิซ และแคปซูลวิดีโอ
Et le `build.gradle.kts`ที่รากของ`office/`ไม่ใช่โค้ดธุรกิจ — เป็นสคริปต์สำหรับการใช้ระบบนิเวศของปลั๊กอิน. เขาพูดว่า "นี่คือปลั๊กอิน Gradle ที่ฉันใช้ นี่คือบริบทของเวิร์กสเปซของฉัน
เลส์ ฟอร์จ : foundry/ ในฐานะการนำไปใช้งาน
foundry/`มีโค้ดที่ถูกทำให้เป็นอุตสาหกรรม. 54 ที่เก็บ Git โดย 7 แห่งในจำนวนนี้ปัจจุบันอยู่ภายใต้การกำกับดูแลโดย.agents/`. นี่คือจุดที่วิสัยทัศน์กลายเป็นสิ่งที่ปฏิบัติได้จริง — ปลั๊กอิน Gradle, CI/CD, การทดสอบ JUnit5 + Cucumber
ความสัมพันธ์กับ`office/`เป็นแบบสองทิศทาง:
-
office/`No text was provided to translate. Please send the French text you’d like translated to Thai.`foundry/: ข้อมูลการสอนเป็นวัตถุดิบที่ปลั๊กอินใช้ -
foundry/`No source text was provided to translate.`office/: ปลั๊กอินสร้างข้อมูลที่ช่วยเสริม`office/` — legraph.json`ของ `graphify-gradle, สไลด์เด็คที่คอมไพล์แล้ว, รายงานการบิลด์
ข้อดี/ข้อเสีย : การจัดแนวเชิงพื้นที่ เทียบกับ การจัดแนวด้วยพรอมต์
มาเปรียบเทียบทั้งสองแนวทางกัน
แนวทางคลาสสิก: การจัดแนวด้วยพรอมต์นำหน้า
✅ โปร |
❌ คอนทรา |
ง่ายต่อการนำไปใช้ บล็อกข้อความใน system prompt |
เปราะบางเมื่อบริบทยาว : กฎจะถูกกลืนหายหลัง 80K โทเค็น |
ใช้ได้กับกฎทั่วไป (โทน, รูปแบบ) |
ไม่สามารถตรวจสอบได้ : ไม่มีสิ่งใดขัดขวางไม่ให้ LLM ละเมิดกฎ |
ไม่จำเป็นต้องคิดสถาปัตยกรรมของโครงการใหม่ |
ไม่สามารถโอนได้ : แต่ละ repo ประกาศกฎซ้ำ |
เป็นเพียงคำประกาศเท่านั้น : LLM รู้ว่าตน*ควรทำ* แต่ไม่มีสิ่งใดขัดขวางมันได้ |
แนวทางนี้: การจัดแนวโดยใช้ภววิทยาเชิงพื้นที่
✅ Pro |
❌ ต่อต้าน |
ทนทานต่อบริบทแบบยาว : กฎอยู่ในพาธของไฟล์ ไม่ใช่ในพรอมต์ที่อยู่ไกลออกไป |
ต้นทุนโครงสร้างพื้นฐานเริ่มต้น : การจัดโครงสร้างเวิร์กสเปซให้เป็นวงกลมต้องใช้เวลา |
ตรวจสอบได้เชิงกลไก : ความลับใน`foundry/ |
ต้องมีวินัย : ผู้ร่วมสมทบใหม่ต้องเข้าใจวงกลม |
โอนย้ายได้ : หนึ่ง`AGENT.adoc`standard เปิดเผยวงกลมให้กับทุกโครงการใหม่ |
ครอบคลุมเฉพาะข้อจำกัดเชิงพื้นที่ — สไตล์โค้ดยังคงอยู่ในพรอมต์ |
ความปลอดภัยโดยการออกแบบ : หนึ่ง`git push`ตั้งแต่`foundry/ |
|
สามารถใช้ได้โดยเอเจนต์ที่ไม่ใช่ LLM : ออร์เคสเตรเตอร์ Gradle สามารถกำหนดเส้นทางตามวงกลมได้ |
ผลประโยชน์หลักไม่ใช่เชิงป้องกัน (ความปลอดภัย การมองเห็น) — แต่เป็นสร้างสรรค์. เมื่อ LLM ทำงานในพื้นที่ซึ่งจัดโครงสร้างด้วยออนโทโลยี มันสามารถทำสิ่งที่ไม่มีพรอมต์ใดอนุญาตให้มันทำได้: สังเกตเดลตา
พีชคณิตเชิงสัมพันธ์ของเวิร์กสเปซและเดลตาที่สังเกตได้
เมื่อ LLM ไล่ดู`foundry/, เขามีโครงข่ายข้อมูลที่มีโครงสร้าง: โหนด (ปลั๊กอิน, ไฟล์, การทดสอบ, การพึ่งพา), เส้นเชื่อมที่มีชนิด (`import, depends_on, generates, tests), ความสัมพันธ์เชิงองค์ประกอบและเชิงลำดับ (`training-gradle`ดึงคลังอ้างอิง`slider-gradle`สร้างสไลด์ →`capsule-gradle`ตัดต่อวิดีโอ)
พีชคณิตนี้ไม่ได้เขียนไว้ที่ใดอย่างชัดเจน — แต่它具有*สังเกตได้* แต่ละ`build.gradle.kts`เปิดเผยส่วนที่ต้องพึ่งพา แต่ละ`INDEX.adoc`แสดงการอ้างอิงข้าม
LLM สังเกตพีชคณิตนี้และตรวจพบเดลตา: ช่องว่างระหว่างสิ่งที่ระบบสามารถผลิตได้อยู่แล้วกับสิ่งที่วิสัยทัศน์อธิบาย
จากเดลตานี้ เขาสามารถกำหนด…แผนที่ผู้เชี่ยวชาญด้านธุรกิจ— CDA (นักออกแบบและพัฒนาแอปพลิเคชัน, Kotlin/Gradle/JHipster) และ FPA (ผู้ฝึกอบรมวิชาชีพสำหรับผู้ใหญ่, Pédagogie/Qualiopi/Bloom) — และระบุสิ่งที่ยังขาดสำหรับผู้เชี่ยวชาญแต่ละคน
Expert CDA (Kotlin/Gradle/JHipster)
├── Plugins : jhipster-gradle-plugins, plantuml-gradle,
│ codebase-gradle
├── Delta : pas encore de SPG CDA formalisé,
│ pas de fine-tuning expert CDA
Expert FPA (Pédagogie/Qualiopi/Bloom)
├── Plugins : training-gradle, slider-gradle,
│ school-backoffice/forms, capsule-gradle
├── Matériel : 38 modules cours, SPG/SPD, taxonomies
└── Delta : parser AsciiDoc→JSON à créer,
orchestrateur à coderLLM ไม่จำเป็นต้องมีใครบอกว่าต้องทำอะไร เดลต้าเกิดขึ้นจากโครงสร้าง
เวกเตอร์ผสมของบริบท: RAG + pgvector + Graphify
พีชคณิตเชิงสัมพันธ์ไม่ใช่โครงสร้างทางทฤษฎี มันถูก ทำให้เป็นรูปธรรม โดยองค์ประกอบสามส่วนที่ก่อตัวเป็นเวกเตอร์คอมโพสิตของบริบทสำหรับ LLM
องค์ประกอบที่ 1 — RAG LangChain4j + PostgreSQL pgvector
ฉันมี LangChain4j ที่ใช้งานจริงในโปรดักชันแล้วในปลั๊กอินสองตัว:`slider-gradle`(ผู้ให้บริการ LLM 4 ราย) และ`plantuml-gradle`(7 ผู้ให้บริการ). เอ็มเบดดิง ONNX (AllMiniLmL6V2) จัดทำดัชนีข้อมูลของ`office/`และซอร์สโค้ดของ`foundry/`ใน PostgreSQL + pgvector
RAG นี้ทำงานบนสองมิติ:
-
ข้อมูลมิติ : เอกสาร`office/`(SPG, บทความ, หลักสูตรอบรม, สคีมา JSON)
-
มิติโค้ด : โค้ดเบส`foundry/`(ซอร์สโค้ด Kotlin, การทดสอบ Cucumber, AGENT.adoc)
จุดตัดครอบคลุมทั้ง อะไร (โดเมนธุรกิจ) และ อย่างไร (การนำไปปฏิบัติ)
องค์ประกอบ 2 — Knowledge Graph Graphify
Graphify ได้รับการผสานรวมไว้ใน`plantuml-gradle`(109 tests, 380/380 PASS) และสร้าง`graph.json`— กราฟความรู้แบบมีโครงสร้างที่มีโหนด เส้นเชื่อม และชุมชนที่ตรวจพบโดยอัตโนมัติ
ต่างจาก RAG ที่ทำงานโดยใช้ความคล้ายคลึงเชิงเวกเตอร์ (แบบคลุมเครือ) กราฟความรู้ทำงานโดยความสัมพันธ์ที่แน่นอน(ดีเทอร์มินิสติก) :`graphify query`สำหรับการสอบถามเชิงความหมาย (~50 โทเคน),`graphify path`เพื่อนำทาง,`graphify explain`เพื่ออธิบาย
องค์ประกอบที่ 3 — Graphify แบบเพิ่มทีละส่วน: กระจัดกระจาย, รวมได้, พร้อมใช้
นี่คือการตัดสินใจด้านสถาปัตยกรรมที่สำคัญ
Graphify ไม่ควรอยู่ในรีโพซิทอรีเดียว มันต้องดำรงอยู่อย่างกระจัดกระจายในแต่ละปลั๊กอิน:
-
แต่ละปลั๊กอิน มีทาสก์ Gradle ฝังอยู่`updateKnowledgeGraph`ซึ่งเรียก Graphifyบนสโคปของตัวเองและผลิต`graph.json`ท้องถิ่น
-
สคริปต์ build ของ`office/
บริโภค`graphify-gradle`กับ`rootDir = /home/cheroliv/workspace`และผลิต`graph.json ทั่วโลกซึ่งรวบรวมกราฟท้องถิ่น -
RAG ของแต่ละปลั๊กอิน ฉีด`graph.json`ระดับโลกเช่นตัวกรองบริบทสำหรับคำขอ LLM
TÂCHE GRADLE (dans chaque plugin)
↓
graphify → graph.json (scope local)
↓
office/build.gradle.kts → graph.json (scope global)
↓
RAG pgvector (dans slider, plantuml, codebase...)
↓ ← injection du graph.json comme filtre
LLM (deepseek-v4-pro)
↓ ← observation algèbre relationnelle
↓ ← détection delta vs cartographies experts
PRIORISATION → prochaine tâcheผลลัพธ์: LLM ไม่ได้ค้นหาในความว่างเปล่า — มันนำทางในพื้นที่ที่จัดโครงสร้างโดยกราฟความรู้ คำขอเกี่ยวกับ "สร้างไดอะแกรม" สามารถเข้าถึงโหนดที่เกี่ยวข้องของกราฟได้
การจำแนกประเภท RGPD อัตโนมัติ: LLM ในฐานะเราเตอร์
ออนโทโลยีเชิงพื้นที่ไม่ได้เพียงแค่ทำให้ LLM สอดคล้อง — แต่ยังมอบให้แก่ LLMตารางการจำแนกประเภท RGPDเพื่อกำหนดเส้นทางข้อมูลแต่ละรายการไปยังโซนที่ชอบด้วยกฎหมายของตน
เกณฑ์ |
การตรวจจับ LLM |
การกระทำ |
ระดับสูงสุด |
ข้อมูลส่วนบุคคล (ชื่อ, อีเมล, IP) |
รูปแบบ`@`, IP, ชื่อเฉพาะ |
ทำให้ไม่ระบุตัวตน`[OF_PILOTE]`หรือเราเตอร์ระดับ 2 |
2 |
โทเคน / ซีเคร็ต / ข้อมูลรับรอง |
รูปแบบ`sk-… |
เราเตอร์ → |
1 |
URL ภายใน |
ประกอบด้วย`localhost`, IP ส่วนตัว |
ทำให้ไม่ระบุชื่อ`${API_URL}` |
2 |
ข้อมูลการสอน (SPG, รายวิชา) |
โครงสร้าง Bloom/Qualiopi |
เราเตอร์ → |
3 |
ซอร์สโค้ด / ทดสอบ |
ส่วนขยาย`.kt`, |
เราเตอร์ → |
4 |
เมื่อสิ้นสุดเซสชัน LLM จะดำเนินการภารกิจโดยรวมPlease provide the French text you’d like me to translate into Thai.
-
การอ่านของ`.gitignore`รากสำหรับระบุอาร์ติแฟกต์ชั่วคราว (ให้แยกออกจากสแนปช็อต) เทียบกับอาร์ติแฟกต์เชิงกลยุทธ์ (ให้เก็บเป็นประวัติ)
-
รายการไฟล์ทั้งหมด`.adoc`ของราก`workspace/`
-
การกรอง: การยกเว้นไฟล์ที่ระบุไว้ใน`.gitignore`, การรวมผู้อื่นทั้งหมด
-
คัดลอกไปยัง`configuration/vision-archive/$DATE/
และอัปเดต symlink`latest/ -
คอมมิตในรีโพซิทอรี`configuration/`พร้อมข้อความที่มีโครงสร้าง
-
การจำแนกประเภทตาม GDPR โดยอัตโนมัติของไฟล์ที่แก้ไขแต่ละไฟล์ (ทุกวง)
-
การกำหนดเส้นทาง : ข้อมูล`office/
→ คอมมิตส่วนตัว, โค้ด`foundry/`No source text was provided to translate. Please send the French text you’d like translated into Thai../gradlew check`, การกำหนดค่า → คอมมิต -
รายงานที่มีโครงสร้างพร้อมการแจ้งเตือนเกี่ยวกับ GDPR และการยืนยันการเก็บถาวร
Le `.gitignore`root ไม่ใช่ไฟล์กำหนดค่า Git — มันคือไฟล์การกำกับดูแลการบันทึกประวัติ. มันกำหนดสคีมาที่ LLM ใช้ในการตัดสินว่าไฟล์ใดจากสวนลับจะเข้าสู่ชีวประวัติเชิงกลยุทธ์ และไฟล์ใดที่ทิ้งได้
LLM ไม่ใช่เพียงเครื่องสร้างข้อความธรรมดาอีกต่อไป มันคือผู้จัดการข้อมูลของระบบนิเวศ — ผู้ผลิต, ตัวจำแนกประเภท, เราเตอร์
แผนงาน : จาก AsciiDoc ถึง LangGraph4j
วันนี้ การกำกับดูแลนี้เป็น ดีเทอร์มินิสติก : LLM ใช้ขั้นตอนที่อธิบายไว้ในไฟล์ AsciiDoc นี่คือระยะที่ 1— วิศวกรรมพรอมต์ด้วยหน่วยความจำ LLM
La เฟส 2จะแยกแต่ละขั้นตอนของกระบวนการออกมาในทาสก์ Gradle ที่มีชนิดPlease provide the French text you’d like me to translate into Thai.
./gradlew endSessionWorkspace → snapshot vision-archive
./gradlew endSessionProject → archive .agents/
./gradlew endSessionReport → rapport multi-zonesLa ระยะที่ 3จะจำลองกระบวนการสิ้นสุดเซสชันเป็นแผนภาพสถานะกับhttps://github.com/langgraph4j/langgraph4j[LangGraph4j]I don’t see any French text to translate. Could you please provide the source text?
[Start] → [Inventaire fichiers modifiés]
→ [Classification RGPD] (nœud ONNX)
→ [Branchement par cercle]
├→ cercle 0 → snapshot → commit
├→ cercle 2 → anonymisation → commit
├→ cercle 4 → archive → commit
└→ cercle 1 → commit configuration/
→ [Rapport] → [End]กราฟนี้จะถูกจัดเก็บเวอร์ชันใน CI/CD ทำงานโดย Gradle และกำหนดค่าผ่าน GitHub Secrets ของปลั๊กอิน LLM จะไม่ต้องตัดสินใจเรื่องการกำหนดเส้นทางอีกต่อไป — กราฟจะเป็นผู้ทำ
สิ่งที่สถาปัตยกรรมนี้แก้ไข (และสิ่งที่มันไม่ได้แก้ไข)
|
ออนโทโลยีเชิงพื้นที่ไม่ได้ครอบคลุมทุกอย่าง ข้อกำหนดรูปแบบการเขียนโค้ด การตั้งชื่อ การตัดสินใจออกแบบสถาปัตยกรรม — ทั้งหมดนี้ยังคงอยู่ในพรอมต์ สิ่งที่ออนโทโลยีเชิงพื้นที่แก้ไขได้คือชั้นความปลอดภัยและการมองเห็น: ที่ซึ่งแต่ละไบต์ต้องอยู่ และใครที่สามารถมองเห็นมันได้ |
นี่คือสิ่งที่มันนำมาอย่างเป็นรูปธรรม:
-
ไม่มี`git push`โดยบังเอิญของความลับ : ความลับอยู่ใน`configuration/
(วงกลม 1) โครงการสาธารณะอยู่ใน`foundry/(วงกลม 4) ไม่มีเส้นทางใดตัดผ่านทั้งสอง -
ไม่มีโค้ดทางธุรกิจในข้อมูล :`office/
มี.adoc`, YAML, JSON Schemas — แต่ไม่มี`.kt`. Le `build.gradle.kts`ซึ่งอาศัยอยู่ที่นั่นเป็นสคริปต์การบริโภค ไม่ใช่โค้ดธุรกิจ -
ไม่มีการเปิดเผยความคิดเชิงกลยุทธ์ : เอกสารวิสัยทัศน์อยู่ในสวนลับ (รูทที่อยู่นอก CVS) สแนปช็อตอยู่ใน`configuration/`(ตู้เซฟส่วนตัว) ไม่มีใคร แม้แต่ในวงความไว้วางใจที่ขยายออกไป อ่านจุดกำเนิดของกลยุทธ์
-
การจัดลำดับความสำคัญอัตโนมัติ : LLM สังเกตเดลตาระหว่างพีชคณิตเชิงสัมพันธ์ (สิ่งที่มีอยู่) กับแผนที่ของผู้เชี่ยวชาญ (สิ่งที่จำเป็น) งานพัฒนาถัดไปเกิดขึ้นจากเดลตานี้
บทสรุป: สถาปัตยกรรมในฐานะวาทกรรม
ฉันไม่ใส่แถลงการณ์ทางการเมืองในฟุตเตอร์ของเว็บไซต์ฉัน ฉันไม่ใส่กฎทางจริยธรรมในพรอมป์ของฉัน การจัดแนวไม่ได้อยู่ในข้อความ — มันอยู่ในระบบไฟล์.
เมื่อ LLM ทำงานในพื้นที่นี้ มันไม่สามารถทำให้ความลับรั่วไหลได้ (พาธป้องกันไว้) มันไม่สามารถสับสนข้อมูลการสอนกับโค้ดต้นฉบับได้ (โซนทางกายภาพแตกต่างกัน) มันไม่สามารถลืมกฎความปลอดภัยที่ 80,000 โทเคนได้ — เพราะกฎไม่ได้อยู่ในพรอมป์ต์ แต่มันอยู่ใน`workspace/`Please provide the French text you’d like me to translate.`configuration/`No source text was provided to translate — please send the French text you’d like translated into Thai.`office/`No source text was provided to translate. Please send the French text you’d like translated into Thai.`foundry/`ที่การอ่านไฟล์แต่ละครั้งจะกระตุ้นอีกครั้ง
นี่คือหลักการของ secure by design ที่นำมาใช้กับการจัดแนวเอเจนต์: ไม่ขอให้ LLM จดจำกฎต่าง ๆ แต่ทำให้สถาปัตยกรรมทำให้ข้อผิดพลาดเป็นไปไม่ได้ในเชิงโครงสร้าง
และอีกอย่าง มันให้สิ่งที่ไม่มีพรอมต์ใดให้แก่ LLM ได้ นั่นคือความสามารถในการรับรู้ว่าตอนนี้เขาอยู่ที่ไหน มีอะไรอยู่บ้าง ขาดอะไรไป — และสรุปจากสิ่งนั้นว่าเขาต้องทำอะไร
ข้อมูลอ้างอิง
-
บทความเกี่ยวกับการกำกับดูแลเอเจนต์ Eager/Lazy:กำกับดูแลเอเจนต์ AI ด้วย AsciiDoc
-
บทความเกี่ยวกับกลไก Hot/Warm/Cold :สไลดิ้งวินโดว์และคลื่นความเย็น
-
บทความเกี่ยวกับการตรวจสอบบริบท:เมื่อการกำกับดูแลของคุณเองกลายเป็นปัญหา
-
บทความเกี่ยวกับการเปรียบเทียบ LLMs ทั้งสาม:DeepSeek-V4-Pro, Kimi K2.6, GLM-5.1