Chrome Prompt API

• API แบบเนทีฟของเบราว์เซอร์สำหรับส่งคำขอภาษาธรรมชาติไปยังโมเดล Gemini Nano ที่ฝังอยู่ใน Chrome และทำ การอนุมาน AI แบบออนดีไวซ์ ได้โดยไม่ต้องส่งข้อมูลไป-กลับกับเซิร์ฟเวอร์
• นำไปใช้ได้หลากหลาย เช่น การค้นหาที่ขับเคลื่อนด้วย AI, ฟีดแบบปรับแต่งผ่านการจัดหมวดหมู่ข่าว, การกรองคอนเทนต์, การสร้างตารางนัดหมายในปฏิทิน, การดึงข้อมูลรายชื่อติดต่อ
• เลือกได้ว่าจะรับ คำตอบครั้งเดียว ผ่าน prompt() หรือ คำตอบแบบสตรีมมิง บนพื้นฐาน ReadableStream ผ่าน promptStreaming()
• มี ความสามารถควบคุมเซสชันอย่างละเอียด เช่น การจัดการคอนเท็กซ์แบบอิงเซสชัน, คำตอบแบบสตรีมมิง, การโคลนเซสชัน
• การอนุมาน AI เกิดขึ้นภายในเบราว์เซอร์โดยไม่ต้องส่งข้อมูลไป-กลับกับเซิร์ฟเวอร์ จึงได้เปรียบด้าน ความเป็นส่วนตัวและการลดความหน่วงของการตอบสนอง
• มีความสามารถมัลติโหมดในตัว รองรับ อินพุตภาพและเสียง นอกเหนือจากข้อความ
  • เสียง: AudioBuffer, ArrayBuffer, Blob เป็นต้น
  • ภาพ: HTMLImageElement, HTMLCanvasElement, VideoFrame, Blob เป็นต้น
• สามารถส่ง JSON schema ในฟิลด์ responseConstraint เพื่อจำกัดรูปแบบผลลัพธ์ของโมเดลให้เป็น boolean หรือโครงสร้าง JSON ที่กำหนดได้
• ใช้ initialPrompts เพื่อใส่ system prompt และคอนเท็กซ์ของบทสนทนาก่อนหน้า และใช้ append() เพื่อ ส่งคอนเท็กซ์เพิ่มเติมล่วงหน้า ได้แม้สร้างเซสชันแล้ว
• หากเพิ่ม prefix: true ในข้อความ assistant ที่ตามมา ก็สามารถชี้นำให้โมเดล เริ่มตอบในรูปแบบที่กำหนด ได้
• รองรับการจัดการ context window รายเซสชัน: ตรวจสอบการใช้โทเค็นได้ด้วย contextUsage/contextWindow และเมื่อล้นจะลบบทสนทนาเริ่มต้นโดยอัตโนมัติ (แต่ยังคง system prompt ไว้)
• ใช้ clone() เพื่อแตกเซสชัน, destroy() เพื่อคืนทรัพยากร, และ AbortSignal เพื่อ ยกเลิกเซสชันหรือพรอมป์ตกลางคัน ได้
• ใช้ expectedInputs/expectedOutputs เพื่อกำหนดรูปแบบอินพุต/เอาต์พุตและภาษาได้ (ปัจจุบันรองรับ en, ja, es)
• ความต้องการด้านฮาร์ดแวร์: Windows 10+/macOS 13+/Linux/ChromeOS, พื้นที่เก็บข้อมูลอย่างน้อย 22GB, GPU VRAM มากกว่า 4GB หรือ CPU RAM อย่างน้อย 16GB + คอร์อย่างน้อย 4 คอร์
• สำหรับ iframe ข้าม Origin สามารถมอบสิทธิ์การเข้าถึงได้ด้วยแอตทริบิวต์ allow="language-model" และ ขณะนี้ยังไม่รองรับบนเว็บเวิร์กเกอร์
• เปิดให้ใช้งานในรูปแบบ Origin Trial ตั้งแต่ Chrome 138

[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 ค่าน้ำหนักโมเดลดู