Serverless CMS ( เพียงแค่ข้อความธรรมดา !!! ) ขึ้นอยู่กับการทำเครื่องหมายด้วยส่วนขยายสำหรับการจำแนกประเภทอนุกรมวิธานหลายมิติทำให้สามารถนำทางเนื้อหาตามหัวข้อ (แกน) และหัวข้อย่อย (พิกัด)
โครงการนี้มีวัตถุประสงค์เพื่อให้เครื่องมือที่ใช้งานง่ายสำหรับการจัดการเอกสาร "ชีวิตยาวนาน" (ปีหรือหลายสิบปี)
แนะนำให้จัดเก็บและจัดประเภทงานวิจัย (PHD) อย่างปลอดภัยเอกสารซอฟต์แวร์ที่ซับซ้อนขั้นตอนที่ซับซ้อนการเขียนหนังสือหน้าเว็บ "อุตสาหกรรม" ตัวอย่างเล็ก ๆ น้อย ๆ สำหรับความใจร้อน:
เนื่องจากเนื้อหาเป็นเพียงข้อความธรรมดา (เทียบกับรูปแบบฐานข้อมูลไบนารีแปลก ๆ ) หมายความว่าเครื่องมือจำนวนมากสามารถนำกลับมาใช้ใหม่เพื่อแก้ไขและจัดการเนื้อหาตาม "ทำสิ่งเดียวและทำถูกต้อง!" ปรัชญา UNIX
คุณสมบัติถัดไปมาฟรี:
┌──────────────────────────────────────────────────────────────┐
├─ CONVENTIONAL CMS (CONFLUENCE, SHAREPOINT, ...) ────────────┤
├──────────────────────────────────────────────────────────────┤
│ │
│1) Central CMS Server 2) "Fool" Browser │
│ ────────────────── ────────────────│
│ DDBB <··· network···> Render conent │
│ Single place of failure │
│ (single place of attack) │
│ Binary format │
│ Server/CMS/Network Admins │
│ │
├──────────────────────────────────────────────────────────────┤
├─ STATIC SITE GENERATOR (NEXT, ...) ─────────────────────────┤
├──────────────────────────────────────────────────────────────┤
│ │
│1) "Source" Content 3) Web Server │
│ ───────────────── ┌····> ──────────── ···┐ │
│ (git versioned, p2p · Publish · │
│ distributed) · "compiled" html · │
│ · · · │
│ · · · │
│ · · v │
│ · 2) Compile 4)"Fool" Browser │
│ └─····> ───────────────── ────────────── │
│ Generates HTML Render content │
│ in opinionated ways │
│ using "complex" tooling │
│ (npm, transpilers, modules, │
│ packagers, ...) │
│ │
├──────────────────────────────────────────────────────────────┤
├─ TXT WORLD DOMINATION PROJECT ──────────────────────────────┤
├──────────────────────────────────────────────────────────────┤
│ │
│1) "Source" Content 2) "Inteligent" Browser │
│ ───────────────────────── ··> ─────────────────────────── │
│ markdown+topic.sub. tags Fetch local/remote "payload"│
│ (git versioned, p2p Processes it. Generate │
│ distributed) HTML, taxonomy, indexes, │
│ · extensions, ... │
│ · │
│ ├─·· or ··········>2) Printer │
│ · ─────────────────────────── │
│ · Print to paper │
│ · (extensions ignored) │
│ · │
│ ├─·· or ··········>2) LLM Learning Algorithm │
│ · ─────────────────────────── │
│ · - LLM training algorithm. │
│ · topics/subtopics provide │
│ · (huge) dimensionality │
│ · reduction!!! │
│ · │
│ ├─·· or ···········>2) JAVA/Rust/Python/... IDE │
│ · ─────────────────────────── │
│ · Improve source code │
│ · navigation based on │
│ · topics.subtopics concerns │
│ · like UI, QA, security, .... │
│ · │
│ ├─·· or ···········>2) (Fill with new ideas and │
│ · use-cases) │
└──────────────────────────────────────────────────────────────┘
ชุดหรือชุดย่อยของไฟล์ข้อความ (markdown, ซอร์สโค้ด) สามารถจัดกลุ่มเป็นไฟล์เสมือนสุดท้าย "ใหญ่" เดียวผ่านรายการ "payload" รายการเป็นเพียงไฟล์ txt ปกติที่ระบุในแต่ละบรรทัดใหม่รายการของไฟล์ markdown เพื่อ concatenate เพื่อสร้างเอกสาร markdown สุดท้าย ตัวอย่าง:
full_book.payload security_book.payload frontend_book.payload
----------------- --------------------- ---------------------
./introduction.md ./chapter4.md ./chapter1.md
./chapter1.md ./chapter5.md ./chapter2.md
./chapter2.md ./chapter9.md ./chapter9.md
./chapter3.md
./chapter4.md
./chapter5.md
./chapter6.md
./chapter7.md
./chapter8.md
./chapter9.md
ตัวอย่างเพียงเล็กน้อยเกี่ยวกับวิธีการใช้โครงการนี้เพื่อจัดทำเอกสารเอกสารในโลกแห่งความเป็นจริง:
ทำไมต้องจดบันทึกในยุคของการเรียนรู้ของเครื่องจักรและแบบจำลองภาษาขนาดใหญ่?
พูดง่ายๆ พวกเขาเติมเต็มซึ่งกันและกัน:
AI ทำงาน "ดี" เมื่อนำไปใช้กับบริบทที่ จำกัด (ไม่เล็ก) ตัวอย่างเช่นงานการเขียนโปรแกรมขั้นพื้นฐานหรืองานคณิตศาสตร์ (ไม่ธรรมดา) ที่มีชุดและการดำเนินงานที่กำหนดไว้อย่างดี (ปัญหาเกี่ยวกับพีชคณิตปัญหาเหมือนหมากรุก ... )
ฉันทำงานในโลกการพัฒนาซอฟต์แวร์ ให้ฉันสรุปประสบการณ์ของฉัน:
ในอีกด้านหนึ่งเมื่อจดบันทึกจากผู้เชี่ยวชาญเราสามารถติดแท็กผลิตภัณฑ์ที่แข่งขันได้เน้นข้อดี/ข้อเสียใช้แผ่นโกงคำอธิบายประกอบกับกรณีการใช้งานคุณสมบัติที่รอดำเนินการสิ่งต่าง ๆ เช่นนั้น
เราสามารถดึงข้อมูล "ข้อมูล" บางส่วนและกรอกบันทึกก่อนหน้านี้ (อาจเขียนเมื่อ 4 ปีก่อน) เพื่อให้เนื้อหาที่ไม่สมบูรณ์เริ่มที่จะ "เข้าใจ" ในที่สุดเราสามารถตัดสินใจได้อย่างสมเหตุสมผลมากขึ้น
เป็นไปได้ผ่านการจัดวิศวกรรมพรอมต์ขั้นสูงเพื่อให้ AI ส่งคืนคำตอบที่สมเหตุสมผล .. แต่วิศวกรรมการแจ้งเตือนขั้นสูงเป็นวิธีที่ยากขึ้นและใช้เวลานานกว่าที่เพียงแค่จดบันทึกและจำแนกโน้ต ในความเป็นจริงฉันจะบอกว่าการจดบันทึกและจำแนกบันทึก การสร้างอนุกรมวิธานที่กำหนดไว้อย่างดีและมีเสถียรภาพคือ "ต้อง" สำหรับ "ขั้นสูง" ที่ได้รับการปรับปรุงด้วยวิศวกรรม
เราสามารถถามบอท LLM เกี่ยวกับการแก้ปัญหาและหลายครั้งที่มันจะทำงาน มีคำถามเกิดขึ้น:
เรากำลังถาม LLM เพราะเราเพิกเฉยต่อการแก้ปัญหาในสถานที่แรกดังนั้นเราอาจเพิกเฉยต่อวิธีการแก้ปัญหาทางเลือกและเราอาจเพิกเฉยต่อสิ่งอื่น ๆ อีกมากมาย (จำ ความเสี่ยงของสิ่งแปลกปลอมที่ไม่รู้จัก ) หากเราจดบันทึกเกี่ยวกับงานที่เกี่ยวข้องและทางเลือกที่เกี่ยวข้องสำหรับปัญหาที่คล้ายกันตอนนี้เราสามารถเพิ่มข้อมูลดังกล่าวลงในการแจ้งเตือนของเราและเรายังสามารถพิจารณาการกรอกข้อมูลด้าน "orthogonal" (QA, ความปลอดภัย, ความโดดเด่น, รูปแบบที่ดีที่สุด, ... ) ด้วยวิธีนี้เราช่วย LLM ในการลดขนาดปัญหาและพรอมต์ของเราจะเป็นพรอมต์ที่มีประสิทธิภาพมากขึ้น
จำเป็นต้องพูด LLM ยังสามารถช่วยเราในการออกแบบอนุกรมวิธานของเราโดยการแนะนำหัวข้อและหัวข้อย่อย ในแง่นั้นทั้งสองระบบสามารถเลี้ยงซึ่งกันและกันในวงไม่มีที่สิ้นสุด เยี่ยมมากใช่มั้ย