อันนี้แหละ 555

เหมือนกับการเอารถยนต์ไปเปรียบเทียบกับการวิ่งมาราธอนเลย..

55555 "ก็ขอให้มีฟีเจอร์นั้นซะ"

ฉันเห็นด้วยกับคุณอย่างยิ่ง!

555555

น่าจะเรียกว่า การพัฒนาโดยมีอาการหลอนเป็นตัวนำ...ได้ไหมนะ ;;

> ดูแล้วน่าจะเหมาะกับการเป็นลีดมาก แต่กลับปฏิเสธบทบาทเพิ่มเติมแบบนี้
> เมื่อผู้เขียนเสนอความท้าทายใหม่เพื่อการเติบโต ...

ในมุมของวิศวกร การเติบโตไม่ใช่การทำสิ่งที่ตัวเองถนัดให้ดียิ่งขึ้นหรอกหรือ?

ขอบคุณมากสำหรับคำพูดดี ๆ ครับ!!

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

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

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

ตอนนี้ผมก็กำลังทำ Computer-use Agent ชื่อว่า UseDesktop อยู่เหมือนกัน

https://youtu.be/aBkbsvMxP_A?si=uaugxKQEu4ZEz7jq

usedesktop.com

ดังนั้นผมจึงเห็นด้วยเป็นส่วนใหญ่ครับ

ในบทความนี้ไม่ได้ลงลึกเป็นเคล็ดลับเชิงปฏิบัติมากนัก แต่พูดถึงภาพรวมเป็นหลัก ถ้าจะเสริมทิปส์อีกสักหน่อยตอนพัฒนา agentic/agent ที่อิง LLM สุดท้ายแล้ว LLM ก็ยังอยู่บนพื้นฐานของทรานส์ฟอร์เมอร์ (กล่าวคือเป็นการอนุมานเชิงความน่าจะเป็น อาศัยโทเคน/สถานะปัจจุบันเพื่อสร้างโทเคนถัดไป ไม่ได้ “เข้าใจ” บริบท/ความหมายแล้วพูดคำถัดไปออกมา แต่เป็นการสร้างเอาต์พุตตามความน่าจะเป็น) ดังนั้นต่อให้เขียน sys prompt ดีแค่ไหน ก็ยังมีหลายครั้งที่มันไม่ตอบในแบบที่ต้องการ (เช่น สั่งให้ตอบเป็น JSON output แต่บางทีก็ลืม } เป็นต้น) เพราะฉะนั้นการเพิ่ม fallback fn หลายชั้นที่อิง regex จึงแทบจะเป็นสิ่งจำเป็นเสมอ

อีกอย่าง ถ้าเขียน sys prompt เพื่อให้ได้ structured output ปกติก็มักจะใช้ non reasoning model และยิ่ง context ยาวมากเท่าไร hallucination ก็ยิ่งเกิดบ่อยขึ้น ดังนั้นแทนที่จะยัดทุกอย่างไว้ใน prompt เดียว การทำ sys prompt หลายชุดแล้ว chain กันมักจะดีกว่า

ถ้าพัฒนาเป็นบริการจริง เนื่องจากอาจเกิดข้อผิดพลาดได้หลากหลาย การออกแบบสถาปัตยกรรมให้เป็นแบบแยกโมดูลและ fault tolerant คือหัวใจสำคัญ (เช่น ให้ supervisor agent เป็น async และ agent ที่เหลือเป็น sync) โดยเฉพาะกับระบบแบบ agentic หรือ agent ที่มักมี unexpected output เกิดขึ้นบ่อย
ดังนั้นตั้งแต่เริ่มเขียนโค้ดก็ควรรักษา SRP และเขียนในลักษณะ declarative ให้มากที่สุด ผมเลยอยากบอกว่าการเข้าหาแบบฟังก์ชันจะดีกว่า (= ไม่มี side effect และ flow ตรงไปตรงมาเข้าใจง่าย)

แล้วก็ขึ้นอยู่กับว่าจะใช้ LLM ผ่าน API หรือจะเสิร์ฟโมเดลเองโดยตรง แต่ถ้าจะเสิร์ฟ SLM หรือ LLM เอง ไม่ควรทำ model serving บนเซิร์ฟเวอร์เดียวกับที่โฮสต์แบ็กเอนด์ ควรแยก IO bound task กับ CPU bound tasks (กล่าวคือ งานที่ต้องใช้ GPU, matrix multiplication ฯลฯ) ไปไว้คนละเซิร์ฟเวอร์ จะ fault tolerant กว่าและดีกว่า (เช่น โฮสต์งาน CPU bound บน runpod)

จริง ๆ ยังมีทิปส์การพัฒนาอีกหลายอย่าง แต่กลัวว่าจะยาวเกินไป เลยขอเขียนไว้แค่นี้ก่อน

หวังว่าจะเป็นประโยชน์กับใครสักคนครับ

แล้วบริการแบบที่ติดตั้งบนเซิร์ฟเวอร์ระยะไกลแบบ private ล่ะ เป็นอย่างไรบ้าง?

ก่อนหน้านี้ก็ยัดระบบแปลอัตโนมัติห่วย ๆ ลงไปในคำแปลภาษาเกาหลีแบบน่ารังเกียจอยู่แล้ว ตอนนี้พัฒนาไปอีกขั้นสินะ ทั้งที่ยังกันการแปลอัตโนมัติไม่ได้ คราวนี้ก็ต้องมาลองชิม AI ห่วย ๆ ที่ยัดมาแบบน่ารังเกียจนั่นกันถ้วนหน้า!

จะว่าไป cgi ก็พอเข้าใจได้อยู่ แต่ปฏิกิริยาต่อ jsp นี่น่าประหลาดใจจริง ๆ 555
jsp กลายเป็นโบราณวัตถุถึงขนาดนั้นไปแล้วเหรอครับ

ฉันไม่ชอบฟีเจอร์ AI โดยเฉพาะบริการที่คอยทำงานอยู่เบื้องหลังแล้วบอกว่าจะมาช่วยเหลือเอาเสียเลย
ถ้าทำงานจากระยะไกลก็มีปัญหาเรื่องข้อมูลของฉันถูกส่งออกไป แต่ถ้าทำงานบนเครื่องก็มีปัญหาเรื่องการใช้ทรัพยากรของคอมพิวเตอร์ฉัน (CPU, หน่วยความจำ, แบตเตอรี่, ...)

น่าจะเป็นแหล่งอ้างอิงที่ดีนะครับ

เป็นนักพัฒนาชาวรัสเซีย เคยย้ายจาก Yandex ไป Riot และตอนนี้ก็ย้ายงานไป JPMorganChase แล้วนะ

5555555555 ตลกมากเลย

รู้สึกเหมือนแค่เปลี่ยนชื่อเท่านั้นนะ