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

DeepTutor พยายามแก้ปัญหานี้ด้วยแนวคิดที่สำคัญกว่าจำนวนฟีเจอร์: เก็บบริบทของผู้เรียนไว้ใช้ต่อเมื่อเปลี่ยนกิจกรรมภายใน workspace เดียว ตามคำอธิบายใน repository โหมด Chat, Quiz, Research, Visualize, Solve และ Mastery Path ใช้ agent loop เดียวกัน—โมเดลคิดเป็นรอบ เรียกเครื่องมือเมื่อจำเป็น ดูผลที่ได้ แล้วจบด้วยคำตอบ—แต่เปลี่ยนวัตถุประสงค์ตามงาน

จุดที่ควรประเมินจึงไม่ใช่ “มีครบกี่โหมด” แต่เป็น “เมื่อเปลี่ยนงานแล้ว ระบบใช้สิ่งที่รู้อยู่ต่อได้ดีแค่ไหน” ถ้าความต่อเนื่องนี้ตรงกับปัญหาของทีม DeepTutor ก็มีเหตุผลให้ทดลองบนระบบของตัวเอง ถ้าแต่ละงานแยกจากกันอยู่แล้ว เครื่องมือรวมศูนย์อาจเพิ่มภาระมากกว่าลดงาน

แกนของ DeepTutor มีสามชั้น

ลองวางรายการฟีเจอร์ไว้ก่อน แล้วมองระบบเป็นความสัมพันธ์สามชั้น

1. ชั้นการทำงาน: agent loop รับโจทย์ เรียกเครื่องมือ ดูผล และถามกลับได้ เมื่อข้อมูลไม่พอ เครื่องมือ ask_user ทำให้เอเจนต์หยุดถามคำถามแบบมีโครงสร้างแทนการเดา แล้วค่อยทำงานต่อหลังได้รับคำตอบ
2. ชั้นวัตถุประสงค์: Chat, Solve, Research, Quiz, Visualize และ Mastery Path เปลี่ยนชนิดของงาน แต่ยังอยู่บนวงจรการทำงานเดียวกัน
3. ชั้นบริบท: สิ่งที่ repository เรียกว่า shared context ไม่ใช่คำกว้าง ๆ แต่ประกอบด้วย knowledge bases, หนังสือ, ร่างใน Co-Writer, notebooks, question banks, personas และ Memory

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

ตัวอย่างเช่น ทีมอาจนำคู่มือภายในเข้า knowledge base ใช้ Chat ถามเพื่อทำความเข้าใจ ให้ Research ช่วยขยายประเด็น สร้างคำถามผ่าน Quiz แล้วนำข้อสรุปไปเรียบเรียงใน Co-Writer ทั้งหมดนี้เป็นภาพการใช้งานที่สอดคล้องกับโครงสร้างที่ repository อธิบาย ไม่ใช่ผลยืนยันว่าแต่ละขั้นจะให้คำตอบที่แม่นหรือเหมาะกับเอกสารของคุณเสมอไป

พื้นที่ต่าง ๆ ต่อกันอย่างไร

Chat เป็นทางเข้าของ agent loop

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

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

Knowledge Center เป็นแหล่งอ้างอิง ไม่ใช่เครื่องรับประกันคำตอบ

knowledge base แต่ละชุดผูกกับ retrieval engine หนึ่งตัว ตัวเลือกที่ repository ระบุมี LlamaIndex, PageIndex, GraphRAG, LightRAG, LightRAG Server, Tencent IMA และ Obsidian นอกจากนี้ โครงการยังอธิบายว่าคลัง RAG มีเวอร์ชันและสลับ document parser ได้

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

สำหรับผู้ใช้ Obsidian จุดน่าสนใจคือ repository ระบุว่าสามารถเชื่อม vault เป็นหนึ่งในแหล่งข้อมูลได้ แต่ข้อมูลที่มีไม่ได้ยืนยันรายละเอียดเรื่องความครบถ้วนของการนำเข้า การซิงก์ หรือพฤติกรรมเมื่อไฟล์เปลี่ยน เรื่องเหล่านี้ควรกลายเป็น test case ไม่ใช่สมมติฐาน

Co-Writer และ Book ทำให้ผลลัพธ์ไม่จบอยู่ในแชต

Co-Writer เป็นพื้นที่เขียน Markdown แบบแบ่งมุมมอง บันทึกอัตโนมัติและแสดงตัวอย่างสด ผู้ใช้เลือกข้อความบางช่วงเพื่อสั่งเขียนใหม่ ขยาย หรือลดความยาวได้ จึงเหมาะกับงานที่คำตอบจากแชตต้องกลายเป็นเอกสารที่แก้ต่อ ไม่ใช่ข้อความใช้ครั้งเดียว

ส่วน Book รับวัสดุจาก knowledge bases, notebooks, question banks หรือประวัติแชต แล้วเสนอเค้าโครงบทก่อนสร้างเนื้อหา จุดที่น่าทดลองไม่ใช่แค่ระบบ “สร้างหนังสือได้” แต่คือเค้าโครงและเนื้อหาที่สร้างยังตามขอบเขตของวัสดุต้นทางหรือไม่ และเมื่อกลับไปแก้ความรู้ต้นทางแล้ว workflow ของทีมจัดการฉบับที่สร้างไปอย่างไร

My Agents เป็นสะพานไปยังเครื่องมือบนเครื่อง

repository ระบุว่า My Agents เชื่อม CLI ของ Claude Code, Codex, Gemini, Kimi, opencode หรือ MiMo Code ที่ทำงานอยู่บนเครื่อง และสตรีมงานของเอเจนต์ที่ปรึกษาเข้า Activity panel ได้ สำหรับทีมพัฒนา นี่อาจช่วยเชื่อมงานเรียนรู้กับงานโค้ดเดิมโดยไม่ต้องย้ายทุกอย่างเข้าเครื่องมือเดียว

อย่างไรก็ตาม คำว่า “เชื่อมได้” ยังไม่ตอบเรื่องสิทธิ์เข้าถึง ขอบเขตข้อมูล ความผิดพลาด หรือการตรวจสอบย้อนหลัง คุณควรกำหนดงานเล็ก ๆ และข้อมูลที่ไม่อ่อนไหวเพื่อดูพฤติกรรมจริงก่อนเปิดให้แตะ repository หรือเอกสารสำคัญ

ทดลองทางสั้นด้วย PyPI

เส้นทาง PyPI เหมาะเมื่ออยากเห็นทั้ง Web app และ CLI โดยไม่ clone source ตาม snapshot ของ README วิธีนี้ต้องมี Python 3.11–3.13 และ Node.js 20+ อยู่ใน PATH

mkdir -p my-deeptutor && cd my-deeptutor
pip install -U deeptutor
deeptutor init
deeptutor start

deeptutor init จะถามเรื่องพอร์ต ผู้ให้บริการ LLM และตัวเลือก embedding จากนั้น deeptutor start จะเริ่ม backend กับ frontend ให้เปิด URL ที่ terminal แสดง ค่าเริ่มต้นตาม README คือ http://127.0.0.1:3782 และหยุดทั้งสองส่วนได้ด้วย Ctrl+C ใน terminal เดิม

ก่อนทำตามคำสั่ง ควรตรวจ README ของ release ที่กำลังจะใช้ เพราะข้อกำหนดเวอร์ชัน พอร์ต และขั้นตอนอาจเปลี่ยนจาก snapshot นี้ หากต้องแก้ตัวระบบหรือพัฒนาจาก checkout เส้นทางติดตั้งจาก source ระบุ Python 3.11–3.13 และ Node.js 22 LTS ซึ่งต่างจากขั้นต่ำของ PyPI

หรือแยกการทดลองไว้ใน Docker

ถ้าต้องการเริ่มด้วย container เดียว repository ระบุ image ghcr.io/hkuds/deeptutor:latest สำหรับ stable release ส่วน ghcr.io/hkuds/deeptutor:pre ใช้กับ pre-release เมื่อมี ตัวอย่างสำหรับ stable คือ

docker run --rm --name deeptutor \
  -p 127.0.0.1:3782:3782 \
  -v deeptutor-data:/app/data \
  ghcr.io/hkuds/deeptutor:latest

จากนั้นเปิด http://127.0.0.1:3782 ข้อมูลจะคงอยู่ใน volume deeptutor-data ที่ mount ไปยัง /app/data สำหรับการใช้งานทั่วไป README ระบุว่า publish เฉพาะพอร์ต frontend 3782 ก็พอ ไม่จำเป็นต้องเปิดพอร์ต backend 8001

ถ้าต้องการรันแบบ detached และลบ container เองภายหลัง ให้ใช้คำสั่งแยกนี้โดยเพิ่ม -d และเอา --rm ออก

docker run -d --name deeptutor \
  -p 127.0.0.1:3782:3782 \
  -v deeptutor-data:/app/data \
  ghcr.io/hkuds/deeptutor:latest

จากนั้นใช้คำสั่งต่อไปนี้ดู log หยุด และลบ container ตามลำดับ ส่วน volume deeptutor-data จะยังคงอยู่

docker logs -f deeptutor
docker stop deeptutor
docker rm deeptutor

การรันใน container ช่วยกำหนดขอบเขตการติดตั้ง แต่ยังไม่ใช่หลักฐานว่า data locality, privacy หรือ security เหมาะกับข้อกำหนดขององค์กร ก่อน self-host ต้องตรวจเส้นทางข้อมูล การตั้งค่า provider ข้อมูลที่เก็บใน volume การสำรอง และสิทธิ์ของผู้ใช้แยกต่างหาก

CLI และ NDJSON เปิดทางให้ทดลองแบบวัดผลซ้ำได้

นอกจากหน้าเว็บ deeptutor chat เปิด interactive REPL ส่วน deeptutor run <capability> <message> รันงานหนึ่งครั้งแล้วจบ เช่น

deeptutor run deep_solve "Find d/dx[sin(x^2)]" --tool reason --format json

เมื่อเติม --format json แต่ละ turn จะสตรีมเป็น NDJSON หนึ่งเหตุการณ์ต่อบรรทัด และทุกบรรทัดมี session_id เราสามารถส่ง ID เดิมกลับผ่าน --session เพื่อเชื่อมหลาย turn ให้อยู่ใน session เดียวกัน

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

ทดลองให้ตอบคำถาม ไม่ใช่ทดลองเพื่อดูว่ารันขึ้นไหม

การเปิดหน้า frontend ได้พิสูจน์เพียงว่าหน้าเว็บเริ่มทำงาน ไม่ได้ยืนยันว่า backend, provider, retrieval และการเก็บข้อมูลทำงานครบถ้วน หรือว่าระบบคุ้มกับภาระ self-host วิธีที่มีประโยชน์กว่าคือเลือกงานจริงขนาดเล็กหนึ่งเส้นทาง เช่น เอกสารภายในหนึ่งชุด คำถามที่ทีมรู้คำตอบ 15–20 ข้อ และชิ้นงานปลายทางหนึ่งแบบ แล้วจดผลตามเกณฑ์ต่อไปนี้

ตั้งเกณฑ์ผ่านก่อนเริ่ม เช่น คำถามสำคัญต้องตอบถูกอย่างน้อยตามสัดส่วนที่ทีมยอมรับ เวลาตรวจต่อชิ้นต้องไม่เกินเพดาน และการเปลี่ยนโหมดต้องลดการป้อนข้อมูลซ้ำอย่างเห็นได้ชัด หากไม่กำหนดไว้ล่วงหน้า เรามักสรุปจากความลื่นไหลของเดโมแทนผลที่งานจริงต้องการ

ข้อมูลที่มีพอให้ลอง แต่ยังไม่พอให้รับรอง

ผู้พัฒนาระบุว่า DeepTutor เป็นโครงการโอเพนซอร์สภายใต้ Apache License 2.0 นำโดย Bingxi Zhao ในกลุ่ม HKUDS และยังไม่มีผลิตภัณฑ์ออนไลน์แบบชำระเงิน โครงการยังรายงานว่าได้ 10,000 GitHub stars ใน 39 วัน และ 20,000 stars ใน 111 วัน ตัวเลขเหล่านี้บอกได้ว่าโครงการได้รับความสนใจตามที่ผู้พัฒนารายงาน แต่ไม่ได้วัดความแม่น ความเสถียร ความปลอดภัย หรือต้นทุนการดูแล

หลักฐานที่ใช้ในบทนี้มาจาก README ของโครงการ จึงรองรับคำอธิบายว่า DeepTutor ออกแบบอะไร เชื่อมองค์ประกอบใด และติดตั้งตามขั้นตอนใด แต่ไม่มี benchmark ผลทดสอบอิสระ threat model หรือประสบการณ์ใช้งานระยะยาวให้ตัดสินแทนคุณ

ดังนั้น verdict ที่สมเหตุสมผลตอนนี้คือ น่าลองเมื่อปัญหาของคุณคือบริบทขาดตอนระหว่างกิจกรรมการเรียนรู้หลายแบบ ไม่ใช่ “พร้อม self-host” ตั้งแต่เห็นรายการฟีเจอร์ เริ่มจากข้อมูลขนาดเล็ก วัด workflow ที่ต้องการจริง แล้วให้ผลทดลองเป็นตัวตอบว่าจะรับภาระรันและดูแลระบบต่อหรือหยุดเพียงเท่านี้

ที่มา: GitHub repository ของ HKUDS/DeepTutor (README snapshot ที่ดึงเมื่อ 16 สิงหาคม 2026; รายละเอียดฟีเจอร์และการติดตั้งเป็นคำอธิบายของโครงการ)