ก็น่าประชดดีที่เว็บซึ่งบอกว่าไม่ต้อนรับ LLM กลับมีสรุปโดย LLM

ดูเหมือนว่าจำเป็นต้องมีตัวเลือกตั้งค่า MBTI สำหรับโมเดล AI

น่าสนใจมาก แต่พอคิดว่าสิ่งนี้ไม่ได้ถูกสร้างโดยภาครัฐหรือบริษัทอย่าง Google ก็แอบน่ากลัวเหมือนกัน
รู้สึกได้เลยว่าโลกนี้มีข้อมูลล้นหลาม

โค้ดถูกเปิดเผยไว้แล้ว ลองเข้าไปดูน่าจะช่วยได้ครับ!

"CTO ของ Amplitude อย่าง Wade Chambers ได้สาธิตเครื่องมือ AI ที่สร้างขึ้นภายในให้เพื่อนร่วมงานบางคนได้ลองดู"

ทั้งบทความของ Naver ที่คุณฮายงโฮกล่าวถึงในสไลด์นำเสนอ และเรื่อง AI Transformation ก็ดูเหมือนว่าถ้าระดับ C-level มีความตั้งใจหรือมีเป้าหมาย จึงจะสามารถขยายไปได้ดีทั่วทั้งองค์กร

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

มีลิงก์รูปภาพที่สรุปภาพรวมได้อย่างเข้าใจง่ายอยู่ในบรรทัดแรกของบทความ

ไม่ค่อยเห็นด้วยเท่าไรครับ ดูเหมือนว่าเป็นแค่ทริกที่ใช้ได้ผลเฉพาะในสถานการณ์ที่เจาะจงมาก ๆ เท่านั้น

โอ้ ผมก็เคยลองทำอะไรคล้าย ๆ กันเหมือนกัน!
เป็นบริการที่ใช้ AI แปลและสรุปโพสต์จาก Hacker News เป็นภาษาเกาหลี แล้วส่งไปยังช่อง Telegram ครับ
ถ้ารู้ว่ามีแบบนี้อยู่แล้วก็คงไม่ทำหรอกครับ.. 555 สมัครติดตามแล้วครับ!

https://t.me/hnaisummarykr

พอจะอธิบายได้ไหมว่านี่หมายถึงอะไร

อยากทราบว่าคุณตรวจสอบการทำงานแบบโลคัลอย่างไรบ้างครับ

ทั้งในคอมเมนต์บน Hacker News และในฟอรัม LocalLLaMA ของ Reddit ก็มีเสียงประเมินว่า GLM ค่อนข้างดีอยู่เหมือนกัน
GLM 4.5 AIR IS SO FKING GOODDD

• GLM 4.5 Air เร็วมากจริง ๆ และความสามารถด้าน tool calling ก็ยอดเยี่ยมด้วย (ไม่ได้ทดสอบแบบรันโลคัล แต่ทดสอบผ่าน Open Router)
• เมื่อเทียบกับ GPT-5 Mini ก็สูสีกันมากพอที่ความได้เปรียบจะขึ้นอยู่กับประเภทของงาน
• โมเดล GLM อื่น ๆ อย่าง GLM 4.5V ก็ล้วนดีทั้งหมด
• สำหรับงานบางประเภท (เช่น การเขียนนิยาย, การเขียนโค้ด) GLM เป็นธรรมชาติกว่าและมีข้อจำกัดน้อยกว่า GPT

อ๊ะ..

พอเอา AI มาใช้ก็บอกว่าประสิทธิภาพเพิ่มเป็นสองเท่า เลยให้งานเพิ่มเป็นสองเท่าด้วยนะ.. เงินเดือนก็เท่าเดิม แถมไม่ช่วยออกค่าใช้จ่าย AI ให้อีก..

ขอบคุณสำหรับคำแนะนำที่ดีมากครับ ตามที่คุณกล่าวมา ใช้ได้ไม่เหมาะสำหรับ use case ของ RDB และคาดว่าควรมองว่าเป็นตำแหน่งของ Search Engine (Elasticsearch) และ Vector DB (Pinecone) ครับ ภายในองค์กรเรายังใช้ Lucene ซึ่งผ่านการรับรองความน่าเชื่อถือมานานแล้วเพื่อรองรับฟีเจอร์ เช่น indexing, sorting และ aggregation เป็นต้น ขอบคุณครับ :)

ดังที่คุณกล่าวมา มันน่าจะเป็นโซลูชันที่สามารถใช้เป็น "serverless" แบบแท้จริงได้เฉพาะในบางสถานการณ์ มากกว่าจะเป็นฐานข้อมูลแบบใช้งานได้ทั่วไป

ไม่คิดว่าจะมีคนตอบเป็นภาษาเกาหลีนะ! (เขียนด้วยโทนค่อนข้างเสียดสีไปหน่อย...)

แรกๆ ผมคิดว่ามันเป็นไอเดียที่ค่อนข้างก้าวหน้ามาก แท้จริงปัญหาหลักของ DB แบบ serverless คือมีเซิร์ฟเวอร์จริงที่ยังทำงานอยู่ในส่วนที่ไม่ควรมีตัวตน เมื่อทราฟฟิกพุ่งสูงขึ้นจะเกิดสถานการณ์เซิร์ฟเวอร์ค้างอยู่จนกว่าจะมีการจัดสรรเซิร์ฟเวอร์ตัวนั้นได้ (โดยประมาณราว 5 นาที) จึงทำให้ DB serverless ของผู้ให้บริการคลาวด์ปัจจุบัน (เช่น AWS ฯลฯ) ใช้ในระดับ production ได้ยาก

ผมก็คิดว่าลองทำดูดีไหม? แต่เหตุผลที่กังวลคือ ถ้าทำแบบนั้นเราต้องนำตรรกะไบนารีสำหรับ indexing, sorting ฯลฯ ที่ถูกสร้างไว้ใน MySQL, PostgreSQL มาทำใหม่บน Lambda ซึ่งไม่รู้เลยว่าจะยากแค่ไหนในการทำโปรเจกต์ฐานข้อมูล open-source ที่เชื่อถือได้อีกครั้งบน Lambda

แต่เนื่องจากเป็นผลิตภัณฑ์ที่คุณพัฒนาขึ้นเอง จึงหวังว่าจะก้าวหน้าไปได้มากกว่านี้นะครับ~!

ขอบคุณมาก น่าจะช่วยได้มากแน่นอน ✌️

ตอนแรกผมตั้งค่าด้วย n8n แต่เปลี่ยนมาใช้ AWS Lambda + @ แล้วครับ 🙇‍♂️

• AWS Lambda: API สำหรับสมัคร/ยกเลิกการสมัครรับข้อมูล (อยู่ในโควต้าฟรี)
• DynamoDB: จัดการผู้สมัครรับข้อมูล (อยู่ในโควต้าฟรี)
• เซิร์ฟเวอร์แยกต่างหาก: ส่งอีเมล (ฟรี)
• AI: JinaAI, OpenAI API (มีค่าใช้จ่าย)

ตอนนี้ก็จัดการแบบนี้อยู่ครับ 555
แนะนำให้ลองทำดูสักครั้งนะครับ สนุกดี 👍

ขอบคุณสำหรับความคิดเห็นที่ดีมากครับ/ค่ะ

เรื่องที่คุณกล่าวถึงว่า "จำเป็นต้องมี state เพื่อให้ latency ลดลง" เป็นการชี้ให้เห็น trade-off ที่สำคัญของสถาปัตยกรรมของเราได้อย่างแม่นยำมาก

ก่อนอื่นขอพูดถึง latency ของคิวรีก่อนนะครับ จาก benchmark ของเรา ค่า p99 (99th percentile) อยู่ที่ประมาณ 130-210ms

ส่วนที่คุณกล่าวถึงความต่างถึง 100 เท่านั้นน่าจะเป็นการอ้างอิงถึงกรณีแย่ที่สุดที่มีการระบุในเนื้อหาว่า "ในกรณี cold start อาจใช้เวลาหลายวินาที" ดังนั้นจึงดูเหมือนว่าต่างกันมาก

อย่างที่คุณชี้ไว้ จุดนี้เป็นจุดอ่อนที่ชัดเจนของสถาปัตยกรรมเรา และดังที่ระบุในบทความ สภาพแวดล้อมการใช้งานจริงมีโอกาสเกิดขึ้นน้อยกว่า 0.01% (P99.99) เท่านั้น ส่วนใหญ่คิวรีที่เหลือจะถูกออกแบบให้ใช้หน่วยความจำและดิสก์ local ของแต่ละ Lambda เป็นแคช เพื่อให้ได้ประสิทธิภาพที่เสถียร

ดังนั้นอย่างที่คุณกล่าว ระบบระบบการเทรดทางการเงินที่ต้องการความหน่วงต่ำมากและต้องรับประกันว่าแต่ละคิวรีจะต่ำกว่า 10ms อาจไม่เหมาะกับสถาปัตยกรรมประเภทนี้ แต่ในแอปพลิเคชันค้นหาและแนะนำบนพื้นฐาน AI ส่วนใหญ่ เวลาแฝงที่ระดับ P99 อยู่ที่ 100-200ms ถือว่าเป็นสมรรถนะที่ดี และเราคิดว่าข้อได้เปรียบในการลดต้นทุนโครงสร้างพื้นฐานและภาระการดำเนินงานได้มากกว่า 90% นั้นมากกว่ามาก

ขอบคุณอีกครั้งสำหรับความคิดเห็นเชิงลึกอีกครั้ง