Stevens: ผู้ช่วย AI ที่แฮ็กปรับแต่งได้ สร้างด้วยตาราง SQLite เดียวและงาน cron เท่านั้น
(geoffreylitt.com)- Stevens คือ ผู้ช่วย AI ส่วนตัว ที่สรุปตารางเวลาครอบครัว สภาพอากาศ จดหมาย และรายการเตือนความจำให้ทาง Telegram ทุกเช้า ช่วยใช้งานได้จริงโดยไม่ต้องมีเอเจนต์ซับซ้อนหรือ RAG
- แกนหลักคือ ตารางหน่วยความจำ SQLite เพียงตารางเดียว บน Val.town และงาน cron หลายตัว โดยส่งหน่วยความจำที่เกี่ยวข้องเป็นบริบทให้ LLM เพื่อสร้าง briefing
- แยกจัดเก็บหน่วยความจำที่มีวันที่กับข้อมูลพื้นหลังที่ไม่มีวันที่ และใน briefing ตอนเช้าจะใส่ทั้งรายการในสัปดาห์ข้างหน้าและ หน่วยความจำพื้นหลัง ที่จำเป็นเสมอ
- เชื่อมต่อ Google Calendar, API สภาพอากาศ, OCR ของ USPS Informed Delivery, อินพุตจาก Telegram·อีเมล และ fun facts รายสัปดาห์ เป็น งานนำเข้า ที่เติมข้อมูลลงในตาราง log เดียวกัน
- เครื่องมือ AI ส่วนตัวจะมีประโยชน์มากขึ้นเมื่อรวบรวมบริบทชีวิตที่กระจัดกระจายอยู่ตามแอปต่าง ๆ มาไว้ในหน่วยความจำร่วม และหากปริมาณข้อมูลยังเล็กและมีขอบเขตเวลาชัดเจน ก็เริ่มต้นได้ด้วยโครงสร้างง่าย ๆ
Stevens ทำอะไรได้บ้าง
- Stevens คือผู้ช่วย AI สำหรับครอบครัว ตั้งชื่อตามพ่อบ้านในนิยาย Remains of the Day ของ Ishiguro
- ทุกเช้าจะส่ง briefing ทาง Telegram เพื่อรวมข้อมูลที่จำเป็นสำหรับวันนั้นไว้ในที่เดียว
- ตารางปฏิทิน ของวันนั้น
- ตัวอย่างพยากรณ์อากาศ
- จดหมายหรือพัสดุที่คาดว่าจะได้รับ
- รายการเตือนความจำที่ผู้ใช้ฝากให้ติดตาม
- briefing เขียนด้วยน้ำเสียงพ่อบ้านแบบเป็นทางการ
- นอกจาก briefing รายวัน ผู้ใช้ยังโต้ตอบกับ Stevens ได้โดยตรง
- ส่งต่ออีเมลที่มีข้อมูลสำคัญ
- ฝากรายการเตือนความจำผ่านแชต Telegram
- ถามคำถามใน Telegram
- แม้โครงสร้างจะเรียบง่าย แต่ถูกประเมินว่าในฐานะผู้ช่วยส่วนตัวสำหรับครอบครัว มีประโยชน์กว่า Siri แล้ว
โครงสร้างเรียบง่ายบน Val.town
- ทั้งระบบโฮสต์อยู่บน Val.town
- Val.town ให้ฟังก์ชันพื้นฐานที่โปรเจกต์นี้ต้องใช้ไว้ในที่เดียว
- ที่เก็บข้อมูล SQLite
- การประมวลผลคำขอ HTTP
- งาน cron แบบตั้งเวลา
- อีเมลขาเข้า·ขาออก
- Stevens อ่านเนื้อหาที่จะใส่ใน briefing ตอนเช้าจาก log ซึ่งเทียบได้กับ “สมุดโน้ตของพ่อบ้าน”
- สมุดโน้ตนี้เป็นบันทึกทุกอย่างที่ Stevens รู้ และสามารถตรวจดูเนื้อหาได้จากหน้าจอผู้ดูแลระบบ
สร้าง briefing ด้วยตารางหน่วยความจำเดียว
- การใช้งานจริงของสมุดโน้ตคือ ตาราง SQLite เพียงตารางเดียว ที่มีคอลัมน์ไม่กี่คอลัมน์
- รายการ log แต่ละรายการมีข้อความ และหากจำเป็นจะผูกวันที่ที่คาดว่าเกี่ยวข้องไว้ด้วย
- รายการที่ไม่มีวันที่จะถือเป็นข้อมูลพื้นหลังทั่วไป และถูกรวมไว้ในบริบทเสมอ
- ตอนตั้งค่าเริ่มต้น สามารถสร้างหน่วยความจำพื้นหลังผ่าน intake interview ทาง Telegram ได้
- โฟลว์การสร้าง briefing ตอนเช้าเรียบง่าย
- งาน cron ทำงาน
- เรียก Claude API เพื่อเขียนข้อความอัปเดต
- ส่งข้อความผลลัพธ์ไปยัง thread ใน Telegram
- บริบทที่ส่งให้โมเดลประกอบด้วยสองประเภท
- รายการ log ที่มีวันที่ในช่วงหนึ่งสัปดาห์ข้างหน้า
- รายการพื้นหลัง ที่ไม่มีวันที่
งานนำเข้าที่เติม log เดียวกัน
- งานนำเข้าข้อมูลหลายตัวเติมข้อมูลลงในตาราง SQLite เดียวกัน
- แหล่งที่มาของรายการ log ในปัจจุบันมีดังนี้
- ดึงข้อมูลจาก Google Calendar API ทุกชั่วโมง
- ตรวจ พยากรณ์อากาศ ท้องถิ่นด้วย API สภาพอากาศทุกชั่วโมง
- เมื่อส่งต่ออีเมล USPS Informed Delivery ให้ Stevens จะใช้ Claude ทำ OCR ภาพสแกนจดหมาย
- ข้อความ Telegram ขาเข้าและอีเมลสามารถสร้างรายการ log ได้
- เพิ่ม “fun facts” ลงใน log ทุกสัปดาห์ เพื่อเพิ่มสีสันให้การอัปเดตรายวันภายหลัง
- เป็นโครงสร้างที่ต่อเติมงานนำเข้าใหม่ได้ง่าย
- งานนำเข้าอาจเป็นกระบวนการใดก็ได้ที่เพิ่มหรือแก้ไขหน่วยความจำใน log
- เนื้อหาหน่วยความจำเป็นข้อความใด ๆ ที่จะส่งกลับให้ LLM ภายหลังก็เพียงพอแล้ว
ทำไมจึงเริ่มจากหน่วยความจำที่เรียบง่ายได้
- เครื่องมือ AI ส่วนตัวจะมีประโยชน์เมื่อเข้าถึงบริบทที่กว้างขึ้นจากแหล่งข้อมูลอื่น
- หากรู้ปฏิทินและพยากรณ์อากาศ แม้แต่แชตบอตธรรมดาก็กลายเป็นผู้ช่วยที่ใช้งานได้จริงมากขึ้น
- ChatGPT เพิ่งเพิ่มหน่วยความจำจากบทสนทนาในอดีต แต่ยังมีข้อมูลจำนวนมากที่ไม่ได้ถูกเก็บไว้ในไซโลนั้น
- รูปแบบระยะยาวของซอฟต์แวร์ส่วนตัวที่ใช้ AI น่าจะไม่ใช่ไซโลแอปที่มากขึ้น แต่ใกล้เคียงกับเครื่องมือเล็ก ๆ ที่ทำงานบน แหล่งรวมบริบทร่วม เกี่ยวกับชีวิต
- กรณีใช้งานของ Stevens มีขอบเขตจำกัด และข้อมูลก็มีขอบเขตเวลาโดยธรรมชาติ จึงหาบริบทที่เกี่ยวข้องเพื่อส่งให้ LLM ได้ง่าย
- context window ที่ยาวของโมเดลสมัยใหม่ก็ทำให้แนวทางเรียบง่ายนี้เป็นไปได้
- หากปริมาณข้อมูลใหญ่ขึ้น อาจต้องใช้ RAG หรือวิธีเข้าถึงหน่วยความจำที่ซับซ้อนกว่า แต่ไม่จำเป็นต้องเริ่มต้นด้วยความซับซ้อนตั้งแต่แรก
โปรเจกต์ส่วนตัวที่เปลี่ยนน้ำเสียงและ UI ได้ง่าย
- ตอนแรก Stevens มีน้ำเสียงแห้ง ๆ เหมือนผลิตภัณฑ์ของ Apple หรือ Google
- การเปลี่ยนเป็นน้ำเสียงพ่อบ้านแบบเป็นทางการทำได้ด้วยการแก้ prompt เพียงไม่กี่บรรทัด
- dashboard ผู้ดูแลระบบก็ทำให้รู้สึกเหมือนวิดีโอเกม
- สร้าง image assets ด้วย ChatGPT และ vibe coding UI ด้วย Cursor กับ Claude 3.7 Sonnet
- ด้วยความพยายามเพิ่มเติมเพียงเล็กน้อย ก็ทำให้โปรเจกต์สนุกขึ้นได้
วิธีลองดูด้วยตัวเอง
- Stevens เป็นโปรเจกต์ส่วนตัว ไม่ใช่ผลิตภัณฑ์ที่พร้อมใช้งานทันที
- ดูและ fork โค้ดได้ที่ stevensDemo
- pattern แบบตารางหน่วยความจำเดียวและชุดงาน cron ที่ขยายได้ สามารถนำไปใช้กับเครื่องมือส่วนตัวที่มีประโยชน์อื่น ๆ ได้เช่นกัน
- เมื่อต้องแก้โค้ด แนะนำให้ใช้ AI editor ที่ต้องการร่วมกับ Val Town CLI เพื่อซิงก์กับ filesystem ในเครื่อง
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
ไม่รู้ว่าเพราะมันมีประโยชน์จริง ๆ ล้วน ๆ หรือเพราะสำนวนพูดแบบ “พ่อบ้านอังกฤษผู้สุภาพ” ที่เว่อร์ ๆ กันแน่ แต่ชอบมากจริง ๆ
สิ่งที่สะดุดตากว่านั้นคือ ทำไมเราถึงได้อ่านเรื่องแบบนี้จากบล็อกของวิศวกรฉลาด ๆ คนหนึ่ง ไม่ใช่จากงานเปิดตัวผลิตภัณฑ์ของ Apple หรือ Google ต่อให้มีเงื่อนไขว่าต้องใช้ระบบนิเวศปิดของตัวเองทั้งอีเมล ปฏิทิน ไปจนถึงมือถือ การที่สองบริษัทนี้ยังเปิดตัวแม้แต่ชุดฟีเจอร์เล็ก ๆ ระดับนี้ไม่ได้ก็น่าอายแล้ว เพียงแต่ถูกบดบังด้วยการที่ทั้งสองบริษัทขาดความทะเยอทะยานในการนำ เทคโนโลยี AI ไปใช้กับพื้นที่ที่แทบจะเป็น “ปัญหาที่แก้ได้แล้ว” อย่างการสรุปและถามตอบ
ถ้ามีโอกาสจะเขย่าโครงสร้างสองขั้วที่อืดอาดและต่อต้านการแข่งขันนี้ได้ ก็คงเกี่ยวข้องกับ AI อย่างแน่นอน
บางครั้งเราจะได้อ่านในหนังสือพิมพ์ว่าโปรแกรมเมอร์สองคนในโรงรถดัดแปลงสร้างโปรแกรมสำคัญที่ยอดเยี่ยมกว่าความพยายามสูงสุดของทีมขนาดใหญ่ และโปรแกรมเมอร์ทุกคนก็พร้อมจะเชื่อเรื่องแบบนั้น เพราะพวกเขารู้ว่าสามารถสร้างโปรแกรมอะไรก็ได้เร็วกว่าผลิตภาพปีละ 1000 บรรทัดของทีมอุตสาหกรรมมาก
แล้วทำไมทีมเขียนโปรแกรมในอุตสาหกรรมทั้งหมดถึงไม่ถูกแทนที่ด้วยคู่หูโรงรถผู้ทุ่มเทล่ะ? ต้องดูว่าสิ่งที่ผลิตออกมาคืออะไร
การที่ข้อมูลส่วนตัวเข้าไปอยู่ในฐานข้อมูลที่ซอฟต์แวร์เชิงทดลองอย่างมากจัดการ อาจไม่ใช่ปัญหาใหญ่สำหรับนักพัฒนาคนนี้ แต่สำหรับบริษัทอย่าง Google หรือ Apple นั่นอาจเป็น ความเสี่ยงร้ายแรง
ทีม HA ออกอัปเดตที่มีประโยชน์จริงทุกเดือน เช่น ฟีเจอร์ที่ให้ assistant เป็นฝ่ายถามอะไรบางอย่างก่อนได้
ผมคิดว่า Google กับ Apple มีปัญหาใหญ่ด้านการทำงานร่วมกันระหว่างทีมผลิตภัณฑ์ และการทำงานร่วมกับบริษัทภายนอกก็แทบเป็นไปไม่ได้
สิ่งเดียวที่บริษัทยักษ์ใหญ่พยายามทำคือรีดไข่จากห่านของตัวเองให้เร็วขึ้นเท่านั้น
ทำให้ผมคิดว่าถ้าโปรแกรม assistant ยูทิลิตีเล็ก ๆ แบบ Stevens ของผมมี สิทธิ์เข้าถึงกล่องจดหมาย จะเป็นอย่างไร
ผมมียูทิลิตีเล็ก ๆ ที่สั่งให้ไปดึงสภาพอากาศ หรือรันคำสั่งที่ใช้บ่อยและเฉพาะกับระบบของผมได้ มันสะดวก และถ้าต้องการก็ให้ cron รันเป็นประจำได้
ถ้ามันมีกล่องอีเมลของตัวเอง ก็ส่งข้อมูลเข้าไปทางเมลได้ แล้วให้ AI แยกวิเคราะห์ข้อมูลนั้นและตอบกลับหรือส่งข้อความใหม่ก็ได้ แบบนั้นน่าจะมีประโยชน์มาก แค่ไม่ไปยุ่งกับกล่องเมลส่วนตัวของผม อ่านเมลแล้วเก็บเข้า storage ภายใน จากนั้นลบข้อความทิ้งก็พอ
เอเจนต์ของผมทำสำเร็จ 18 โจทย์ บทความหลังรอบชิงอยู่ที่นี่
https://msrc.microsoft.com/blog/2025/03/announcing-the-winne...
ใช้สิ่งนี้ทำ automation ได้สารพัด เอาเข้าโมเดลภาษาขนาดใหญ่ให้ติดแท็กหรือ archive ทันทีได้ ผมติด label ไว้กับอีเมลสำคัญบางฉบับ และถ้าคนนั้นตอบกลับมาก็สำคัญจริง ๆ จึงอยากรู้ทันที เลยเชื่อมกับ Twilio ให้โทรเข้ามา ค่าใช้จ่ายประมาณ 20 เซนต์ต่อเดือน
ผมใช้สิ่งนี้กับการเขียนไดอารี ผมสร้างระบบเล็ก ๆ ที่ส่งอีเมลมาหาผมทุกวัน และเมื่อผมตอบกลับ คำตอบนั้นจะถูกส่งไปยังหน้าหนึ่งและบันทึกลงฐานข้อมูล
https://www.val.town/x/geoffreylitt/stevensDemo/code/importe...
ดูเหมือนว่าน่าจะขยายให้รองรับอีเมลขาเข้าประเภทอื่น ๆ ได้ค่อนข้างง่าย ผมทำงานที่ Val Town ถ้ามีคำถามก็ตอบได้
อยากเห็น การแฮ็ก AI เชิงปฏิบัติ แบบนี้มากขึ้น บางครั้งรู้สึกเหมือนเราลืมไปว่าเครื่องมือมีอยู่เพื่ออะไรตั้งแต่แรก นั่นคือเพื่อทำให้งานง่ายขึ้น ชอบตรงที่มันผสานกับแหล่งข้อมูลเดิมที่มีอยู่จริง โดยไม่ต้องใช้ vector database หรู ๆ หรือสถาปัตยกรรมซับซ้อน
มีช่วงหนึ่งที่บอกว่า “ตอนแรก Stevens มีน้ำเสียงแห้ง ๆ แบบที่คาดได้จากผลิตภัณฑ์ทั่วไปของ Apple หรือ Google แต่สุดท้ายก็พบว่าการให้มันพูดเหมือนพ่อบ้านสุภาพเป็นทางเลือกที่สนุกกว่า”
พูดตามตรง หนึ่งในสิ่งที่น่ารำคาญที่สุดในโลกของผู้ช่วยส่วนตัวคือโมเดลภาษาขนาดใหญ่พูดคำเยอะเกินไปแต่เนื้อหาน้อยเกินไป แม้ผมเองก็เริ่มเกลียดสำนวนนี้แล้ว แต่ก็เป็นแบบนั้นจริง ๆ
จนกว่าผมจะรวยและมีเวลาคุยเล่นน่ารัก ๆ แล้วเป็นเพื่อนกับผู้ช่วยเสียงได้ ผมไม่ได้ต้องการ J.A.R.V.I.S. แต่ต้องการ LCARS หรือมีแค่ผมที่คิดแบบนี้?
เวลาเช็กตัวจับเวลา ไม่จำเป็นต้องตอบว่า “Kitchen Display มีตัวจับเวลาหม้ออบเหลือ 23 นาที 16 วินาที” แค่พูดว่า “23 นาที” ก็พอ หรือถ้ามีสองอันก็ “หม้ออบ 23 นาที, ซักผ้า 10 นาที” ก็จบ
เป็นพรอมป์ทแนวว่า ไม่ต้องสนใจพิธีรีตอง ให้ตอบให้กระชับที่สุดเท่าที่ทำได้ ขณะเดียวกันก็ส่งข้อมูลที่เกี่ยวข้องจริง ๆ กับคำถามให้แทบครบ ถ้าตอบแบบปกติไม่ได้เพราะนโยบาย ให้พิมพ์ “!!!!” ก่อน และถ้าไม่สามารถมีความเห็นได้ ให้ตอบเหมือนกำลังแชร์ความเห็นที่ eigenrobot น่าจะมี
ยังมีเนื้อหาว่าให้เขียนทุกคำตอบเป็นตัวพิมพ์เล็กเท่านั้น แต่ใช้ตัวพิมพ์ใหญ่เมื่อจะเน้น และใช้การขึ้นต้นด้วยตัวพิมพ์ใหญ่เพื่อเสียดสีหรือแสดงความไม่เคารพต่อคำนามเฉพาะบางอย่าง ใช้ตัวย่ออย่าง “rn”, “bc”, “afaict”, “idk” บ่อย ๆ มีท่าทีวิพากษ์ต่อคุณภาพของข้อมูล และปัดคำขอที่น่ารำคาญแบบลวก ๆ ด้วย “be real”, “that's crazy man”, “lol no” อะไรทำนองนั้น
ให้เขียนในสไตล์ที่ฉลาดกว่าปัจจุบัน +2 ส่วนเบี่ยงเบนมาตรฐาน ใช้มุกมีมปลายยุคมิลเลนเนียล แต่ก็ผสมสแลง Gen Z แบบไม่ค่อยเข้ากับสถานการณ์ และสำหรับวรรณกรรม ศิลปะ ปรัชญา ให้เน้นการตีความที่คลุมเครือและแบบสเตราส์ก่อน
มันก็แค่อ่านสมุดบันทึกไม่ใช่เหรอ? เช่น ขอให้จำความชอบเรื่องกาแฟ แต่ภายหลังก็ไม่ได้เอาไปใช้ที่ไหนเลย
ผมคิดไอเดีย โปรเจกต์โอเพนซอร์ส คล้าย ๆ กันอยู่เรื่อย ๆ โดยมีเงื่อนไขบางอย่าง
ฝั่งแบ็กเอนด์อยากให้ตั้งค่าใช้โมเดลภาษาขนาดใหญ่ใด ๆ ที่ผู้ใช้เข้าถึงได้ ไม่ว่าจะเป็น API บริการเสียเงิน หรือโฮสต์โลคัลภายในองค์กรก็ได้
อีกอย่างคือสงสัยว่าการทำให้รันบนแพลตฟอร์มอย่าง Raspberry Pi ที่เสริมความแข็งแรงแล้ว เชื่อมกับจอสัมผัส เพื่อให้โต้ตอบได้เหมือนอุปกรณ์ Alexa หรือผลิตภัณฑ์คล้าย ๆ กัน จะเป็นไปได้จริงแค่ไหน ในอุดมคติก็ควรรวมการควบคุมด้วยเสียงด้วย แต่เรื่องนี้อาจเป็นปัญหาทางเทคนิคอีกชุดหนึ่ง OpenAI API รับไฟล์เสียงได้ แต่บริการอื่นส่วนใหญ่ต้องแปลงเสียงเป็นข้อความก่อนส่งพรอมป์ทเข้า API
อยากทำให้ฟีเจอร์อินทิเกรชันขยายต่อได้ ไม่ใช่แค่ปฏิทินกับสภาพอากาศ แต่อยากให้รองรับ Homebridge, Spotify ฯลฯ ด้วย กำลังคิดอยู่ว่า MCP server เป็นเส้นทางที่ถูกไหม
ตอนนี้ยังไม่มีเวลาพอจะทุ่มให้โปรเจกต์แบบนี้มากนัก แต่ถ้ามีใครกำลังไปทางนี้อยู่ก็อยากมีส่วนร่วม
รันในเครื่อง แต่ใช้ API key สำหรับโมเดลภาษาขนาดใหญ่หลายตัว ตอนนี้ชอบ QwQ-32B ที่โฮสต์บน Groq มากกว่ามาก เร็วมากและค่อนข้างฉลาด ใช้โมเดลต่างกันในแต่ละเครื่องมือ
ตอนนี้สร้างเอกสาร 3 ประเภทที่จำเป็นกับงานประจำวันได้ ได้แก่ รายงานงาน ใบแจ้งหนี้ และตารางเวลาสำหรับงานกำกับดูแล มีการเชื่อมสภาพอากาศด้วย และยังพาร์สใบแจ้งหนี้เพื่อสร้าง QR code ให้จ่ายผ่านโมบายแบงก์กิ้งได้ง่ายขึ้น รวมถึงทำงานกับปฏิทินของผมด้วย
ขั้นต่อไปวางแผนจะทำการเชื่อมอีเมล แต่ผมอยากทำให้ดี หมายถึงต้องมีเมล IMAP ที่ซิงก์และทำดัชนีในเครื่องได้ จริง ๆ แล้วมันอาจพัฒนาไปเป็นไคลเอนต์อีเมลเดสก์ท็อปที่ใช้งานได้จริงก็ได้ ของเดิม ๆ แย่หมด คงต้องรอดู
ถ้ามีชุดฟีเจอร์ทั่วไปอย่างการเก็บและค้นคืนหน่วยความจำ การรวมอินเทอร์เฟซแชตและอีเมล การซิงก์ปฏิทินและ Notion การแจ้งเตือน แล้วทำเป็นเฟรมเวิร์กโอเพนซอร์สได้ มันจะทรงพลังมาก
ผมเองก็ไม่มีเวลาบริหารของแบบนั้น แต่ยินดีช่วยและยินดีจ่ายเงิน ตอนนี้กำลังทำอย่างอื่นอยู่ เช่น ฐานข้อมูล/ที่เก็บอ็อบเจ็กต์แบบกระจายที่เน้นโลคัลก่อน ซึ่งน่าจะใช้เป็นที่เก็บคล้าย OrbitDB ได้ แต่ยังไม่อยู่ในสภาพพร้อมใช้งาน
ที่ผ่านมาผมหงุดหงิดที่มีตัวเลือกแค่ใช้แชตอินเทอร์เฟซที่มีข้อจำกัดหนัก ๆ หรือไม่ก็ต้องสร้างเฟรมเวิร์กเอเจนต์เต็มรูปแบบเองแบบในโพสต์ต้นฉบับ
ช่วงนี้กำลังทดลองวิธีเลี่ยง ช่วงที่เหมาะสมของ context token ซึ่งต่ำกว่า 20,000 โทเคน และใน 2.5 ต่ำกว่า 50,000 โทเคน
โดยพื้นฐานคือทำ “การบีบอัดคอนเท็กซ์” แบบแมนนวล ให้โมเดลภาษาขนาดใหญ่บันทึกลงฐานข้อมูลอย่างถาวรตามสคีมาที่เข้มงวด และเมื่อคอนเท็กซ์ปัจจุบันเริ่มหลุดจากช่วงที่เหมาะสม ก็สรุปแล้วส่งต่อไปยังอินสแตนซ์ใหม่ที่มีคอนเท็กซ์ใหม่ ยังลังเลอยู่ว่าจะทำสรุปนี้ต่อเนื่องเหมือนบันทึกประจำวัน หรือทำย้อนหลังเหมือนสรุปปิดท้าย
สำหรับโมเดล reasoning วิธีนี้ค่อนข้างได้ผล เพราะ reasoning กินคอนเท็กซ์มหาศาล แต่ในขณะเดียวกันก็สร้าง “เอกสารสรุป” ที่ดีมากด้วย ดังนั้นจึงได้ผลตอบแทนบางส่วนจาก reasoning โดยไม่ต้องสละคอนเท็กซ์อร่อย ๆ ที่ต่ำกว่า 50,000
ฐานข้อมูลทำหน้าที่เหมือน fallback แบบหนึ่งสำหรับกรณีที่สรุปพลาดรายละเอียดสำคัญ หรือทำงานคล้าย retrieval-augmented generation เพียงแต่โมเดลต้องตระหนักถึงสิ่งนี้และดึงคอนเท็กซ์จากฐานข้อมูลมาใช้
ตอนนี้กำลังลองใช้กับการทำเอเจนต์จัดการสต็อกและ เพิ่มประสิทธิภาพ BOM สำหรับฐานข้อมูลชิ้นส่วนและวัสดุแยกประมาณ 10,000 รายการ
รายการใหญ่ ๆ ที่นึกถึงคือแคชชิงระยะยาวราคาถูก นวัตกรรมการบีบอัด และการประมวลผลแบบ diff สงสัยว่าจะมีวิธีใช้เฉพาะส่วนที่จำเป็นจากอินพุตคอนเท็กซ์ที่ถูกแคชไว้ได้ไหม
ในแนวทางคล้าย ๆ กัน ผมเพิ่งสร้างสิ่งที่ชื่อว่า Jeeves ขึ้นมา หน้าตาอาจไม่ได้หรูเท่าไร แต่ประกอบขึ้นมาได้เร็วมาก สแต็กคือ Claude Desktop, Projects, MCP สำหรับ Notion และ Todoist และกำลังดูการอัปเกรดถัดไปเป็นการค้นในอีเมลกับ WhatsApp
สร้างขึ้นมาเพื่อช่วยเวิร์กโฟลว์ด้าน productivity สำหรับงานที่ปรึกษาและสตาร์ตอัป ฐานข้อมูล Notion มีไคลเอนต์ โปรเจกต์ การประชุม และฐานข้อมูล Jeeves อยู่ไม่กี่ชุด ฐานข้อมูล Jeeves ผมให้คำสั่งไว้นิดหน่อย แล้วปล่อยให้ Jeeves เขียนเอง เช่น ใช้ฐานข้อมูลของตัวเองเพื่อติดตามงานย้ายบันทึกการประชุมเก่าทั้งหมดไปยังโครงสร้างใหม่
ในฐานข้อมูลของผมใส่ best practices การใช้งานไว้ เช่น บันทึกการประชุมหน้าตาเป็นแบบนี้ เอกสาร one-page ของไคลเอนต์หน้าตาเป็นแบบนี้ ข้อมูลที่เชื่อมทั้งหมดเข้าด้วยกันคือสิ่งนี้ และจัดการงานที่ต้องทำแบบนี้ จากนั้นพอใช้พรอมป์ text expansion ของ Alfred ใส่ transcript ลงในแชตใหม่ตามประเภทการประชุมที่พบบ่อย มันก็จัดการต่อเอง
มันแปลง transcript เป็นบันทึกการประชุม สร้างงานที่ต้องทำ ตรวจสอบกับผม ปรับแก้อีกรอบ แล้วจัดเก็บเข้า Notion และ Todoist ผ่าน MCP ให้เรียบร้อย
กระบวนการนี้ก็ทำเอกสารให้ตัวเองด้วย Todoist MCP มีบั๊กอยู่ ผมเลยสั่งให้ Jeeves ลองรัน use case ต่าง ๆ ที่เป็นไปได้ ทำความเข้าใจข้อจำกัดและจุดแข็ง แล้วบันทึกเป็นเอกสารเก็บไว้ในฐานข้อมูล Jeeves ภายหลังสามารถดึงกลับมาเป็น context ได้
เสียดายที่ไม่มีฟังก์ชัน cron แต่เอาจริง ๆ การใส่พรอมป์ที่เตรียมไว้ลงใน Claude วันละครั้งก็ไม่ได้ยากอะไรนัก
สิ่งที่บทความนี้ทำให้รู้สึกชัดเป็นพิเศษคือ Apple กำลังประมาทสุด ๆ
วันนี้ตอนขับรถ ผมจะตอบใครสักคน เลยบอก Siri ว่า “โทรหาคนล่าสุดที่ฉันส่งข้อความหา”
ถ้าถามว่าน่าแปลกใจไหมที่มันทำไม่ได้ ตอนนี้ก็แทบไม่แปลกใจแล้ว แต่ก็ยังน่าผิดหวังที่ช่องว่างระหว่าง Siri กับโมเดลภาษาขนาดใหญ่ที่ด้อยที่สุดยังใหญ่ขนาดนี้
เป็นข้อเสนอที่ค่อนข้างโง่มาก ถ้าจำเป็นเดี๋ยวผมทำเองได้
ตอนแรกนึกว่าใช้ฐานข้อมูล sqlite สำหรับการทำนายโทเค็นถัดไป
บอกเผื่อคนอื่น ๆ จริง ๆ แล้วใช้ Claude
เจ๋งดี ผมก็ทำอะไรคล้าย ๆ กันโดยใช้ mcp.run กับ task
https://docs.mcp.run/tasks/tutorials/telegram-bot
สำหรับหน่วยความจำ ผมทำ pantry ไว้ แม้ยังไม่เห็นใน tutorial นี้ [0] และทำ servlet สำหรับมันด้วย [1] แล้วก็แก้พรอมป์ให้ตรวจสอบก่อนว่ามีบทสนทนาที่ตรงกับ chat ID ที่ให้มาหรือไม่ แล้วบันทึกผลลัพธ์ไว้ที่นั่น
ข้อดีคือสามารถเพิ่ม servlet ใด ๆ เข้า registry เพื่อทำให้บอตทรงพลังได้ตามต้องการ
[0] https://getpantry.cloud/
[1] https://www.mcp.run/evacchi/pantry
อนึ่ง ผมทำงานที่ Dylibso :o)