TypeChat: แพลตฟอร์ม AI แบบแชต

 (microsoft.github.io)
3 คะแนน โดย GN⁺ 2023-07-21 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • ความยากที่สุดเมื่อเพิ่มการป้อนข้อมูลด้วยภาษาธรรมชาติเข้าไปในแอปเดิม คือการแปลง เจตนาของผู้ใช้ ให้เป็นโครงสร้างที่ซอฟต์แวร์เชื่อถือได้ และ TypeChat คือไลบรารีที่พยายามแก้ปัญหาจุดนี้ด้วยชนิดข้อมูลของ TypeScript
  • เนื่องจากคำตอบข้อความอิสระของ LLM แยกวิเคราะห์ได้ไม่เสถียร TypeChat จึงชี้นำให้คำตอบออกมาเป็น JSON และเพิ่มการตรวจสอบสคีมา เพื่อให้กลายเป็นข้อมูลที่แอปสามารถประมวลผลได้
  • ชนิดข้อมูลของ TypeScript สามารถแสดงโครงสร้าง JSON ได้อย่างละเอียด และยังเป็นรูปแบบที่ LLM พบเจอบ่อยในกระบวนการฝึก จึงเหมาะสำหรับใช้เป็น สคีมาคำตอบ
  • หากคำตอบไม่ตรงกับชนิดข้อมูล ก็สามารถส่งข้อผิดพลาดจากคอมไพเลอร์ TypeScript กลับไปเป็นฟีดแบ็กเพื่อแก้ไขได้ ทำให้เพิ่ม ความปลอดภัยของชนิดข้อมูล ได้ก่อนขั้นตอนหลังการประมวลผลหรือการยืนยันจากผู้ใช้
  • TypeChat ติดตั้งได้ด้วย npm install typechat และเผยแพร่เป็นโอเพนซอร์สภายใต้สัญญาอนุญาต MIT พร้อมมีการรวมเข้ากับ OpenAI API และ Azure OpenAI service

แปลงคำขอภาษาธรรมชาติให้เป็นข้อมูลที่แอปประมวลผลได้

  • โมเดลภาษาขนาดใหญ่รุ่นใหม่สามารถนำไปต่อเข้ากับแชตแอสซิสแทนต์ได้ง่าย แต่การผสานภาษาธรรมชาติเข้ากับอินเทอร์เฟซของแอปเดิมอย่างเสถียรยังเป็นโจทย์อีกแบบหนึ่ง
  • TypeChat มุ่งเน้นที่การแปลงคำขอของผู้ใช้ให้อยู่ในรูปแบบที่แอปจัดการได้ และทำให้ทั้งนักพัฒนาและผู้ใช้สามารถเชื่อถือผลลัพธ์ที่ระบบทำงานออกมา
  • ไลบรารีที่เปิดเผยสู่สาธารณะนี้ใช้ นิยามชนิดข้อมูล ในโค้ดเบสเพื่อให้ได้คำตอบ AI แบบมีโครงสร้าง และตั้งเป้าไปที่ความปลอดภัยของชนิดข้อมูล
  • สามารถติดตั้งได้ด้วยคำสั่งต่อไปนี้
npm install typechat

ใช้ JSON และชนิดข้อมูลแทนการพาร์สภาษาธรรมชาติ

  • โดยพื้นฐานแล้ว LLM ถูกปรับมาเพื่อการสนทนาแบบ ภาษาธรรมชาติ เช่นภาษาอังกฤษ ดังนั้นแม้จะใส่กฎอย่าง “ตอบเป็นรายการ bullet” ไว้ในพรอมป์ต์ ซอฟต์แวร์ทั่วไปก็ยังพาร์สได้อย่างเสถียรได้ยาก
  • หากขอให้ตอบเป็น JSON โดยมากจะได้คำตอบในรูปแบบที่แอปรับมือได้ง่ายกว่า
    • ในตัวอย่าง คำขอ “blueberry muffin” 1 ชิ้นและ “grande latte” 1 แก้ว ถูกแปลงเป็น JSON ที่มีอาร์เรย์ items
  • แม้ตัวอย่างแบบง่ายจะช่วยชี้นำโครงสร้างได้ แต่ก็ยังนิยามได้ไม่เพียงพอว่า AI ควรคืนค่าอะไร และไม่ได้ให้เกณฑ์สำหรับการตรวจสอบความถูกต้อง

ใช้ชนิดข้อมูล TypeScript เป็นสคีมาคำตอบ

  • TypeChat ใส่ ชนิดข้อมูล TypeScript ลงในพรอมป์ต์เพื่อบอกโครงสร้าง JSON ที่ LLM ควรส่งกลับ
  • ในสคีมาตัวอย่าง ชนิด Response มี items: Item[] และ Item มีฟิลด์ name, quantity, รวมถึง size และ notes ที่เป็นตัวเลือก
  • TypeScript เหมาะกับการอธิบาย JSON อย่างละเอียด และเพราะ LLM เคยพบเจอนิยามชนิดข้อมูลจำนวนมาก จึงมีประโยชน์ในการชี้นำรูปแบบคำตอบ
  • หากคำตอบไม่ตรงกับชนิดข้อมูล คอมไพเลอร์ TypeScript จะตรวจสอบโดยอิงจากนิยามชนิดข้อมูลที่เป็นโค้ด TypeScript ที่ถูกต้อง
  • ฟีดแบ็กจากข้อผิดพลาดของคอมไพเลอร์สามารถนำมาใช้เพื่อชี้นำให้แก้คำตอบ ทำให้กระบวนการได้คำตอบที่ตรงชนิดข้อมูลมีความแข็งแรงมากขึ้น

วิธีใช้งาน TypeChat และตัวอย่าง

  • TypeChat สามารถใช้กับแนวทางแบบ สคีมาข้อมูล เพื่อแปลงเจตนาของผู้ใช้ให้เป็นคำตอบแบบมีโครงสร้าง
  • โค้ดตัวอย่างนิยามอินเทอร์เฟซ SentimentResponse เพื่อจำแนกอารมณ์ของข้อความที่ผู้ใช้ป้อนว่าเป็น negative, neutral หรือ positive
  • สร้าง language model จากตัวแปรสภาพแวดล้อมด้วย createLanguageModel(process.env) จากนั้นอ่านไฟล์สคีมาแล้วสร้างตัวแปลด้วย createJsonTranslator<SentimentResponse>
  • หาก translator.translate(request) สำเร็จ ก็จะแสดง response.data.sentiment และหากล้มเหลวก็จะแสดงข้อความข้อผิดพลาด
  • นอกจากสคีมาข้อมูลแล้ว ยังสามารถใช้ สคีมา API เพื่อประกอบเป็นโปรแกรมพื้นฐานได้
  • ดูวิธีใช้งานได้ที่ docs และ examples

โอเพนซอร์สและความเป็นกลางต่อโมเดล

  • TypeChat เป็นโอเพนซอร์สภายใต้ สัญญาอนุญาต MIT และเผยแพร่อยู่บน GitHub
  • เพื่อความสะดวก มีการรวมพื้นฐานสำหรับ OpenAI API และ Azure OpenAI service มาให้
  • เป้าหมายของการออกแบบคือ ความเป็นกลางต่อโมเดล และมุ่งไปที่แนวทางที่ใช้ได้กับ API แบบ chat completion
  • ปัจจุบัน TypeChat ทำงานได้ดีที่สุดกับโมเดลที่ผ่านการฝึกทั้งกับร้อยแก้วและโค้ด
  • แพ็กเกจอยู่บน npm และสามารถลองใช้งานได้ทันที

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
sungwoo 2023-07-26

ฮ่า ๆ เห็นข่าวแล้วกะจะมาโพสต์เหมือนกัน แต่สู้ AI ไม่ได้จริง ๆ แฮะ
 
GN⁺ 2023-07-21
ความเห็นบน Hacker News

  • ยังไม่ค่อยเห็นว่า มูลค่าเพิ่ม อยู่ตรงไหน
    ข้อความหลักที่ส่งไปยัง LLM อยู่ตรงนี้: https://github.com/microsoft/TypeChat/blob/main/src/typechat...
    สุดท้ายก็ดูเหมือนเป็นการใช้พรอมป์ตแบบตายตัวเพื่อให้คืนข้อมูลที่มีโครงสร้าง พร้อมเพิ่มระบบอัตโนมัติเล็กน้อยและการผูกติดกับผู้ให้บริการเข้าไปได้นิดหน่อย ไลบรารี LLM พวกนี้ส่วนใหญ่ก็แทบไม่ต่างจาก API ที่ครอบ API ชั้นล่างอีกทีแบบหยาบ ๆ และสคริปต์ที่ทำงานแบบเดียวกันก็เขียนเองได้ง่าย แถมยืดหยุ่นกว่าเมื่อโมเดลและความต้องการของผู้ใช้เปลี่ยนไป
    ตัวอย่างเช่น ถ้าจะเปลี่ยนพรอมป์ตหรือใช้คลาส Python ปริมาณงานระหว่างการใช้ไลบรารีแบบนี้กับการยก API call และ text template ให้ผู้ใช้จัดการเอง(https://github.com/hofstadter-io/hof/blob/_dev/flow/chat/llm...) ต่างกันมาก

    • มูลค่าอยู่ตรงนี้: 1) รัน ตัวตรวจสอบชนิดของ TypeScript กับผลลัพธ์ที่ LLM ส่งกลับมา 2) ถ้ามี type error ก็รวบรวมมันแล้วสร้างเป็น “พรอมป์ตแก้ไข” เพื่อชักนำให้ได้เอาต์พุตที่มีโอกาสผ่านการตรวจชนิดสูงขึ้น 3) ถ้า heuristic ในข้อ 2 ล้มเหลว ก็จัดการกรณีนั้นได้อย่างเรียบร้อย
      https://github.com/microsoft/TypeChat/blob/main/src/typechat...
      จากประสบการณ์ที่เคยลองแนวคิดเดียวกัน heuristic ในข้อ 2 ใช้งานได้ดีจนน่าแปลกใจกับชนิดข้อมูลที่ค่อนข้างง่าย คือเรคคอร์ดและอาร์เรย์ที่ไม่ซ้อนลึกมาก และมีการใช้ type variable แบบจำกัด เพียงแค่พรอมป์ตให้ LLM คืนค่าที่เป็นชนิดค่อนข้างง่ายก็สร้างแอปที่มีประโยชน์ได้แล้ว และไลบรารีนี้ก็มีคุณค่าเพราะลดความจำเป็นในการลงมือทำแพตเทิร์นการร้องขอแบบนั้นเอง พร้อมให้การผสานเข้ากับโค้ดเบส TypeScript แบบมาตรฐาน
    • ไลบรารี LLM ที่เห็นช่วงนี้แทบทั้งหมดก็เป็นแบบนี้ สุดท้ายก็ลงเอยที่การขอให้ LLM ทำบางอย่างในรูปแบบที่กำหนด และผมเคยเห็นว่าเมื่อเจอ เงื่อนไขซับซ้อน มันจะทำตามคำสั่งได้น้อยลงและกลับไปสู่พฤติกรรมพื้นฐาน
      ถึงอย่างนั้นก็ดูเหมือนการใช้ไลบรารีจะเป็นทิศทางที่ถูกอยู่ เลยยังคอยดูต่อไปว่าแนวทางไหนจะสุกงอมพอ
    • ไม่เข้าใจว่าการผูกติดกับผู้ให้บริการอยู่ตรงไหน นี่คือ ไลบรารีโอเพนซอร์ส และในไฟล์ที่ลิงก์ไว้ก็มีการตั้งค่าสำหรับผู้ให้บริการสองรายคือ ChatGPT กับ Bard
    • มูลค่าอยู่ที่การแปลง ข้อมูลไม่มีโครงสร้าง ให้เป็นข้อมูลที่มีโครงสร้าง และรับประกันว่ามันตรงตามข้อจำกัดของสคีมา
      เช่น ถ้ามีคำตอบแบบข้อความอิสระจากแบบสำรวจเกี่ยวกับผลิตภัณฑ์ 1000 รายการ ก็สร้างสคีมาแล้วรัน TypeChat กับแต่ละรายการเพื่อให้ได้ชุดข้อมูลจากข้อความอิสระเหล่านั้น มีประโยชน์มาก
    • ยิ่ง abstraction ดีขึ้น ก็ยิ่งเขียนสิ่งที่มีประโยชน์ได้ง่ายขึ้น

  • มีอยู่จุดหนึ่งที่ผมไม่เข้าใจ
    ไม่เข้าใจว่าทำไมต้องผ่านขั้นตอนซับซ้อนแบบคาดหวังว่าจะได้คำตอบที่ใช้ได้ จากนั้นค่อยติดตัวตรวจสอบปลายทางเพื่อตรวจจับคำตอบที่ผิด แล้วไปขอร้องให้โมเดลตอบด้วยไวยากรณ์ที่ต้องการ
    ถ้าสุ่มเลือกเฉพาะโทเค็นที่ตรงกับรูปแบบที่ร้องขอ ก็สามารถรับประกัน ไวยากรณ์ JSON ที่ถูกต้อง ได้ แทนที่จะเลือกโทเค็นคะแนนสูงสุดแบบละโมบทุกครั้ง ก็แค่เลือกโทเค็นที่ได้คะแนนสูงสุดในบรรดาโทเค็นที่สอดคล้องกับรูปแบบที่ต้องการ
    Guidance ของ Microsoft ทำแบบนี้อยู่แล้ว: https://github.com/microsoft/guidance
    แต่ดูเหมือน OpenAI จะไม่เปิดคะแนนเต็มของทุกโทเค็น และเปิดเผยแค่โทเค็นคะแนนสูงสุดเท่านั้น ถ้ารันโมเดลในเครื่อง การใช้ Guidance นั้นง่าย รับประกันได้ว่า JSON จะถูกต้องทุกครั้ง และยังสร้างได้เร็วกว่าอีก เลยดูแปลก

    • คล้ายกับเรื่อง M&M สีน้ำตาล[0] ถ้าโมเดลส่งคืนข้อมูลที่ถูกต้องในเชิงความหมาย อย่างน้อยก็ควรคาดหวังได้ว่ามันจะจัดไวยากรณ์ให้ถูก ถ้าทำไม่ได้ก็คงต้องทิ้งคำตอบนั้นอยู่ดี
      อีกอย่าง วิธีนั้นก็น่าจะถ่ายทอดความซับซ้อนทั้งหมดของ ชนิดข้อมูล TypeScript ได้ยาก
      [0] https://www.snopes.com/fact-check/brown-out/
    • วิธีนั้นรับประกัน JSON ที่ถูกต้องตามไวยากรณ์ได้ก็จริง แต่เรื่อง ความถูกต้องเชิงความหมาย เป็นอีกประเด็นหนึ่ง
      ถ้าโมเดลจริง ๆ อยากใส่โทเค็นอื่น แต่ถูกบังคับให้ใส่ { คุณภาพของข้อความที่สร้างต่อจากนั้นอาจแย่ลงก็ได้ ไม่ได้มั่นใจ แค่นึกความเป็นไปได้ออกมา
    • ผมมองว่าวิธีสุ่มเลือกเฉพาะโทเค็นที่ใช้ได้มีอนาคตมาก
      ผมเคย fine-tune โอเพนซอร์ส LLM สำหรับงานแยกวิเคราะห์ JSON และแม้ไม่ใช้ guided token sampling ก็ยังรู้สึกว่า พารามิเตอร์ 70B อาจเกินความจำเป็นสำหรับบางงาน ผมเห็นผลลัพธ์ค่อนข้างดีจากโมเดลที่เล็กกว่านี้มาก และคิดว่าการผสานการ fine-tune โมเดลขนาดเล็กกับ guided token sampling น่าจะน่าสนใจ
      แต่สำหรับแอปที่ต้องครอบคลุมกว้างมาก การ fine-tune อาจไม่สมบูรณ์แบบ เพราะจะลำบากเมื่อมีอินพุตที่ไม่คาดคิดจากชุดข้อมูลฝึก
    • LLM สามารถจัดการสถานการณ์ที่ซับซ้อนกว่านี้ได้ เช่น ใน ตู้ขายสินค้าอัตโนมัติ ถ้าพูดสั่งของไปตรง ๆ โดยไม่ผ่านขั้นตอนการสั่งซื้อทั้งหมด มันอาจเดาจากสต็อกได้ว่า “ช็อกโกแลตบาร์สองสามอัน” หมายถึงอะไร
      แน่นอนว่าบนเว็บมันไม่สมเหตุสมผล การคลิกสินค้าสองสามอย่างด้วยเมาส์ง่ายกว่ามาก
    • อย่างที่ Llama.cpp อธิบายไว้ล่าสุด มันได้เพิ่ม การสุ่มตัวอย่างตามไวยากรณ์ ที่จำกัดการเลือกโทเค็นให้เป็นไปตามรูปแบบคงที่
      https://github.com/ggerganov/llama.cpp/pull/1773

  • พอฉันคิดอะไรขึ้นมา ก็เหมือน Anders Hejlsberg จะสร้างมันออกมาก่อนเสมอ
    คำขอและคำตอบแบบมีโครงสร้าง นี่แหละคือวิวัฒนาการขั้นถัดไปของ LLM แบบ 100% ผู้คนเริ่มเบื่อแชตบอตกันแล้ว และถ้าสามารถเสียบเข้ากับแบ็กเอนด์ไหนก็ได้โดยไม่ต้องกังวลเรื่องการ parse ข้อความหรือการเขียนพรอมป์ต ก็คงยอดมาก

    • ฉันอยากเอา อินเทอร์เฟซที่สั่งงานได้ ที่ฉันจัดเตรียมไว้ ไปผูกกับ LLM ที่รันในเครื่อง เช่น “เช็กเวลา”, “ดูปฏิทิน”, “ส่งข้อความถึงผู้ใช้” อะไรทำนองนั้น
      TypeChat ดูเหมือนจะมาถูกทางแล้ว นึกภาพเลเยอร์เพิ่มอย่าง “จัด JSON input นี้ให้เข้ากับหนึ่งใน action ที่ทำได้ ถ้าทำได้” ออกเลย
      มองเห็นอนาคตแบบไฮบริดที่สะอาดดี ซึ่งบอตหรือ LLM จะคอยเชื่อมชั้นโค้ดจริง ๆ เข้าด้วยกัน บางครั้งก็เป็นส่วนหนึ่งของการเก็บรวบรวม/ติดแท็ก บางครั้งก็เป็นส่วนหนึ่งที่ตอบสนองต่ออินพุต
      โดยรวมเป็นพื้นที่ที่น่าสนใจมาก แต่ทุกอย่างเคลื่อนไหวเร็วเกินไปจนฉันยังไม่ได้ลงลึกมากนัก รู้สึกว่ามีคนเก่ง ๆ ทำงานอยู่เยอะ เลยอาจต้องรอให้ฝุ่นจางลงอีกหน่อย ถึงอย่างนั้นก็ดูเหมือนว่าอินเทอร์เฟซภายในบ้านในฝันของฉันมาถึงจุดที่สร้างได้แล้ว
    • เมื่อวานเพิ่งทำอะไรคล้าย ๆ กันไปเอง แต่โฟกัสไปที่ ฟังก์ชันเป็นศูนย์กลาง มากกว่าวัตถุ
    • ถ้าใช้เป็น ตัวแมปแบบไดนามิก ของชั้นแบ็กเอนด์ได้ก็น่าจะสุดยอดมาก
      ลองดู API payload ที่เปลี่ยนบ่อย ๆ รอบ ๆ consumer ฝั่ง Java สิ ในวงการธนาคารกับ JSON payload ขนาดมหึมา ฉันถึงกับต้องทำชั้น NodeJS แยกไว้เพื่อรักษาสติในสภาพแวดล้อมแบ็กเอนด์ Java
      งานแมปปิงเป็นจุดที่ LLM เปล่งประกายได้จริง
    • น่าลองดู: https://news.ycombinator.com/item?id=36750083

  • ถ้าจะตีความแบบร้อนแรงหน่อย เรากำลังค่อย ๆ เข้าสู่ ช่วงที่ AI กลายเป็นเครื่องมือ ผู้คนเริ่มตระหนักว่าในนี้ไม่ได้มีการสร้างคุณค่าจริงมากนัก แต่มีการลงทุนใน AI มากเกินไปจนเงินยังคงไหลเข้าไปเรื่อย ๆ มันยังเป็นหัวข้อที่ดีสำหรับตีพิมพ์งานวิชาการด้วย และ LangChain นี่แทบจะเป็นมุกตลกแต่ก็ได้เงิน seed ไป 10 ล้านดอลลาร์
    DeFi/crypto ก็ผ่านช่วงนี้มาแล้วเมื่อ 2 ปีก่อน หลังจากอยู่ในภาวะประหลาด ๆ แบบ limbo ไปอีกหลายปี ผู้คนก็จะค่อย ๆ ตระหนักว่า AI ไม่ใช่ผลิตภัณฑ์แต่เป็นฟีเจอร์ มีขอบเขตการใช้งานจำกัด และไม่ได้จะมากอบกู้โลก เราจะทำรถยนต์ไร้คนขับไม่ได้เพราะมี edge case เต็มไปหมด และจะทำการผ่าตัดไม่ได้เพราะมันอาจฆ่าคนได้
    ฉันพูดมาตลอดว่าแม้แต่เครื่องมือ AI ที่มีประโยชน์ที่สุดอย่าง Copilot ก็ยังมีประโยชน์ได้แค่ในเชิงข้างเคียงเท่านั้น อย่างดีที่สุดก็แค่ช่วยลดจำนวนคลิกบน Google ลงไม่กี่ครั้ง และ agent ก็ไม่ได้ “ฉลาด” เลย เราเคยผ่านฟองสบู่คล้าย ๆ กันกับแชตบอตเมื่อหลายปีก่อน[1] และเดี๋ยวนี้ก็ไม่มีใครสนใจแล้ว “เมตาเวิร์ส” จบสั้นกว่ามาก แต่ก็เป็นจิตวิทยามวลชนแบบเดียวกัน จาก “สิ่งใหญ่ลำดับถัดไป” กลายเป็นไม่ใช่เสียอย่างนั้น
    [1] https://venturebeat.com/business/facebook-opens-its-messenger...

    • ขอคัดค้านอย่างแรงกับคำพูดที่ว่า AI เป็นแค่ฟองสบู่ขอบเขตจำกัด
      คุณยกแต่กรณีใช้งานที่ยากที่สุดของ AI อย่างรถยนต์ไร้คนขับกับการผ่าตัด งานของคนส่วนใหญ่ไม่ได้เกี่ยวกับความเป็นความตาย จึงเหมาะกับการ ทำงานอัตโนมัติ มาก ต่อให้ในอาชีพที่เกี่ยวกับชีวิตคนจะยังต้องมีมนุษย์อยู่ ก็น่าจะถูกเสริมด้วย AI agent อย่างมาก ตัวอย่างเช่น แม้การผ่าตัดจะยังทำโดยมนุษย์ แต่การวินิจฉัยร่วมกับ AI โดยแพทย์หรือพยาบาลอาจกลายเป็นข้อบังคับได้
      คุณกำลังเปรียบเทียบฟองสบู่แชตบอตเมื่อหลายปีก่อนกับตอนนี้อย่างจริงจังหรือ? ChatGPT แตะผู้ใช้ 100 ล้านคนในเวลาไม่กี่เดือน และมีคนจำนวนมหาศาลได้ลองใช้จริง ฟองสบู่แชตบอตเมื่อหลายปีก่อนแทบไม่มีตัวตนด้วยซ้ำ
      ที่บอกว่า Copilot และอื่น ๆ มีประโยชน์แค่ข้างเคียง ก็เพราะตอนนี้เรากำลังเห็นเวอร์ชันที่แย่ที่สุดของมันอยู่ ChatGPT เปลี่ยนชีวิตฉันไปแล้ว ทั้งที่ยังรันโค้ดไม่ได้ด้วยซ้ำ Code Interpreter รันได้ แต่ฉันยังไม่ได้ลองทดสอบ
      พอถึงราวปี 2030 มนุษย์ก็คงไม่พิมพ์โค้ดกันแล้ว แต่จะคอยให้พรอมป์ตกับเครื่องและกำกับ AI agent แทน และตอนนั้นงานส่วนใหญ่ก็น่าจะถูกทำให้เป็นอัตโนมัติได้ด้วย
      AI ไม่ใช่แค่กระแส แต่จะเปลี่ยนทุกอุตสาหกรรม และเร็วกว่าที่คนคิดมาก การประชดประชันที่เอา AI ไปเทียบกับเมตาเวิร์สเพื่อลดทอนนัยสำคัญของมันนั้นทั้งไร้สาระและขาดจินตนาการ โดยเฉพาะฝั่ง AI agent ยังมีงานให้ทำอีกมาก แต่เราน่าจะไปถึงจุดนั้นเร็วกว่าที่คนคิดมาก และผลกระทบก็จะมหาศาล
    • ทุกครั้งที่ใช้ ChatGPT ฉันรู้สึกเหมือนกำลังเห็นเทคโนโลยีคนละอย่างกับที่คนอื่นเห็น เขาว่ามันตอบได้ทุกคำถาม สอนได้ทุกเรื่อง แต่สำหรับฉันมันให้ความรู้สึกเหมือน บริการฟาร์มคอนเทนต์ มากกว่า Copilot ก็คล้ายกัน ส่วนใหญ่แล้วการเลือกตัวอย่างแย่ ๆ ที่พอแย่น้อยหน่อยและไล่แก้บั๊ก ยังสู้เขียนโค้ดเองตรง ๆ ไม่ได้
      แต่ AlphaGo ก็ใช้เวลาไม่นานจากสภาพที่ “หลอน” เดินหมากแย่ ๆ ไปสู่การเป็นนักหมากล้อมที่เก่งที่สุดในโลก ถ้าสิ่งนี้เกิดขึ้นกับโมเดลภาษาได้เหมือนกัน GPT-x ก็อาจล้างข้อถกเถียงตอนนี้ทิ้งหมดได้
    • ขอคัดค้านอย่างแรงกับคำพูดที่ว่า “ไม่มีการสร้างคุณค่าจริง” ในกรณีใช้งานของฉันมีตัวอย่างโต้แย้งที่ชัดเจนมาก
      GPT-4 ช่วยได้มหาศาลเวลาที่คนมีทักษะทำงานข้างเคียงซึ่งทักษะพื้นฐานของตัวเองยังพอเอาอยู่ แต่ความรู้เฉพาะโดเมนยังอ่อน
      ฉันเขียนโค้ดมา 10 ปี และช่วงนี้กำลังเรียน machine learning เป็นครั้งแรก ทุกวันฉันใช้ GPT-4 และพอใจมาก
      แน่นอนว่าบางครั้งความหยาบ ๆ ของมันก็น่ารำคาญ สำหรับฉันมันยังอยู่ในระดับที่จัดการได้และไม่ได้เป็นภาระมาก ฉันชินกับการมองข้ามหรือหาทางอ้อมไปแล้ว และการใช้เครื่องมือแบบนี้ก็มีทักษะของมันอยู่จริง
      ฉันมองว่าคุณค่าที่มันมอบให้จะเพิ่มขึ้นเรื่อย ๆ เรายังเก็บผลไม้ที่ห้อยต่ำและระดับกลางได้ไม่หมดเลยด้วยซ้ำ
    • ความต่างสำคัญกับ DeFi/crypto คือ ต่อให้ฝั่งนั้นจะน่าประทับใจในเชิงเทคนิคแค่ไหน ผู้คนก็ต้องเปลี่ยนวิธีทำสิ่งต่าง ๆ ไปอย่างสิ้นเชิงเพื่อให้ได้ประโยชน์แรกจากมัน
      ส่วน AI ยุคใหม่ หรือจริง ๆ แล้วส่วนมากก็คือ LLM สามารถนำไปใช้ได้ทันทีและกว้างขวางในแทบทุกภาคส่วนเศรษฐกิจ นั่นจึงเป็นเหตุผลว่าทำไมคนจำนวนมากถึงกำลังสร้างและปล่อยฟีเจอร์กันอยู่แล้ว เทคโนโลยีนี้มีคุณค่ามหาศาล จะเปลี่ยนโลกทั้งหมดไหมก็ไม่ แต่เพียงพอที่จะสร้างหมวดหมู่ผลิตภัณฑ์ใหม่ และยกระดับความสามารถส่วนใหญ่ของผลิตภัณฑ์เดิมอย่างมีนัยสำคัญในระดับรากฐาน
    • รู้สึกว่าเป็นการตีความที่ค่อนข้างสมเหตุสมผล AI มีประโยชน์ใช้สอยมากและเก่งมากกับงานบางอย่าง แต่ไม่ใช่ ยาวิเศษแก้ได้ทุกอย่าง อย่างที่คนคาดหวัง

  • ยังไม่เข้าใจว่าทำไมในบรรดาผู้ช่วยเสียงของ Apple, Google, Amazon และ Microsoft ถึงยังไม่มีรายไหนผสาน LLM เข้ากับบริการอย่างจริงจัง และทำไม OpenAI ถึงยังไม่ออก ผู้ช่วยเสียง ของตัวเอง
    อีกอย่าง ถ้าเว็บไซต์ต่าง ๆ เปิดเผย URL มาตรฐานสำหรับการโต้ตอบกับ AI เหมือน RSS และเปิดอินเทอร์เฟซผ่าน TypeChat ก็ดูเหมือนว่าเราน่าจะไปได้ไกลพอสมควรในทางนั้น

    • OpenAI มีโอกาสสูงที่จะทำผู้ช่วยของตัวเอง ถ้าดูจาก “Building a kind of JARVIS @ OреոΑӏ” ของ Karpathy ก็น่าจะเป็นแบบนั้น และ Microsoft เองก็คงกำลังทำงานเรื่องการผสานหรือตีความ Cortana ใหม่ด้วย LLM ของ OpenAI อยู่แล้ว
      แต่เมื่อเทียบกับ LLM แบบเสียงแล้ว คุณค่าของ ความสามารถในการลงมือทำจริง นั้นสูงกว่ามาก ยกตัวอย่าง Alexa จำเป็นต้องมีระบบที่จัดการการควบคุมสมาร์ตโฮมได้อย่างคาดเดาได้และดีบักได้ ไม่อย่างนั้นคนก็จะหงุดหงิด
      ผมคิดว่ามันเป็นไปได้แน่ ๆ แต่ระบบอย่าง Alexa หรือ Siri ในปัจจุบัน รวมถึง Cortana ที่คนนิยมใช้น้อยกว่า ต่างก็เป็นกฎและซอฟต์แวร์ที่สร้างทับอยู่บนโมเดลที่ทรงพลังน้อยกว่ามาหลายปี และใช้ฮุกกับ API มากมาย การจะทำให้มันใช้งานได้ต้องทั้งปรับปรุงโดยยังรักษาคุณภาพปัจจุบันไว้ และในขณะเดียวกันก็ต้องรื้อส่วนหลักของระบบใหม่ จึงต้องใช้เวลา
      แถมผู้ช่วยพวกนี้ก็ทำเงินไม่ได้จริงและส่วนใหญ่ขาดทุน มีคุณค่าก็เฉพาะกับบริษัทยักษ์ใหญ่ที่สามารถหารายได้หรือผลักดันธุรกิจด้วยวิธีอื่น เช่น โทรศัพท์มือถือหรือการชอปปิง ดังนั้นแรงจูงใจสำหรับสตาร์ตอัปจึงมีน้อย
      เมื่อก่อนผมเคยทำงานทั้งฝั่ง Cortana และ Alexa และก็เคยคิดหนักพอสมควรเรื่องการสร้างเวอร์ชันใหม่ตั้งแต่ต้นโดยอิงจากความก้าวหน้าของ LLM เทคโนโลยีโดยรวมดูตรงไปตรงมา และก็มีไอเดียกรณีใช้งานใหม่ ๆ ที่เพิ่งเป็นไปได้ในตอนนี้ด้วย แต่ผมหาโมเดลธุรกิจที่ใช้งานได้ไม่เจอ เลยตอนนี้ไปทำอย่างอื่นที่ต่างออกไปเลย
    • ตอนที่ผมเพิ่งรู้ครั้งแรกว่า ChatGPT คืออะไร ความคิดแรกที่แวบเข้ามาคือ “อ้อ Siri ควรจะเป็นแบบนี้มาตั้งแต่แรกสิ”
    • หลังจากได้ลองใช้ ChatGPT กับ Bing แล้ว การคุยกับ Alexa ก็ดูน่าขำไปเลย น่าหงุดหงิดจริง ๆ ที่เห็นฮาร์ดแวร์ดี ๆ ถูกซอฟต์แวร์ห่วย ๆ ฉุดไว้มาเป็นเวลาหลายปี
    • Microsoft กำลังทำแบบนั้นเพื่อแทนที่ Cortana ใน Windows 11
    • ผมหวังมากว่าจะมีอะไรสักอย่างที่ใช้ควบคุม Home Assistant ได้
      แต่การใช้ API แบบคลาวด์เพื่อเรื่องนี้ทำให้รู้สึกไม่สบายใจเกินไป เลยอยากได้แบบที่รันบนเซิร์ฟเวอร์ในบ้าน และในขณะเดียวกัน การรู้จำเสียงกับเวลาตอบสนองก็ต้องเร็วมากจนไม่รู้สึกว่าต้องรอเลย
      ผมเคยเห็นความพยายามทำผู้ช่วยส่วนตัวแบบ DIY มาหลายครั้ง แต่จะมีดีเลย์ค่อนข้างมากตลอด จนรู้สึกว่าถ้าใช้บ่อย ๆ คงน่าหงุดหงิดอย่างรวดเร็ว

  • มีจุดหนึ่งที่ดูเหมือนจะได้คำตอบแบบ { "name": "grande latte" } ได้ง่าย
    แต่ถ้าชนิดข้อมูลเป็น Item = { name: string; ... size?: string; } ก็ยังไม่ค่อยเข้าใจว่ามันช่วยหลีกเลี่ยง name: "grande latte" ได้อย่างไร
    ในตัวอย่างคำตอบมี "size": 16 อยู่และบอกว่า “ค่อนข้างยอดเยี่ยม” แต่จริง ๆ แล้วมันไม่ได้คืนค่าตามชนิดข้อมูลที่ร้องขอด้วยซ้ำ น่าจะเป็นแค่พิมพ์ผิดในตัวอย่างมากกว่า ซึ่งถ้าเป็นอย่างนั้น ไอเดียเองก็ดูเจ๋งดี

    • ขอบคุณที่ทักนะ ในบล็อกโพสต์เวอร์ชันก่อนหน้านี้ใช้สคีมาอีกตัวที่เผลอกำหนด size เป็น number ไว้ผิดพลาด ผมเปลี่ยนสคีมาแล้วแต่ยังไม่ได้รันพรอมป์ต์ใหม่ ตอนนี้น่าจะแก้เรียบร้อยแล้ว
    • ผมมองว่าตัวอย่างนี้ค่อนข้างอ่อนโดยรวม ไม่ใช่แค่เรื่องพิมพ์ผิดอย่างเดียว
      ตั้งแต่แรกแล้วก็มีโอกาสสูงที่เราไม่อยากได้ฟิลด์สตริง name เราไม่สามารถป้องกันค่าประเภท { name: “the brown one”, size: “the espresso cup”, … } ได้ และมันก็แย่พอ ๆ กับการพาร์สสตริงต้นฉบับโดยตรง
      ที่จริงน่าจะต้องการ ชนิดยูเนียนของสตริง ขนาดใหญ่ที่แทนค่าที่รู้จักสำหรับแต่ละฟิลด์ แบบนั้นก็ให้ LLM เดาให้อยู่ในกลุ่มนั้นได้
      แต่ก็ยังสงสัยอยู่ดีว่าทำไมต้องผูกสิ่งนั้นไว้กับไวยากรณ์ของ type ด้วย ฝั่งอย่าง Zod ที่สามารถสร้างยูเนียนประเภทนั้นจากข้อมูลรันไทม์ได้น่าจะเหมาะกว่า
      ยังต้องมีข้อจำกัดอย่างจำนวนต้องเป็นจำนวนเต็มบวกและห้ามเป็นเศษส่วนด้วย แน่นอนว่าเราสามารถตรวจสอบค่า JSON ภายหลังได้ แต่ถ้าทำแบบนั้น ผู้ใช้จะเห็นข้อผิดพลาดสองประเภท แบบหนึ่งคือข้อผิดพลาดที่ LLM สร้างขึ้นด้วยภาษามนุษย์ที่ลื่นไหล และอีกแบบคือข้อผิดพลาดเชิงเทคนิคแปลก ๆ อย่าง “ค่าจำนวนมากเกินไป”
      ไวยากรณ์ของ type ดูเหมือนอยู่ผิดที่สำหรับการอธิบายเรื่องพวกนี้
    • ดูเหมือนเป็นแค่ บั๊กในเอกสาร มากกว่า ช่วงท้าย ๆ ตอนเขียนบทประกาศน่าจะเปลี่ยนจากขนาดเป็นออนซ์ไปเป็นขนาดมาตรฐาน แล้วลืมปรับค่าผลลัพธ์ให้ตรงกัน
      จากโค้ดที่ให้มาอย่างเดียว ระบบไม่มีทางแมป “grande” เป็น 16 ได้ และ 16 ก็ดูเหมือนไม่ได้ถูกใช้ที่อื่นด้วย
    • ในย่อหน้าถัดไปเขาพูดถึง “จะเกิดอะไรขึ้นถ้าไม่สนใจ type” ดังนั้นน่าจะเขียนมาโดยตั้งใจในแง่นั้น

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

    • อย่างน้อยใน OpenAI การใช้ ความสามารถในการเรียกฟังก์ชัน แบบใหม่ภายในน่าจะดีกว่าไหม?
    • ผมไม่แน่ใจว่า TypeChat ทำงานอย่างไร แต่ Guidance [1] ก็เป็นโปรเจกต์คล้ายกัน และจริง ๆ แล้วสามารถผสานเข้ากับการสุ่มตัวอย่างโทเคนเพื่อบังคับรูปแบบได้
      [1]: https://github.com/microsoft/guidance
    • ผลิตภัณฑ์ส่วนใหญ่น่าจะกังวลเรื่อง ความสอดคล้องกับตลาดของผลิตภัณฑ์ ก่อน แล้วค่อยหาทางลดต้นทุนทีหลัง
      และก็มีสมมติฐานที่ฟังขึ้นพอสมควรว่าในเมื่อ ตลาดต้องการเอาต์พุตแบบมีโครงสร้าง โมเดลต่าง ๆ ก็จะพัฒนาไปในทางนั้นด้วย

  • สัปดาห์นี้ผมเพิ่งทำสิ่งที่คล้ายกับอันนี้มากแต่ขอบเขตเล็กกว่าสำหรับ Laravel PHP แล้วก็ปล่อยออกมา: https://github.com/adrenallen/ai-agents-laravel
    ผมคิดว่าวิศวกรควรจะสามารถเปิดใช้ “บอต” ใหม่กับ LLM ที่มีอยู่ได้อย่างง่ายดาย มีงานน่าเบื่ออยู่เยอะในการแปลงฟังก์ชันให้อยู่ในรูปแบบที่ ChatGPT เข้าใจได้ แล้วก็จัดการคำตอบก่อนแยกวิเคราะห์กลับอีกที
    ถ้าใช้ระบบแบบนี้ คุณจะโฟกัสกับการเขียนโค้ด PHP จริง ๆ และเพิ่มคอมเมนต์ที่ชัดเจนไม่กี่จุด จากนั้นบอตก็จะใช้โค้ดนั้นเป็นเครื่องมือได้ทันทีไม่ว่างานไหนก็ตาม
    อีกอย่าง วิธีนี้ทำให้การแชร์โค้ดง่ายขึ้นมาก ถ้าใครเขียนฟังก์ชันไว้ ก็เอาไปใส่ในบอตตัวใหม่แล้วใช้ได้ทันที ผมชอบตรงที่มันตัด “ชั้นแปลงเพื่อให้ LLM ใช้และเข้าใจได้” ออกไป และช่วยเพิ่มความเร็วในการสร้างอย่างมาก
    มันยังไม่สมบูรณ์แบบ แต่ผมคิดว่าสุดท้ายแล้วทุกอย่างจะไปทางนี้ ถ้าเราอยากใช้โค้ดของกันและกันได้ดีขึ้น ลองนึกถึงวิธีที่ทุกวันนี้เราใช้ package manager ในการเขียนโค้ด ผมอยากมี package manager สำหรับเครื่องมือเฉพาะทาง AI ด้วย เช่น ติดตั้งไลบรารี “ดึงสภาพอากาศ” แล้วเพิ่มเข้าไปในบอตของผม จากนั้นมันก็สามารถดึงสภาพอากาศได้

    • ผมกำลังทำแนวทางที่คล้ายกันแต่กว้างกว่านิดหน่อยอยู่ เลยกดดาวไว้ มีไอเดียบางอย่างที่เนี้ยบมากจริง ๆ

  • เดี๋ยวก่อน นี่คือการทำ runtime validation กับอ็อบเจ็กต์ตาม type definition ของ TypeScript ใช่ไหม? ถ้าปล่อยเป็นไลบรารีหรือฟีเจอร์แบบแยกเดี่ยวได้ นี่อาจเป็นตัวเปลี่ยนเกมอย่างแท้จริงสำหรับการตรวจสอบ payload ของ API response ใน codebase TypeScript

  • แปลกใจมากที่ที่นี่ไม่ใช้ guidance [0]
    มันน่าจะช่วยแนะนำการเติมฟิลด์ที่จำเป็นให้ครบได้ ทำให้ลดความจำเป็นของการตรวจสอบความถูกต้อง[1] ลงได้ และสุดท้ายก็น่าจะประหยัด เวลา GPU ได้ด้วย
    ต้องมีเหตุผลแน่ ๆ และผมอยากรู้จริง ๆ
    พูดนอกเรื่องนิดหนึ่ง ผมเองก็กำลังสร้างอะไรประมาณนี้อยู่พอดี แล้ว Microsoft ก็โผล่มาเหมือนมาแย่งข้าวกลางวันผมไป
    [0] https://github.com/microsoft/guidance
    [1] https://github.com/microsoft/TypeChat/blob/main/src/typechat...