Prompt API

• เป็น Web API สำหรับส่งคำขอภาษาธรรมชาติไปยัง Gemini Nano ที่ฝังอยู่ใน Chrome และนำไปใช้กับงานอย่างถาม-ตอบ, การจัดหมวดหมู่, การกรองคอนเทนต์, การดึงกำหนดการ, และการดึงข้อมูลติดต่อได้
• ก่อนใช้งานต้องมีการดาวน์โหลดโมเดลแยกต่างหาก และจะทำงานได้ก็ต่อเมื่อเป็นไปตามเงื่อนไขการรัน เช่น OS ที่รองรับ, พื้นที่เก็บข้อมูล, และหน่วยความจำ GPU หรือ CPU
• เซสชันเตรียมใช้งานได้โดยตรวจสอบความพร้อมผ่าน LanguageModel.availability() แล้วเรียก create() จากนั้นสามารถต่อเนื่องหรือแตกแขนงคอนเท็กซ์ได้ด้วย initialPrompts, append(), และ clone()
• อินพุตรองรับ text, image, audio ส่วนเอาต์พุตตอนนี้รองรับเฉพาะ text โดย prompt() จะคืนคำตอบแบบเสร็จสมบูรณ์ และ promptStreaming() จะคืนคำตอบแบบสตรีมมิง
• มีทั้งเอาต์พุตแบบมีโครงสร้างด้วย responseConstraint, การจัดการ context window, permission policy, และการประมวลผลแบบมัลติโหมด ทำให้มีโมเดลการทำงานสำหรับ AI บนอุปกรณ์ภายในเบราว์เซอร์

---

ภาพรวม

• ทำงานเป็น API สำหรับส่งคำขอภาษาธรรมชาติไปยัง Gemini Nano ที่ฝังอยู่ใน Chrome และสามารถนำไปใช้กับงานอย่างถาม-ตอบบนหน้าเว็บ, การจัดหมวดหมู่บทความ, การกรองคอนเทนต์, การดึงกำหนดการ, และการดึงข้อมูลติดต่อ
• แม้ Chrome จะฝัง API มาให้แล้ว แต่ตัวโมเดลยังต้องดาวน์โหลดแยกต่างหาก และก่อนใช้งานครั้งแรกควรตรวจสอบ Google's Generative AI Prohibited Uses Policy
• ก่อนใช้งาน Generative AI แนะนำให้อ้างอิง People + AI Guidebook
• สามารถใช้ TypeScript typings ได้จากแพ็กเกจ @types/dom-chromium-ai
• นักพัฒนา Chrome Extensions ต้องลบสิทธิ์ origin trial ที่หมดอายุแล้วชื่อ aiLanguageModelOriginTrial

ฮาร์ดแวร์และเงื่อนไขการรัน

• Prompt API, Summarizer API, Writer API, Rewriter API และ Proofreader API จะทำงานบน Chrome ได้เมื่อเป็นไปตามเงื่อนไขบางอย่าง
• ระบบปฏิบัติการที่รองรับคือ Windows 10/11, macOS 13+, Linux และ ChromeOS โดย ChromeOS รองรับเมื่อเป็นอุปกรณ์ Chromebook Plus ที่ใช้ Platform 16389.0.0 ขึ้นไป
• Chrome for Android, iOS และ ChromeOS บนอุปกรณ์ที่ไม่ใช่ Chromebook Plus ยังไม่รองรับ API ที่อิง Gemini Nano
• พื้นที่เก็บข้อมูลต้องมีพื้นที่ว่างอย่างน้อย 22GB บนโวลุมที่มี Chrome profile อยู่
• การรันโมเดลทำได้ผ่าน GPU หรือ CPU
  • GPU ต้องมี VRAM มากกว่า 4GB
  • CPU ต้องมี RAM อย่างน้อย 16GB และ CPU core อย่างน้อย 4 คอร์
  • Prompt API ที่ใช้อินพุตเสียงจะต้องใช้ GPU
• เครือข่ายจำเป็นต้องเป็นการเชื่อมต่อแบบไม่จำกัดหรือไม่คิดตามปริมาณการใช้ เฉพาะตอนดาวน์โหลดโมเดลครั้งแรก
  • หลังจากนั้นการใช้งานโมเดลไม่ต้องใช้การเชื่อมต่อเครือข่าย
  • ระหว่างใช้โมเดล ข้อมูลจะไม่ถูกส่งไปยัง Google หรือบุคคลที่สาม
• ขนาดโมเดลอาจเปลี่ยนแปลงตามการอัปเดตเบราว์เซอร์ และสามารถตรวจสอบขนาดปัจจุบันได้ที่ chrome://on-device-internals
• หลังดาวน์โหลดแล้ว หากพื้นที่ว่างลดลงเหลือน้อยกว่า 10GB โมเดลจะถูกลบออกจากอุปกรณ์ และจะถูกดาวน์โหลดใหม่เมื่อกลับมาตรงตามเงื่อนไขอีกครั้ง

การเริ่มใช้งานและการเตรียมโมเดล

• ตรวจสอบความพร้อมใช้งานได้ผ่าน LanguageModel.availability()
• ใน availability() ต้องส่งออปชันเดียวกันกับที่จะใช้ใน prompt() หรือ promptStreaming() ภายหลัง
  • เนื่องจากบางโมเดลอาจไม่รองรับ modality หรือภาษาเฉพาะ การใช้ออปชันให้ตรงกันจึงสำคัญ
• การดาวน์โหลดโมเดลและสร้างเซสชันเริ่มต้นด้วย create() หลังตรวจสอบ user activation
• หากกำลังดาวน์โหลดอยู่ ควรรับ progress event เพื่อแจ้งสถานะการดาวน์โหลดให้ผู้ใช้ทราบ
• บน localhost สามารถเปิดใช้ Built-in AI API ได้ผ่าน Chrome flags
  • chrome://flags/#optimization-guide-on-device-model
  • chrome://flags/#prompt-api-for-gemini-nano-multimodal-input
  • จากนั้นต้อง Relaunch หรือรีสตาร์ต Chrome
  • หากเกิดข้อผิดพลาด สามารถดู การแก้ปัญหา localhost

การสร้างเซสชันและการตั้งค่าพื้นฐาน

• เซสชันถูกสร้างด้วย LanguageModel.create()
• ใน Prompt API สำหรับ Chrome Extensions สามารถปรับ topK และ temperature เป็นออปชันรายเซสชันได้
  • ตรวจสอบค่าเริ่มต้นและค่าสูงสุดได้ผ่าน LanguageModel.params()
  • ฟีเจอร์นี้ใช้ได้เฉพาะกับ Chrome Extensions หรือเมื่อใช้ sampling parameters origin trial
• params() จะคืนค่า defaultTopK, maxTopK, defaultTemperature, maxTemperature
• ตอนกำหนดค่าเซสชันใหม่ ต้องระบุ topK และ temperature ทั้งคู่หรือไม่ระบุทั้งคู่
• create() รับ AbortSignal ผ่านฟิลด์ signal เพื่อยกเลิกเซสชันได้

การจัดคอนเท็กซ์และการประกอบพรอมป์ต์

• ใช้ initialPrompts เพื่อใส่บริบทจากบทสนทนาก่อนหน้า ทำให้สามารถต่อเซสชันที่บันทึกไว้หลังรีสตาร์ตเบราว์เซอร์ได้
• ในอาร์เรย์พรอมป์ต์สามารถใส่บทบาท system, user, assistant ร่วมกันได้
• หากกำหนด prefix: true ให้ข้อความ assistant ตัวสุดท้าย จะสามารถเติมบางส่วนของคำตอบล่วงหน้าเพื่อชี้นำรูปแบบเอาต์พุตที่ต้องการได้
  • ตัวอย่างเช่น ใส่สตริงเริ่มต้นของ code block แบบ TOML ไว้ล่วงหน้าเพื่อบังคับรูปแบบเอาต์พุต
• หลังสร้างเซสชันแล้ว สามารถใส่คอนเท็กซ์เพิ่มเติมล่วงหน้าได้ด้วย append()
  • ต่างจาก initialPrompts ตรงที่สามารถสะสมคอนเท็กซ์ได้แม้สร้างเซสชันแล้ว
  • append() จะ resolve หลังจากพรอมป์ต์ถูกตรวจสอบ ประมวลผล และเพิ่มเข้าไปแล้ว
  • หากเป็นพรอมป์ต์ที่เพิ่มไม่ได้ promise จะถูก reject

รูปแบบอินพุต/เอาต์พุตและหลายภาษา

• ตอนสร้างเซสชันสามารถกำหนด รูปแบบและภาษา ของอินพุต/เอาต์พุตที่คาดหมายได้ผ่าน expectedInputs และ expectedOutputs
• type ของ expectedInputs รองรับ text, image, audio
• type ของ expectedOutputs ตอนนี้อนุญาตเฉพาะ text
• ภาษาใช้การกำหนดผ่านอาร์เรย์ languages โดย Prompt API รองรับ "en", "ja", "es"
  • การรองรับภาษาเพิ่มเติมกำลังอยู่ระหว่างพัฒนา
  • ฝั่งอินพุตสามารถใส่ภาษาของ system prompt และภาษาของ user prompt อย่างน้อยหนึ่งภาษาได้
  • ฝั่งเอาต์พุตสามารถใส่ภาษาเอาต์พุตได้อย่างน้อยหนึ่งภาษา
• หากพบอินพุตหรือเอาต์พุตที่ไม่รองรับ อาจเกิด "NotSupportedError" DOMException

อินพุตแบบมัลติโหมด

• นำไปใช้กับงานอย่างถอดเสียงจากเสียง หรือสร้างคำอธิบายภาพ, caption, และ alt text ได้
• เดโมที่เกี่ยวข้อง
  • Mediarecorder Audio Prompt
  • Canvas Image Prompt
• อินพุตเสียงรองรับชนิดต่อไปนี้
  • AudioBuffer
  • ArrayBufferView
  • ArrayBuffer
  • Blob
• อินพุตภาพรองรับชนิดต่อไปนี้
  • HTMLImageElement
  • SVGImageElement
  • HTMLVideoElement
  • HTMLCanvasElement
  • ImageBitmap
  • OffscreenCanvas
  • VideoFrame
  • Blob
  • ImageData
• ในตัวอย่าง มีการใส่ Blob ของภาพและ HTMLCanvasElement พร้อมกันเพื่อให้เปรียบเทียบสื่อภาพสองรายการ แล้วต่อด้วย AudioBuffer เพื่อรับคำตอบเสียงจากผู้ใช้

เอาต์พุตแบบมีโครงสร้างและข้อจำกัด

• สามารถใช้เอาต์พุตแบบมีโครงสร้างได้โดยใส่ JSON Schema ลงใน responseConstraint ของ prompt() หรือ promptStreaming()
• ดูฟีเจอร์ที่เกี่ยวข้องได้ที่ structured output
• ในตัวอย่าง มีการใส่ boolean schema เพื่อให้ตอบเพียง true หรือ false ว่าโพสต์นั้นเกี่ยวกับงานเซรามิกหรือไม่
• ตอนใช้งานจริง สามารถใส่ JSON Schema หรือ regex ไว้เป็นส่วนหนึ่งของข้อความได้เช่นกัน ซึ่งในกรณีนั้นจะใช้พื้นที่บางส่วนของ context window
• หากส่งออปชัน responseConstraint ให้ session.measureContextUsage() ก็จะวัดได้ว่าข้อจำกัดนี้ใช้คอนเท็กซ์ไปเท่าใด
• สามารถหลีกเลี่ยงพฤติกรรมนี้ได้ด้วยออปชัน omitResponseConstraintInput
  • ในกรณีนั้น แนะนำให้ใส่คำแนะนำเกี่ยวกับรูปแบบเอาต์พุตที่ต้องการไว้ในพรอมป์ต์ด้วย

วิธีรันพรอมป์ต์

• หากคาดว่าจะได้คำตอบสั้น ให้ใช้ prompt() เพื่อรับผลลัพธ์ที่เสร็จสมบูรณ์ในครั้งเดียว
• หากคาดว่าจะได้คำตอบยาว ให้ใช้ promptStreaming() เพื่อรับผลลัพธ์บางส่วนแบบสตรีมมิง
• promptStreaming() จะคืนค่า ReadableStream
• ทั้ง prompt() และ promptStreaming() รับ signal เป็นอาร์กิวเมนต์ตัวที่สองเพื่อยกเลิกพรอมป์ต์ระหว่างรันได้

การจัดการเซสชัน

• แต่ละเซสชันจะคงไว้ซึ่งคอนเท็กซ์ของบทสนทนา ทำให้ปฏิสัมพันธ์ก่อนหน้าส่งผลต่อคำตอบภายหลัง
• แต่ละเซสชันมีจำนวนโทเค็นสูงสุดที่ประมวลผลได้ และสามารถตรวจสอบการใช้งานปัจจุบันกับขีดจำกัดได้ผ่าน session.contextUsage และ session.contextWindow
• หากพรอมป์ต์ใหม่ทำให้ context window ล้น ส่วนต้นของบทสนทนายกเว้น system prompt จะถูกลบออกเป็นคู่คำถาม-คำตอบเพื่อเปิดพื้นที่
• สถานการณ์นี้ตรวจจับได้ผ่านอีเวนต์ contextoverflow ของเซสชัน
• หากแม้ลบประวัติบทสนทนาแล้วก็ยังไม่สามารถจัดสรรโทเค็นได้เพียงพอ prompt() หรือ promptStreaming() จะล้มเหลวด้วย QuotaExceededError และจะไม่มีการลบอะไรออก
  • requested: จำนวนโทเค็นที่อินพุตใช้
  • contextWindow: จำนวนโทเค็นที่ใช้งานได้
• รายละเอียดเพิ่มเติมดูได้ที่ session management

การโคลนและการปิดเซสชัน

• ใช้ clone() เพื่อคัดลอกเซสชันเดิมและสร้างแขนงบทสนทนาได้
• เซสชันที่โคลนจะคงคอนเท็กซ์เดิมและ initial prompt ไว้
• clone() ก็รับ AbortSignal ผ่านฟิลด์ signal ได้เช่นกัน
• หากไม่ต้องการเซสชันนั้นแล้ว สามารถใช้ destroy() เพื่อคืนทรัพยากรได้
• เมื่อเซสชันถูกทำลายแล้วจะไม่สามารถใช้งานได้อีก และงานที่กำลังรันอยู่ก็จะถูกยกเลิกด้วย
• การสร้างเซสชันอาจใช้เวลา ดังนั้นหากต้องส่งพรอมป์ต์บ่อย การคงเซสชันไว้ใช้อาจเหมาะกว่า

Permission Policy และข้อจำกัดของสภาพแวดล้อมรัน

• โดยปกติ Prompt API ใช้งานได้เฉพาะใน top-level window และ iframe ที่มี origin เดียวกันเท่านั้น
• สำหรับ cross-origin iframe สามารถมอบสิทธิ์เข้าถึงได้ด้วยคุณสมบัติ allow="language-model" ของ Permission Policy
• ตอนนี้ Prompt API ยังใช้ใน Web Workers ไม่ได้
  • เพราะการกำหนดเอกสารที่ต้องรับผิดชอบตรวจสอบสถานะ permissions policy สำหรับแต่ละ worker มีความซับซ้อน

เดโมและเอกสารอ้างอิง

• เดโมเว็บแอปพลิเคชัน
  • Prompt API playground
  • Mediarecorder Audio Prompt
  • Canvas Image Prompt
• ยังมีเดโม extension สำหรับทดสอบ Chrome Extensions ให้ด้วย
  • extension source code

ประสิทธิภาพและฟีดแบ็ก

• Prompt API สำหรับเว็บยังอยู่ระหว่างการพัฒนาอย่างต่อเนื่อง
• เพื่อประสิทธิภาพที่ดีที่สุด ควรอ้างอิงแนวปฏิบัติที่ดีของ session management
• ช่องทางส่งฟีดแบ็กการใช้งาน
  • bug report
  • feature request
  • Prompt API GitHub repository
  • Join the early preview program

[GN⁺]

ความคิดเห็นจาก Hacker News

• API นี้ดูเข้ากับไอเดีย de-snarkifier ที่ฉันคิดมานานพอดี
  โซเชียลมีเดียมีทั้งสิ่งที่กระตุ้นความคิดและเรื่องให้เรียนรู้เยอะก็จริง แต่ก็ทำให้ถูกดูดเข้าไปใน การโต้เถียงทางอุดมการณ์ และสงครามคอมเมนต์ได้ง่ายแม้จะไม่ต้องการก็ตาม การไปทะเลาะกับคนแปลกหน้าบนอินเทอร์เน็ตจนหมดแรงทางอารมณ์ แทบจะเป็นการสิ้นเปลืองทุนมนุษย์
  ถ้ามี API แบบนี้ ก็น่าจะทำเป็นส่วนขยายเบราว์เซอร์ที่ปรับถ้อยคำเฉพาะส่วนที่ก้าวร้าวหรือเหน็บแนมให้นุ่มลงก่อนแสดงโพสต์ โดยคงข้อมูลข้อเท็จจริงไว้เหมือนเดิมได้ และต่อยอดไปถึงขั้นเปลี่ยนโทนที่ก้าวร้าวให้ฟังดูตลกหรือน่าไร้ความสามารถแทนก็ยังได้
  แบบนั้นคนอ่านก็จะได้รับการปกป้องจากการโจมตีส่วนบุคคลของคนแปลกหน้า และคนเขียนเองก็จะหมดแรงจูงใจที่จะหยาบคาย ถ้าทุกคนใช้ตัวกรองแบบนี้ ก็ไม่มีเหตุผลให้แข่งกันว่าใครจะเลวร้ายกว่าใครอีก

  • นี่เหมือน Soylent ของการสื่อสารแบบข้อความเลย
    มีสารอาหารครบ แต่รสชาติไม่มีอะไรพิเศษ
  • ฉันตื่นเต้นกับเครื่องมือแบบนี้มาก มันอาจช่วยกวาด แคลอรีเปล่า ของอินเทอร์เน็ตออกไป จนการใช้งานแพลตฟอร์มยอดนิยมในตอนนี้ลดลงอย่างมากก็ได้
    สิ่งที่ฉันอยากได้คือการลบ พาดหัวคลิกเบต กับโฆษณาออกทั้งหมด แล้วเหลือแค่หัวข้อเชิงข้อเท็จจริงแบบแห้ง ๆ
    ไม่ว่าหัวข้อไหน แค่มีบทความหลักหนึ่งชิ้นกับคอมเมนต์ที่มีสาระไม่กี่อันก็พอแล้ว ที่เหลือส่วนใหญ่เป็นเสียงรบกวนที่ฉันไม่อยากเห็น
    ตอนนี้สภาพโซเชียลมีเดียแย่มากจนฉันแทบไม่ใช้แล้ว และ HN ก็เคยเป็นข้อยกเว้นเดียว แต่ตอนนี้ที่นี่เองก็ดูเหมือนกำลังไปในทางคล้ายกันเพราะ AI ล้นเกิน ถึงอย่างนั้นฉันก็ยังเสียเวลาไปกับมันหลายชั่วโมงทุก ๆ สองสัปดาห์ และอยากตัดสิ่งนั้นออกไปให้หมดด้วย
    ในอุดมคติแล้ว อยากให้มีการกรองหรือสรุปคอนเทนต์ออกไปสัก 98% และเมื่อเวลาผ่านไปก็อยากใช้อินเทอร์เน็ตเฉพาะเวลาที่ตั้งใจค้นหาอะไรเท่านั้น โดยพื้นฐานคืออยากเอา ความเป็นสื่อบันเทิง ของอินเทอร์เน็ตออกไปเกือบทั้งหมด แล้วเอาเวลาและพลังงานกลับไปให้โลกจริงกับแหล่งข้อมูลคุณภาพสูงอย่างหนังสือแทน
  • บน YouTube ก็มีอะไรคล้ายกันอยู่แล้ว และฉันใช้ DeArrow อยู่
    ส่วนขยายนี้เป็นเครื่องมือแบบคราวด์ซอร์สที่พยายามลดความหวือหวาเกินจริง และฉันก็แอบคิดว่าผู้มีส่วนร่วมระดับบนบางคนอาจเป็นบอต LLM
  • เป็นไอเดียที่น่าสนใจและดูคุ้มค่าที่จะลองสำรวจ
    เพียงแต่ของแบบนี้พอชนกับโลกจริงแล้วมักคาดเดาไม่ได้ และถึงจะออกมาดี มันก็มักจะทำงานต่างจากที่จินตนาการไว้ตอนแรกพอสมควร
  • ฉันเป็น PM ของ built-in AI APIs ใน Chrome และชอบไอเดีย de-snarkifier นี้มาก ดูเหมือนจะมีความสนใจในวงกว้างด้วย
    ฉันเลยอดไม่ได้ที่จะรีบทำต้นแบบ Snarknada ขึ้นมาคร่าว ๆ พร้อมสำรวจทั้งแพตเทิร์นหน่วงต่ำและความเป็นไปได้ด้านความแม่นยำ
    นี่แหละคือเหตุผลที่ฉันมองว่า on-device เหมาะกับงานใช้ลักษณะนี้ ถ้าจะทำให้ฟีดเลื่อนแบบไม่สิ้นสุดทั้งฟีดนุ่มลงด้วย cloud API ต้นทุนโทเคนจะสูงจนฝั่งนักพัฒนารับไม่ไหว อีกอย่างก็เป็นเรื่องธรรมดาที่คนจะไม่อยากส่งฟีดส่วนตัวหรือ DM ไปให้เซิร์ฟเวอร์ของบุคคลที่สามเพื่อจัดโทนข้อความ
    ถ้าย้ายสิ่งนี้มาไว้ในเครื่อง การทำ Semantic Mutation ความถี่สูงก็อาจเป็นจริงได้เป็นครั้งแรกทั้งในแง่ต้นทุนและเทคนิค ถ้ามีใครทำอะไรที่จริงจังกว่าต้นแบบ PM เล่น ๆ ของฉัน แล้วเจอจุดฝืดที่ชัดเจน อยากให้มาบอกกันมาก เพราะมันช่วยในการจัดลำดับความสำคัญของโรดแมปได้
    [1]: ถ้าคุณใช้ coding agent (เช่น Cursor, Claude Code ฯลฯ) แนะนำให้ชี้ไปที่ https://www.npmjs.com/package/built-in-ai-skills-md-agent-md เพราะหลายโมเดลยังถูกฝึกมาจาก namespace window.ai แบบเก่าที่ล้าสมัยแล้ว และไฟล์สกิลนี้จะช่วยให้ใช้งาน API ปัจจุบันได้อย่างถูกต้อง

• ฉันเป็นคนขับเคลื่อนงานออกแบบ API นี้ และก่อนเกษียณก็ได้เขียนสรุป ข้อพิจารณาด้านการออกแบบ ที่เกี่ยวข้องไว้ด้วย
  https://domenic.me/builtin-ai-api-design/

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

• อันนี้ใช้งานได้จริง และฉันก็ปล่อยใช้ไปแล้วสำหรับ local inference
  มันใช้แทน ollama แบบคนงบน้อยได้ประมาณหนึ่งสำหรับงาน LLM เบา ๆ อย่างการค้นหา ข้อดีใหญ่สุดคือ ฟรี รักษาความเป็นส่วนตัว และแทบไม่ต้องให้ผู้ใช้ทำอะไรเลย จึงเหมาะกับการเอา local inference ไปให้ผู้ใช้ที่ไม่ใช่สายเทคนิค
  แต่ประสบการณ์ใช้งานจริงยังไม่ดีนัก ขนาดดาวน์โหลดโมเดลใหญ่กว่าเบราว์เซอร์เองหลายหลัก และต้องผ่านขั้นตอนนั้นให้เสร็จก่อนถึงจะได้โทเคนแรก
  ดูเหมือนว่าสิ่งนี้จะแก้ยาก จนกว่าระบบปฏิบัติการจะมีโมเดลที่ฝังมาให้ล่วงหน้าอย่างสม่ำเสมอ และ API แบบนี้จะเชื่อมต่อเข้ากับมันได้

  • นี่เป็นการดาวน์โหลดครั้งเดียวที่ทุกเว็บไซต์ซึ่งใช้ Prompt API แชร์ร่วมกัน
    ปัญหาใหญ่กว่าคือบนพีซีทั่วไปส่วนใหญ่ โมเดลยังเล็กเกินไปและช้าเกินไป ฉันเคยลองเอาไปใช้เปลี่ยนประโยคใน infocom text adventure แบบเรียลไทม์ แต่ตอนนี้บนพีซีจำนวนมากมันช้าเกินกว่าจะใช้งานได้จริง
  • กระแสใหญ่รอบถัดไปอาจเป็นซอฟต์แวร์สมัครสมาชิกแบบพรีเมียมที่ขายพร้อม 5090 หลายใบ ก็ได้
  • ถ้าเป็น MoE model ก็อาจดึงเฉพาะ expert layer ที่ต้องใช้มาจากเครือข่ายผ่าน HTTP range query ได้เมื่อจำเป็น
    คล้ายกับที่ bittorrent รับชิ้นส่วนไฟล์จากหลายโฮสต์ ชั้นที่ใช้ร่วมกันยังคงต้องโหลดอยู่ แต่เวลาจนถึงโทเคนแรกอาจทำให้แปรผันตาม active size มากกว่าขนาดรวมได้
    แน่นอนว่าแบบนั้นจะไม่ใช่ offline inference แบบสมบูรณ์ แต่ถ้าเป็นฟีเจอร์เว็บในเบราว์เซอร์ นั่นอาจไม่ใช่ประเด็นหลักนัก
  • หวังว่าเราจะไม่ไปถึงโลกที่ระบบปฏิบัติการ บันเดิลโมเดลมาให้ล่วงหน้า แบบเสถียร
  • ดีมากเลย
    แต่อยากรู้ว่าถ้าโมเดลใหญ่กว่าเบราว์เซอร์มากและต้องดาวน์โหลดก่อนถึงโทเคนแรก นี่หมายความว่าเป็น การดาวน์โหลดแบบหน่วงเวลา ใช่ไหม ถ้าแปลว่าผู้ใช้ที่เรียกใช้ครั้งแรกต้องรอจนดาวน์โหลดเสร็จในตอนนั้นเลย ประสบการณ์ใช้งานก็ดูน่ากลัวพอควร
    เลยสงสัยว่า Chrome แสดงอะไรอย่างกล่องสถานะการดาวน์โหลดเพื่อลดความสับสนหรือไม่ และใช้พื้นที่ดิสก์ประมาณเท่าไร

• ดูเผิน ๆ เหมือนนี่ใช้ Gemini Nano แต่ Gemma 4 E2B/E4B รุ่นล่าสุดดูดีกว่ามาก ดังนั้นในระยะสั้นอาจดีกว่าถ้าจะปล่อยเวอร์ชัน quantized ผ่านส่วนขยายแทน

  • Gemini Nano-1: 46% MMLU, 1.8B
  • Gemini Nano-2: 56% MMLU, 3.25B
  • Gemma4 E2B: 60.0% MMLU, 2.3B
  • Gemma4 E4B: 69.4% MMLU, 4.5B
    แหล่งที่มา:
  • https://huggingface.co/google/gemma-4-E2B-it
  • https://android-developers.googleblog.com/2024/10/gemini-nano-experimental-access-available-on-android.html
  • ตอนนี้ฉันไม่รู้สถานการณ์ภายใน แต่สมัยที่ฉันอยู่ทีมนี้ เราเอา โมเดล Google ขนาดเล็กรุ่นล่าสุด เข้า Chrome กันเร็วมาก
    ถ้า Gemma 4 หรือ Gemini Nano ที่เทียบระดับกันยังไม่อยู่ใน Chrome ก็คาดว่าน่าจะเข้ามาเร็ว ๆ นี้
    และโพสต์นี้อัปเดตล่าสุดเมื่อ 2025-09-21 ซึ่งตอนนั้นเป็น Gemini Nano 3 ไปแล้ว
  • ใช่
    เขียนไว้ว่าตัว Prompt API คือการส่งคำขอภาษาธรรมชาติไปยัง Gemini Nano ที่อยู่ในเบราว์เซอร์
  • Prompt API ใช้โมเดลที่มีให้ใช้งานในเบราว์เซอร์
    บน Edge ก็น่าจะเป็น Phi4

• นี่ก็ดูเหมือนจะเป็นวิธีที่ดีให้ สคริปต์ JS อันตรายโยนภาระการสร้างโทเคนไปให้ผู้เข้าชมที่ไม่รู้อิโหน่อิเหน่
  น่าสนใจเหมือนกันว่ามันจะกระจายงานได้ไหม เช่น แยกพรอมป์ขนาดใหญ่ออกเป็นส่วนเล็ก ๆ แล้วส่งไปหลายเบราว์เซอร์ ให้แต่ละตัวประมวลผลชิ้นเล็ก ๆ ในรูปแบบ subagent pattern หรือโครงสร้างคล้าย RLM เพื่อรวมเป็นผลลัพธ์ที่มีประโยชน์

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

• นี่ดูเหมือนก้าวหนึ่งไปสู่ Model API ที่สมบูรณ์ แต่ตอนนี้ยังเป็นเพียงก้าวเล็ก ๆ
  มันทำให้นึกถึง Foundation Models ของ Apple ด้วย
  การผสาน AI จำนวนมากเน้นไปที่การสื่อสารด้วยข้อความหรือสไตล์แชต แต่จริง ๆ แล้วก็มีซอฟต์แวร์จำนวนมากที่ได้ประโยชน์จากอินเทอร์เฟซที่ไม่ใช่ข้อความ
  สุดท้ายแล้ว ฉันคิดว่า OS และเบราว์เซอร์ควรให้ API สำหรับจัดการโมเดล เพื่อให้แอปเข้าถึงทั้งโมเดล on-device และโมเดลระยะไกลผ่านอินเทอร์เฟซง่าย ๆ ได้
  ถ้าสิ่งนี้ถูกทำให้เป็นมาตรฐานข้ามแพลตฟอร์มได้ก็คงดีมาก และเพราะต้องครอบคลุมถึงมือถือด้วย ฝ่ายที่มีโอกาสผลักดันได้จริงก็น่าจะเป็น Apple กับ Google เป็นหลัก Meta อาจตามมาทีหลังหรืออาจขยับก่อนก็ได้
  ประเด็นสำคัญคือมันไม่ควรเป็น API ที่ผูกกับโมเดลประชาสัมพันธ์ตัวใดตัวหนึ่ง
  แอปควรสอบถามแล้วเลือกใช้โมเดลที่เหมาะสมได้
  (1) https://developer.apple.com/documentation/foundationmodels

  • Foundation Models ของ Apple ดูดีในเอกสารก็จริง แต่พอดูจริงแล้วติดที่ context window 4k
    แน่นอนว่าตอนนี้ก็ยังอยู่ช่วงเริ่มต้น

• https://github.com/mozilla/standards-positions/issues/1067

  • อันนี้ก็น่าดูเช่นกัน: https://github.com/mozilla/standards-positions/issues/1213

• เราใช้สิ่งนี้สำหรับ สรุปย้อนดูงาน hackday
  https://remotehack.space/previous-hacks/
  มันเป็นสคริปต์เล็ก ๆ ที่อ่าน RSS feed แล้วสร้างสรุปจากเนื้อหาเต็ม ซึ่งเข้ากับเว็บไซต์แบบ static ได้ค่อนข้างดี และสักวันก็อยากขยายให้มันตั้งคำถามอื่น ๆ กับคอนเทนต์เดียวกันได้ด้วย

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

  • ปัญหา การแตกกระจายของการทดสอบ นี่แหละคือประเด็นหลักจริง ๆ
    ในทางปฏิบัติพรอมป์ไม่ได้เป็นกลางต่อโมเดล ดังนั้นพรอมป์ที่จูนอย่างละเอียดให้เข้ากับ Gemini Nano 3 v2025 อาจประสิทธิภาพตกเงียบ ๆ บนโมเดลฝั่ง Gecko ก็ได้ แต่ API กลับไม่มีแม้แต่การ ตรวจสอบความสามารถ ให้แตกแขนงการทำงาน
    อย่างน้อย WebGL ยังเปิดให้ query การรองรับส่วนขยายได้ แต่นี่แย่กว่านั้นอีก การออกฟีเจอร์โดยพึ่งคุณภาพพรอมป์ของโมเดลที่ทั้งชื่อและเวอร์ชันถูกซ่อนไว้หลังเบราว์เซอร์ ก็คล้ายกับการปล่อยซอฟต์แวร์ที่การทำงานขึ้นอยู่กับพจนานุกรมที่ผู้ใช้ติดตั้งไว้

• ฉันเข้าใจว่า Gemini Nano ไม่ได้เป็น open weights แบบ Gemma ใช่ไหม
  ถ้าไม่มีใครทำไปแล้ว ก็อยากลอง dump ค่าน้ำหนักโมเดลดู