TLDR
- สร้างแชทบอทที่ทำงาน 100% บนเบราว์เซอร์ของผู้ใช้ ไม่ต้องมีเซิร์ฟเวอร์
-ใช้ Transformers.js เพื่อรันโมเดล AI สำหรับแปลงข้อความเป็น Vector (Embeddings) ในฝั่ง Client
- ข้อมูลผู้ใช้เป็นส่วนตัวทั้งหมดเพราะไม่ได้ส่งไปไหน และตอบสนองได้ทันทีเพราะไม่มี Latency ของเน็ตเวิร์ค
-ใช้เทคนิคคล้าย RAG (Retrieval-Augmented Generation) โดยดึงข้อมูลจาก Knowledge Base ในเครื่องมาช่วยให้ AI ตอบได้แม่นยำขึ้น

ช่วงนี้ ผมอินกับ On-Device / AI Built In มาก งาน Google IO Extended ผมก็พูดเรื่องนี้ คราวนี้ก็เลยมาคิดว่า ปกติแล้วพวก AI ที่เป็น Server เนี่ยเค้าทำอะไรได้บ้างนะ แล้วมันจะเอามาทำบน Browser แทนได้มั้ยนะ ก็เลยคิดว่า เออมันมี chatbot นี่..ที่น่าจะใช้แค่ embeding model แล้วก็ Prompt API ก็น่าจะจบเลยนี่ ก็เลยลองเขียน code ออกมาเป็นแบบ prototype ดูว่าถ้าเราทำ chatbot แบบ LLM Based มันจะทำได้มั้ย แล้วถ้าจะทำต้องทำยังไง

AI ส่วนตัวที่ไม่ต้องง้อเซิร์ฟเวอร์

ก่อนอื่นเลยหลายๆคนอาจจะสงสัยว่าจะใช้ On-device AI ไปทำไม แล้ว On-device AI มันดียังไง ไอเดียหลักของโปรเจกต์นี้คือการสร้างแชทบอทที่ทำงานได้ด้วยตัวเองทั้งหมดบนอุปกรณ์ของ User โดยไม่ต้องพึ่งพาเซิร์ฟเวอร์เลย ซึ่งพอเราทำแบบนี้ได้ เราก็ได้ข้อดีมาเต็มๆ คือ

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

ซึ่งหลักการทำงานของ Project นี้มันคือการดึงข้อมูลที่เกี่ยวข้องที่สุดจากชุดความรู้ (Knowledge Base) ที่เราเตรียมไว้ แล้วส่งให้ AI ช่วยเรียบเรียงเป็นคำตอบอีกทีหนึ่ง เหมือนการทำ RAG ทั่วๆไปแหละแค่ทำให้มันจบ บน browser

มันทำได้อย่างไร?

เพื่อให้เห็นภาพมากขึ้น ผมจะแยกการทำงานออกมาเป็น 4 ขั้นตอนหลักๆ ที่เกิดขึ้นทั้งหมดในเบราว์เซอร์ครับ

1. แปลง Knowladge เป็น Vector: ต้องบอกว่าขั้นตอนนี้ตอนแรกผมก็อยากที่จะจบด้วย built-in AI นั่นแหละแต่ตัว model ที่มีมาไม่ไม่ support Embedding ก็เลยต้องไปไล่หา model Embedding ที่เอามาใช้บน browser ได้ ซึ่ง size กลายเป็นเรื่องที่ผมกังวลมากๆเพราะว่า ถ้า model ใหญ่เกินไป ความดูเป็นไปได้ของ project นี้จะล้มเลย คราวนี้พอ research ไปๆมาๆก็ไปเจอ Model all-MiniLM-L6-v2 ที่ Support Transformer.js และขนาดน่ารักมากๆแค่ 20MB เองซึ่งพอทำงานจริงๆก็โหลดไม่กี่วินาทีก็เสร็จ คราวนี้ผมก็เอา JSON ของ FAQ ที่ mock เอาไว้ มาแปลงเป็น vector แล้วก็ยัดลงไปใน LocalStorage จริงๆพยายามหา localDB ที่ support vector ไม่เจอ ก็เลย save มันไปแบบโง่ๆแบบนี้แหละ สุดท้ายถ้าจะทำจริงๆคงต้อง implement index-db ที่ suport vector ขึ้นมา (จริงแล้วมีนะ แต่ไม่มีใคร maintain มานานแล้วผมเลยข้ามไป https://github.com/PaulKinlan/idb-vector)

2. คราวนี้เมื่อผู้ใช้พิมพ์คำถามเข้ามา ผมใช้ไลบรารี Transformers.js เพื่อโหลดโมเดล all-MiniLM-L6-v2 (เหมือน process เดิมที่โหลด FAQ )ขึ้นมาทำงานในเบราว์เซอร์ โมเดลนี้จะแปลงประโยคคำถามให้กลายเป็นชุดตัวเลข (Vector) ที่สื่อถึงความหมายของประโยคนั้นๆ คราวนี้พอเราได้ vector เราก็เอาไปหา cosine similarity กับ doc ที่เก็บใน LocalStorage แล้วก็เอา top 10 ที่มี Similarity สูงที่สุดมา สำหรับ function cosineSimilarity ผมก็ search หาทั่วๆไปเลยครับใครจะใช้ Lib ก็ได้นะ

3. ประกอบร่าง Prompt: แทนที่จะโยนคำถามดิบๆ ไปให้ AI, ผมเอา “ข้อมูลที่เกี่ยวข้อง” ที่หาเจอในข้อ 2 มาประกอบเข้าไปใน Prompt ด้วย วิธีนี้ทำให้ AI มีบริบทและข้อมูลที่ถูกต้องสำหรับใช้ในการสร้างคำตอบ ผมยัด intial prompt เข้าไปด้วยเพื่อให้ตัวมันเข้าใจมากขึ้น

4. สร้างคำตอบด้วย Prompt API: สุดท้าย ผมส่ง Prompt ที่สมบูรณ์แล้วไปให้ Prompt API ซึ่งเป็น Built-in AI ของ Chrome / Edge ช่วยสร้างคำตอบที่สอดคล้องกับข้อมูลที่เราป้อนให้ หน้าตาของโค้ดตอนเรียกใช้ Prompt API ก็จะประมาณนี้ครับ:

ข้อจำกัด

• ขอบเขตความรู้: แชทบอทจะรู้แค่เรื่องที่มีอยู่ในฐานข้อมูลที่เราเตรียมไว้ให้เท่านั้น ไม่สามารถตอบเรื่องอื่นๆ นอกเหนือจากนี้ได้เพราะตัว model ที่รันอยู่ข้างหลังเล็กมากๆ
• ⚠️⚠️⚠️ Browser Compatibility: ตอนนี้ฟีเจอร์หลักยังต้องพึ่งพา Prompt API ซึ่งเป็นฟีเจอร์ทดลองยังใช้ไม่ได้บนเว็บต้องเปิด Flag หรือรันบน origin trial และยังมีแค่บน Chrome และ Microsoft Edge ถ้าใครอยากลองก็ให้ไปเปิด feature flag ก่อน
  chrome://flags/#prompt-api-for-gemini-nano
  edge://flags/#edge-llm-prompt-api-for-phi-mini
• ทรัพยากรเครื่อง: ตอนนี้ฟีเจอร์ Built-in AI ยังรองรับแค่บน Desktop ที่มี RAM 4 GB และมีพื้นที่ว่าง 22 GB ขึ้นไปได้เท่านั้น

ยังไม่สุดเลยขออัดต่อ

พอทำๆไปก็มาคิดว่า ถ้าไม่มี Prompt API หละ จะทำยังไง ก็เลยคิดถึงบทความก่อนที่เราเอา Gemma 3 1B มารันบน Browser ก็เลยคิดว่า ลองเอาสองงานมารวมกันดู ก็เลยลองเขียน code แบบเดียวกับบทความก่อนเพื่อรัน Gemma 3 1B ดู

สิ่งที่เจอไม่ค่อยประทับใจเท่าไหร่ เพราะ model ต่อให้เล็กขนาดไหน ก็ยังกินเนื้อที่ 500MB อยู่ดี ไม่พอ model ขนาด 1B เทียบไม่ได้เยก็ Prompt API เพราะว่า model ที่เป็น prompt API ถ้าจำไม่ผิด คือ Gemma E4B ที่ขนาดใหญ่กว่าเยอะมากๆ แต่ถ้าถามว่าพอใช้ได้มั้ย ก็ตอบว่า พอใช้ได้อยู่

สรุป

ถ้าถามว่าพอจะทำ Chatbot บน browser ได้แล้วมั้ย ก็ตอบว่าพอทำได้แหละ อาจจะเป็น Chatbot ง่ายๆหรืออาจจะเป็นพวก Fix response ก็พอไหวอยู่ แต่ถ้าทำแบบ Gemerative 100% อาจจะต้องจัดการเรื่อง local DB หรือ เรื่อง context window ให้ดีพอ ยังไม่รวมพวก เรื่อง browser compatibility ด้วย เอาจริงๆแล้ว วิธีนี้อาจจะเอาไปใช้กับ Application ที่เป็น app android หรือ ios ด้วยก็ได้ไม่จำเป็นต้องทำบนเว็บอย่างเดียว

ถ้าใครอยากดู code ที่ผมสร้างเอาไว้ก็ไปดูที่ Github https://github.com/thangman22/ondevice-chatbot ได้เลยแต่อย่าคาดหวังว่ามันจะดีมากนะ ฮ่าๆ

TLDR:
- Chrome now includes 6 high-level functions for calling Gemini Nano: Translator, Language Detector, Summarizer, Writer/Rewriter, Proofreader, and Prompt APIs.
- Some are available in Chrome 138 stable, with the Prompt API initially for Extensions.
- Microsoft Edge is also introducing similar on-device AI features.

Several months ago, Google launched Built-in AI in Chrome, enabling developers to access the in-browser model via JavaScript functions. Back then, we could only use prompts. However, over time, Google shifted its approach from solely providing prompts to offering more ready-to-use functions. Today, let’s explore what these ready-to-use functions are. The benefit of Built-in AI is that we don’t have to incur costs by directly calling the Gemini API every time, and simple tasks can be completed directly in the browser on the frontend.

Translator API

This Translator API helps us avoid the need to manually call a Cloud API for language translation because we can call it directly from the browser. However, we first need to check if our language pair is supported. This feature is a relief for web developers who need to support multiple languages, as previously, implementing such a feature required considering how to manage cloud costs.

Language Detector API

Besides being able to translate languages, we can also detect languages. Sometimes, we need this to check which API to call or to detect the language that needs to be translated in subsequent processes. Normally, we would have to implement this with an API or use a paid service.

Summarizer API

Coming to another API that I like, the Summarizer API. This API helps us transform long articles into simple summaries. In the options, we can specify the desired summary style: TLDR, teaser, key points, or headline. For all of these, we can define the length and also specify whether we want the output as Markdown or plain text.

If you ask what the results are like, I tried using it to summarize an article from this website, and this is roughly what it came out with. It’s quite usable for creating a TLDR feature on various websites or for summarizing long articles to be used in a chatbot to converse with users.

* Meta is actively developing and testing an official Instagram app for iPad, with a release expected this year.
* The delay in releasing an iPad-optimized Instagram app was partly due to technical limitations and perceived petty reasons.
* The decision to develop the iPad app comes as Instagram's user base has grown, the device has become more powerful, and the platform's use cases have evolved.

For these 3 APIs, we will be able to use them on Chrome version 138, both in Extensions and via Web APIs.

Writer / Rewriter API

These two APIs have quite similar functions: the Writer API helps us write articles or emails from a prompt, while the Re-writer API is used when we already have an email or article but want the AI to help change the writing style a bit. These two APIs are used almost 100% identically; the only difference is the function name.

From trying it out, the AI helps rewrite quite well. Plus, if we specify that it should be written as an email, it comes out in a very good email format.

These two APIs are currently in an Origin Trial status, so anyone who wants to use them can go register first. However, it’s thought that they will likely arrive in Chrome 142 at the earliest.

What’s interesting is that Microsoft itself has also embedded its own model, like Phi, into Microsoft Edge. This allows Microsoft Edge to use Summarizer API and Writer/Rewriter API functionalities just like Google Chrome. Importantly, the API interface is 100% identical.

Proofreader API

Regarding this API, it must be said that there’s very little information available (“it’s very empty”). There was a demo in one of the Google I/O sessions, but not many details have been released yet. However, from what I understand, this API will help tell us which word is misspelled by providing the text’s position, allowing us to highlight it ourselves. But one can guess that the API interface probably won’t be much different from the others. It will likely be available for us to try in Chrome 140 by enabling flags.

Prompt API

Okay, here’s the English translation of those two paragraphs:

Coming to the last one, this API is a normal prompt API where we can write anything, just like writing normal prompts for LLMs (Large Language Models). This feature has been available since the very first day of Built-in AI, but there have been many developments and improvements since 2024.

The current API interface looks more standard and is much easier to write/use (after having been changed three times).

In this version, the prompt API supports multimodal input, including both audio and images. We can send prompts with more than just text.

The output structure can be defined to be JSON or a Specific Type to make programming easier for us.
https://developer.chrome.com/docs/ai/structured-output-for-prompt-api

It’s clear that the built-in API is now becoming quite similar to the Cloud API. This doesn’t even include Stream output, which has been supported from the beginning. It probably won’t be long before we see Built-in AI performing on par with Cloud APIs. However, it’s a bit unfortunate that for now, the Prompt API will initially only be supported on Chrome extensions. If you want to use it on the web, you must enable a flag in the browser.

But another piece of good news about the Prompt API is that Microsoft has decided to adopt it as well, with a 100% identical API interface. In the future, even if using different browsers, there will be no need to worry about compatibility anymore.

Summary

It’s evident that the standards for all these functions are now aligning for both Chrome and Edge. I believe that in the future, even if each provider develops their own models, they probably won’t deviate much from this current direction. Essentially, the main workflow involves first calling an “availability” method to check if a model exists and if it needs to be downloaded. If a download is completed, you then call a “create” method. The specific methods for each function will then differ slightly.

The question on everyone’s mind likely concerns device requirements. It must be said that currently, this feature is only supported on desktops with at least 4GB of RAM and 22GB of available storage. We’ll have to see if a new, smaller version of Gemini Nano will be released. If one does become available, I think it could easily be incorporated into mobile devices or machines with lower specifications.

As for whether anyone is using this in production yet, the answer is “not yet.” We’ll likely have to wait a while longer before we see widespread actual implementation.

Reference

• https://developer.chrome.com/docs/ai/get-started
• https://learn.microsoft.com/en-us/microsoft-edge/web-platform/prompt-api
• https://learn.microsoft.com/en-us/microsoft-edge/web-platform/writing-assistance-apis

Playground

• https://chrome.dev/web-ai-demos/writer-rewriter-api-playground/
• https://chrome.dev/web-ai-demos/translation-language-detection-api-playground/
• https://chrome.dev/web-ai-demos/summarization-api-playground/

TLDR

วันนี้ Chrome ยัด highlevel function สำหรับเรียก Gemini nano มาแล้ว 6 ตัว Translator API, Language Detector API, Summarizer API, Writer / Rewriter API, Proofreader API, Prompt API

บางตัวจะเริ่มใช้ได้ตั้งแต่ Chrome 138 ส่วน Prompt API ใช้ได้บน Extension ก่อน

Microsoft Edge เอาด้วย function หน้าตาเหมือนกันเลย

จากหลายเดือนก่อนที่ Google เปิดตัว Built-in AI มาใน chrome ที่ทำให้นักพัฒนาสามารถเข้าถึงตัว model ที่อยู่ใน Browser ผ่าน function ใน Javascript ได้ ในวันนั้น เราเรียกใช้ได้แค่ตัว prompt แต่พอเวลาผ่านไป Google ก็เปลี่ยน แนวทางแทนที่จะ provide เป็น prompt อย่างเดียวก็เปลี่ยนเป็น ready to use function มากขึ้น วันนี้เรามาดูกันดีกว่าว่า ready to use function ที่ผมว่ามีอะไรบ้าง ซึ่งประโยชน์ของ Built-in AI คือ การที่เราไม่ต้องมานั่งเสียเงิน call ไปหา Gemini API ตรงๆทุกครั้งและยังสามารถทำงานง่ายๆจบได้ที่ browser ฝั่ง frontend ได้เลย

Translator API

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

Language Detector API

นอกจากจะแปลภาษาได้แล้ว เรายัง detect ภาษาได้ด้วยซึ่งบางทีเราต้องเอาไปเช็ค api ที่ต้องยิง หรือ ต้องเอามา detect ภาษาที่จะต้องเอาไปแปลใน process ต่อๆไป ซึ่งปกติแล้วเราต้อง implement สิ่งๆนี้ด้วย API หรือไม่ก็ต้องไปใช้ service ที่เสียเงิน

Summarizer API

มาถึง API ที่ผมชอบอีกตัวนึงคือ Summarizer API เพราะ API ตัวนี้จะช่วยให้เราแปลง บทความยาวๆเป็นสรุปง่ายๆ ซึ่งใน option เราสามารถกำหฟนดได้ว่าอยากได้ สรุป style ไหน tldr, teaser, key-points หรือ headline ซึ่งทั้งหมดนี้เราสามารถกำหนดความยาวได้หมดเลย และบอกได้ด้วยว่าอยากได้เป็น markdown หรือ pain text

ถ้าถามว่า result ออกมาประมาณไหน ผมลองเอาบทความในเว็บนี้ไป ให้สรุปดู ฏ็ได้ออกมาประมาณนี้ ซึ่งก็พอจะใช้ได้อยู่สำหรับทำ feature TLDR บนเว็บไซต์ต่างๆ ได้ หรือใช้สรุปบทความยาวๆเป็น chatbot ไว้คุยกับ user ได้

* Meta is actively developing and testing an official Instagram app for iPad, with a release expected this year.
* The delay in releasing an iPad-optimized Instagram app was partly due to technical limitations and perceived petty reasons.
* The decision to develop the iPad app comes as Instagram's user base has grown, the device has become more powerful, and the platform's use cases have evolved.

สำหรับ 3 API นี้เราจะได้ใช้กันบน Chrome version 138 ทั้งบน Extension และ บน Web API

Writer / Rewriter API

API สองตัวนี้จะช่วงงานที่คล้ายๆกันคือ ตัว Writer จะช่วยให้เราสามารถเขียน บทความหรืออีเมลจาก prompt ได้ ส่วน re-writer จะ ใช้ในกรณีที่ เรามีอีเมลหรือบทความอยู่แล้วแต่อยากให้ AI ช่วยเปลี่ยน แนวทางการเขียนให้ใหม่หน่อย API สองตัวนี้ใช้เหมือนกันแทบจะ 100% ต่างกันแค่ชื่อ function เท่านั้นเอง

จากที่ลองตัว AI ก็ช่วย Rewrite ออกมาดีในระดับนึงเลย บวกกับถ้าเราบอกว่าใครเขียนเป็น email ก็มาเป็นรูปแบบ Email อย่างดีเลย

API สองตัวนี้ตอนนี้อยู่ในสถานะ Origin trial แล้วซึ่งใครอยากใช้ก็ไป register กันก่อนได้ แต่คิดว่าน่าจะมาใน Chrome 142 เป็นอย่างเร็ว

ที่น่าสนใจคือ ฝั่ง Microsoft เองก็ได้ฝั่ง Model ที่ทำเอง อย่าง Phi เข้าไปใน Microsoft Edge ซึ่งทำให้ตัว Microsoft Edge สามารถใช้งาน Summarizer API และ Writer / Rewriter API ได้เหมือน Google Chrome ที่สำคัญ API หน้าตาเหมือนกัน 100%

Proofreader API

API ตัวนี้ต้องบอกว่าว่างเปล่ามากๆ มีการ Demo ใน session นึงของ Google IO แต่ยังไม่ได้มี Detail อะไรออกมามาก แต่เท่าที่เข้าใจคือ API ตัวนี้จะช่วยบอกเราว่าคำไหน พิมพ์ผิด โดยบอกเป็น positon ของ text ออกมาให้เราเอาไป highlight เอง แต่เดาได้ว่าหน้าตา API ก็คงไม่พ้น ตัวอื่นๆ ซึ่งคงออกมาให้เราลอง ตอน Chrome 140 ด้วยการเปิด flags

Prompt API

มาถึงตัวสุดท้าย API นี้เป็น API ที่เป็น prompt ปกติเลยที่เราเขียนอะไรก็ได้ เหมือนการเขียน prompt ปกติของพวก LLM ซึ่ง feature นี้มีมาตั้งแต่วันแรกเลยของ Built-in AI แต่มีสิ่งที่พัฒนามาจากตอนปี 2024 อยู่หลายอย่างมากๆ

• หน้าตา API ที่เป็นไป ดูเป็น standard มากขึ้น และเขียนง่ายมากขึ้น (หลังจากเปลี่ยนมา 3 รอบ)

• ใน version นี้ ตัว prompt API Support Multi Modal ทั้งเสียงแล้วก็รูปภาพเราสามารถส่ง prompt ได้มากว่า text

• กำหนด structure output ได้ให้ออกมาเป็น JSON หรือ Specific Type เพื่อทำให้เราเขียน โปรแกรมได้ง่ายขึ้น https://developer.chrome.com/docs/ai/structured-output-for-prompt-api

จะเห็นได้ว่า ตอนนี้ตัว API ของตัว built-in ค่อนข้างใกล้เคียงกับตัว Cloud มากขึ้นแล้ว นี่ยังไม่รวม Stream output ที่ support ตั้งแต่แรก คงอีกไม่นานแล้วที่จะเห็น Built-in AI ทำงานได้ไม่แพ้ตัว Cloud API แต่น่าเสียดายนิดหน่อยที่ตอนนี้ ตัว Prompt API ยังจะ support แต่บน Chrome extension ไปก่อนในช่วงแรก ถ้าจะใช้บน web ต้องเปิด flag ใน browser ใช้เท่านั้น

แต่อีกข่าวดีของ Prompt API ก็คือ Microsoft ตัดสินใจเอาด้วย API หน้าตาเหมือนกัน 100% ต่อไปใช้ browser ต่างกันก็ไม่ต้องกังวลเรื่อง compatibility แล้ว

สรุป

จะเห็นว่าตอนนี้ Standard ของ function ทั้งหมดนี้ก็ดูไปในทางเดียวกันแล้วทั้ง Chrome และ Edge ผมคิดว่าในอนาคตถ้าแต่ละเจ้าทำ Model ของตัวเองเสร็จก็ไม่น่าจะหนีไปจากนี้มากจากนี้ หลักๆคือ เราต้อง เรียก Method “availability” ก่อนเพื่อเช็คว่ามี Model อยู่มั้ย ต้อง Download มั้ย ถ้า Download เสร็จ ก็เรียก Method “create” ส่วน method ของแต่ละ function ก็จะต่างกันออกไปนิดหน่อยบ

ปัญหาที่ทุกคนถามคงไม่พ้นเรื่อง Device ต้องบอกว่าตอนนี้ Feature นี้ยัง Support แค่ Desktop ที่มี Ram 4 GB ละ มี storage เหลือ 22 GB ขึ้นไปอยู่ ก็ต้องดูว่า จะมี Gemini Nano รุ่นใหม่ที่เล็กลงกว่านี้ออกมามั้ย ถ้ามี ก็คิดว่าน่าจะไปอยู่ใน Mobile Device หรือเครื่องที่ Spec ต่ำลงไม่ยาก

ส่วนถ้าใครสงสัยว่ามีใครใช้ใน production หรือยังคำตอบคือ “ยัง” น่าจะต้องรออีกซักพักเลยกว่าจะมีคนเอาไปใช้จริงๆ

Playground

ผมได้ลองสร้าง Playground ง่ายๆมาให้ทุกคนได้ลองเล่นเผื่อจะนึกออกว่าเอาไปทำอะไรได้บ้าง

เนื้อหาเพิ่มเติม

• https://developer.chrome.com/docs/ai/get-started
• https://learn.microsoft.com/en-us/microsoft-edge/web-platform/prompt-api
• https://learn.microsoft.com/en-us/microsoft-edge/web-platform/writing-assistance-apis

Playground

• https://chrome.dev/web-ai-demos/writer-rewriter-api-playground/
• https://chrome.dev/web-ai-demos/translation-language-detection-api-playground/
• https://chrome.dev/web-ai-demos/summarization-api-playground/

ต้องบอกก่อนว่า Idea หรือ Tools ที่ใช้รัน LLM บน Browser มีมาซักพักแล้ว ไม่ว่าจะเป็น MediaPipe LLM Inference ของ Google หรือ WebLLM แต่ปัญหาใหญ่ๆมันคือไซส์ model นี่แหละที่ต่อให้เล็กขนาดไหนก็ใหญ่ระดับ GB ทั้งนั้น เมื่อวีคก่อน Google ออก Gemma 3 ออกมา ซึ่งจุดเด่นของ Model รุ่นนี้คือมันเล็กลงมาก และที่มันเด็ดเนี่ยคือมันมี version ที่ขนาด 1 Billion parameter ที่มีไฟล์ไซส์ 500MB ออกมาด้วย ทำให้ผมคิดว่า 500MB นี่แหละที่น่าจะ ใกล้เคียงกับการเอามารันบน Browser มากที่สุดแล้ว ก็เลยคิดว่าจะลองเอามาเทสหน่อยว่ามันรัน ได้จริงมั้ยนะ

ตัว model ตัว 1B ไม่ได้มีความสามารถเท่ากับ ตัวใหญ่ๆที่มีขนาด Context window ที่ใหญ่ 128K แต่ถ้าเทียบกับ model ขนาดเล็ก ก็ถือว่าใหญ่เหมือนกันเพราะก็มี context window ขนาด 32K รวมถึง model ตัวนี้เป็น text only นะครับ

ตัวผมเองเลือกใช้ MediaPipe LLM เพราะว่า ตัว Lib compatible กับตัว Gemma อยู่แล้วตั้งแต่ version 2 ไม่ต้อง compile model ใหม่ใช้ได้เลยข้างหลัง model ตัวนี้ เป็น wrap ของ lib LiteRT หรือ TFlite อีกที

1. ขั้นแรก Download model จาก Kaggle มาก่อนเลยครับ สำหรับ Version นี้จะไม่มีไฟล์ .bin ให้เรา Download ไฟล์ .task มาใช้นะครับ ตอนโหลดอย่าลืมเปลี่ยนไปหน้า LiteRT ก่อนนะครับ

2. Code mediapipe คือ ง่ายมากๆ เพราะมีมาตั้งแต่ Gemma 2 แล้ว

หลังจากนั้นก็ให้ AI เขียน frontend สวยๆขึ้นมาหน่อย ก็จบและ

เหมือนจะดีแต่….

จริงๆบล็อกนี้ไม่ได้ตั้งใจให้ไปทำตาม แต่ตั้งใจจะลองให้รู้จะได้ยังไม่ได้ต้องไปทำตามจริงๆผมมีข้อสรปุอยู่ ตามนี้ครับ

1. จริงอยู่ที่ในความเป็นจริงเราเอา service worker มา cache model ไว้ได้ แต่ model ขนาด 500MB ก็ยังไม่เล็กซักเท่าไหร่ สำหรับเว็บ และต่อให้เรามี ไฟล์ ที่ cache ไว้แล้วบน Local ตัว model ก็ใช้เวลา initial อยู่ประมาณ 30–40 วินาทีอยู่ดี เพราะฉะนั้นแล้ว การโหลด model ขึ้นมากก็ยังดูฝช้ไม่ได้จริงเท่าไหร่สำหรับเราแล้วก็คงต้องรอ Built-in Model ที่มากับ Browser หรือ Model ที่เล็กลงกว่านี้ในอนาคตถึงจะน่าเอามาใช้มากกว่านี้
2. Model ตัว 1b เหมือนจะมี bug ติด infinity loop จน output token เต็ม เอาจริงๆไม่แน่ใจว่าเป็นเพราะ MediaPipe หรือ ตัว model กันแน่ พยายามหาทาง compile ตัว 4b มาใช้ใน LiteRT แต่ก็เหมือนมีคนเจอว่า ตัว WASM มันรันไม่ได้เพราะ Layer มันเยอะไป

3. ตอนนี้ต้องรอ WebLLM ที่ยังไม่ Support Gemma 3 ก่อนว่าจะ Compile ตัว 4b หรือ 27b ได้มั้ยถ้าได้เดี๋ยวจะเล่าให้ฟังอีกที

4. มัน LiteRT มันจะเร็วต่อเมื่อใช้ WebGPU เท่านั้นซึ่งตอนนี้ยังใช้ไม่ได้ทุก Browser เพราะฉะนั้นแล้วอาจจะช้ามากๆถ้าใช้ Safari

สรุป!!!

สุดท้ายแล้วผมลองให้แล้วนะครับ ยังไม่ต้องทำตาม รอใช้ built-in model ดีกว่าไม่มีปัญหาจุกจิกด้วย

Link

• https://www.kaggle.com/models/google/gemma-3
• https://ai.google.dev/edge/mediapipe/solutions/genai/llm_inference

ใครจำได้เนี่ยเมื่อก่อน ถ้าเราจะ reload อะไรซักอย่างบนหน้าเว็บไว้ก่อนเราก็จะใช้ tag prefetch, preload ที่เอาไปใส่ใน Meta แต่ปัญหาใหญ่ๆเลยคือ มัน ทำให้มันทำงาน เป็น programatic ยากมากๆ Chrome ก็เลยออกของใหม่มา นั่นคือ Speculation Rules API จริงๆมันคือ หลักการเดิมเลยคือ การที่เราระบุไว้ก่อนว่าอะไรที่น่าจะใช้แล้วบอก Browser ว่า ให้โหลดหน้านั้นมารอไว้ก่อนเลยนะ

วิธีใช้

วิธีคือ เราก็แค่ประกาศ script หน้าตาประมาณด้านบนเอาไว้เพื่อบอก Browser ว่า Link ไหนในหน้าเว็บนี้ ควร preload เอาไว้ก่อน

1. Prerender — อันนี้คือ condition ของ page ที่อยากให้ prerender background ไว้ก่อนที่ path นั้นจะถูกเปิด โดยเราสามารถระบุเป็น link ที่เป็น list ของ url เลยก็ได้ หรือ จะให้ตัว Browser ไปกวาดดูจาก tag a บนหน้าเว็บก็ได้ ถ้าดูจาก condition ในตัวอย่าง จะเป็นตัวอย่างที่บอกว่า ให้ไปกวาดดูใน tag a แล้วถ้าอันไหน match condition ให้ prerender ได้เลย ถ้าดูใน array แรกของ prerender ในตัวอย่าง จะเห็นว่ามี property ที่เขียนว่า eagerness อยู่ property นี้เอาไว้ระบุว่าเราต้องการให้สิ่งๆนี้ prerender ด่วนขนาดไหน โดย option จะแบ่งเป็น

immediate — คือด่วนสุด เปิดหน้าเว็บมา prerender ได้เลย
eager — ตอนนี้เหมือน immediate แต่ในอนาคต จะทำงานตรงกลางระหว่าง immediate กับ moderate
moderate — ตัว browser จะ prerender เมื่อเราเอาเมาส์ไปวางบน link นั้นๆเกิน 200 milliseconds
conservative — ตัว Browser จะเริ่ม prerender ตอนนี้ user click

2. Prefetch — อันนี้จะเหมาะกับ การที่เราเอาไว้ preload ไฟล์ เช่น html หรือ css หรือ เหมาะกับเว็บที่เป็น SPA ที่ต้องใช้ไฟล์ ซ้ำๆ โดยเราต้องประกาศเป็นชื่อไฟล์ที่เราอยากจะ preload

หรือถ้าใครอยากทำให้เป็น programatics มากขึ้นกว่าเดิมเราก็สามารถจะ inject tag script เข้าไปปกติได้เลย

แล้วพอ set speculationrules แล้ว Browser จะทำยังไงต่อ

พอเราประกาศ condition แบบข้างบนแล้ว เมื่อ Browser เจอ link ที่ match condition ตัว browser ก็จะ แอบ preload หน้านั้นไว้ก่อนที่เราจะเปิด เอาไปเก็บไว้ใน cache ของ browser แต่ไม่ใช่ว่า browser จะ preload ไปเรื่อยๆนะครับ แต่ browser จะมี limit อยู่ว่า eagerness แบบไหนจะ เก็บไว้ไม่เกินกี่หน้า ตามตารางนี้

eagernessPrefetchPrerenderimmediate / eager5010moderate / conservative2 (FIFO)2 (FIFO)

ซึ่งเราสามารถ Debug ดูได้ว่า Browser preload อะไรไว้บ้างหรือ script ของเราทำงานถูกต้องมั้ย ด้วย Chrome Devtools ใน tap Application จะมี เมนูเขียนไว้ว่า speculative loads

อะไรใช้ได้อะไรใช้ไม่ได้บ้าง

อย่างแรกเลย ตอนนี้ feature นี้ใช้ได้แค่ chrome / edge / opera อย่างที่สองคือ ถ้าสมมติเครื่อง หรือมือถือ อยู่ใน mode ประหยัดพลังงาน หรือ ประหยัด data feature นี้จะไม่ทำงาน ตอนนี้ feature นี้ยังอยู่ในการทดสอบระดับนึงอาจจะต้องตาม document นิดหน่อยว่า support อะไรบ้างหรือทำอะไรได้บ้าง

Reference

https://developer.chrome.com/docs/web-platform/prerender-pages

https://developer.mozilla.org/en-US/docs/Web/API/Speculation_Rules_API

วันก่อน ประชุม Google meet ก็เหลือบไปเห็นว่า มันมี UI ที่เป็น Pictue in picture แบบนี้โผล่ออกมา ก็ตกใจว่ามันทำได้ยังไงเพราะว่า มัน support แต่ Video นิ ก็เลยค้นจนไปเจอว่า ตอนนี้ใน Chrome เราสามารถทำ Picture in Picture บน element อะไรก็ได้แล้ว เอาจริงๆเหมือนง่ายนะแต่มีจุดงง อยู่หลายจุดมากๆเลย มาดูกันว่าต้องทำยังไงบ้าง โดยที่ผมจะทำตัวอย่างเป็น application แชท

How-to

1.เราต้องสร้าง element ที่เราจะเอาไปยัดใน PIP ขึ้นมาก่อน สมมติว่าผมสร้าง element ที่เป็นแชทขึ้นมา แล้วหลังจากนั้นก็สร้าง ปุ่มที่จะ active pip ขึ้นมา แล้วพอปุ่มนั้น active ก็ให้ย้าย Element ที่เรากำหนดไปไว้ใน PiP window จริงๆแล้วเราไม่จำเป็นต้อง detect เฉพาะ click event ก็ได้ เราอาจจะเอามาใช้กับ visibility event เพื่อให้ active PiP window ตอนที่ tab โดน hide หรือ เปลี่ยน tab ก็ได้ แต่จะมีข้อแม้นึงคือ PiP จะ active ได้ user ต้องมี interactive เช่น scroll หรือ click บนหน้านั้นๆมาก่อน

https://gist.github.com/thangman22/3289fed2ff3a7675017a0ee972fa43a1

2. ตัว PiP เนี่ยมันมองว่าเป็นหน้าต่างๆนึง เพราะฉะนั้น การบอกว่าจะเอา Element ไหนย้ายไป มันคือย้ายไปจริงๆแบบ ถอดออกจากหน้าหลักแล้วย้ายไปที่หน้าต่าง PiP เลย

3. ปัญหามันจะเกิดก็ตรงนี้นี่แหละ เพราะ PiP ย้ายไปทุกอย่าง แต่ไม่ย้าย CSS ไป.. ซึ่งเราต้อง Move เอา CSS จาก หน้าหลก ไปไว้ใน PiP ผ่าน Code แบบนี้ในตอนที่เรา active PiP ขึ้นมา ถ้าเอาแบบง่ายๆก็ใช้วิธีก็เถื่อนๆเลยคือ หา tag style ทั้งหน้าแล้วก็ append เข้าไปใน PiP windows เลย แต่ถ้าเราตั้งสตินิดนึงก็อาจจะใช้วิธีแบบที่สร้าง css file ขึ้นมาแล้ว inject ไปก็ได้ แต่ก็ต้องมั่นใจว่า copy ไปถูก

https://gist.github.com/thangman22/85ae30b09892939e1ccf3ab42e9c7127

4. ความบันเทิงมันยังไม่จบเพราะพอเราย้าย Element ไปไว้ใน PiP แล้ว ตอนที่ PiP ปิด เราต้องไม่ลืมย้าย element นั้นกลับมา โดยที่เราต้อง ตอน Listen event ว่า PiP ปิดตอนไหนไว้ด้วยไม่อย่างงั้น เราจะไม่สามารถย้าย Element นั้นกลับมาได้เลยเพราะ โดย normal behavior แล้ว ตัว PiP จะให้เรากำหนดเองว่าจะย้ายไปย้ายมายังไงแบบ manual

https://gist.github.com/thangman22/d520f906c127c2dfc96f84e145bd0e1f

ต้องบอกว่าเหมือนจะไม่ยากมากแต่ถ้าไม่เข้าใจว่ามีส่วนต้องย้ายไปย้ายมาด้วย จะงงมากๆว่าทำไม PiP window ปิดไปแล้ว แต่ Element ยังไม่กลับมาที่หน้าหลัก

สำหรับตัว CSS เองเราก็สามารถกำหนด Media query display-mode: picture-in-picture ที่เป็นของ PiP window ได้เพื่อเราจะได้กำหนดได้ชัดเจนว่าตอนอยู่บนหน้าหลักต้องแสดงผลยังไง และบน PiP window ต้องแสดงผลยังไง ทำให้เรากำหนดการแสดงผลได้พอสมควร

https://gist.github.com/thangman22/a909b9e2a0f14743eb04605116150aca

พอเรา implement code ตามนั้นเสร็จเราก็จะได้ PiP ของเราที่หน้าตาแบบนี้

ลองไปเล่น Demo กันได้ที่ https://glitch.com/edit/#!/kon-tum-web-view-pip-on-every-element นะครับ

มาลงรายละเอียดเพิ่มเรื่อง Function ที่ใช้สำหรับ active PiP กันหน่อย สำหรับ Option ที่เรา สามารถกำหนดใน requestWindow ได้ก็จะมีอยู่ 4 อย่าง

• width — ความกว้างของหน้าต่าง
• height — ความสูงของหน้าต่าง
• disallowReturnToOpener — ปิดปุ่มสำหรับการ return ไปหน้าหลัก ต้องปิด PiP ไปเลยเท่านั้น (เอาจริงๆ ปุ่มนี้แทบไม่ต่างกับปุ่มปิด)
• preferInitialWindowPlacement — เปิด PiP บน position ที่เป็น default

หมายเหตุ

สำหรับ feature นี้ตอนนี้ใช้ได้แค่ Chromium ที่รันบน Desktop เท่านั้น Firefox / Safari และ Mobile Browser ทั้งหมดยังใช้ไม่ได้นะครับ

ตอนงาน Google I/O Google ได้ประกาศว่า Google จะ Built in Gemini มาบน Google Chrome หลายๆคนก็คงคิดแต่ว่าโอเค Google Chrome ก็คงจะมีฟีเจอร์ AI ที่เหมือนแบบสามารถใช้บน Google Chrome ได้เรียกใช้ได้ซึ่งก็จริง ณ เวลานี้เนี่ยถ้าเราพิมพ์ในช่อง address bar ใน Chrome ว่า @gemini เราก็สามารถคุยกับ Gemini บนบน Chrome ได้เลยโดยที่ไม่ต้องเข้าเว็บแต่ก็ยังเป็นวิธีแบบที่ลิงค์ไปหาเว็บอยู่ดี

วันนี้เนี่ยเรามี Concept ที่เรียกว่า On Device AI หรือ AI ที่ทำการ Built in ตัวโมเดลลงมาไว้ในแพลตฟอร์มเลยซึ่งแพลตฟอร์มของเว็บก็คือตัว Browser ซึ่ง Concept ง่ายๆก็คือ Google Bundle Gemini Nano มาไว้บน Google Chrome เพื่อให้นักพัฒนาสามารถเรียกใช้ Gemini Nano ได้โดยที่ไม่ต้องขอผ่าน API คำถามคือแล้วมันจะดียังไงทำไมไม่ Call ผ่าน API อย่างแรกคือเมื่อเราขอผ่าน API เนี่ยเราก็จะต้องมีเรียกว่าเวลาที่เรียก API ไปแล้วก็ได้รับผลกลับมาซึ่งเวลาตรงนี้มันค่อนข้างใช้เวลานานมันเลยทำให้ Use Case บางอย่างไม่สามารถใช้งานได้ อาจจะเป็น Live Translation หรือ Sentiment Analysis แต่การ Built in Model ลงมาใน Browser เลยทำให้เราสามารถที่จะปลดล็อคทำ Use Case เหล่านี้ได้เลย อย่างที่สองคือคนทุกคนก็รู้ดีว่าพวก LLM Model เนี่ยราคาสูง การเอามาทำงานเล็กๆก็จะหาจตุดคตุ้มทุนยากเพราะฉะนั้นแล้ว การที่มี Model ฟรีให้เราเรียกใช้ทำงานเล็กๆได้ ก็เป็นเรื่องที่ช่วย Developer ได้ง่ายมากๆ

On Device AI

ก่อนจะไปเล่าเรื่อง Gemini Nano on Chrome มาเล่าเรื่อง On device AI ก่อน จริงๆแล้ว Concept นี้ก็เป็น concept ที่มีใน platform อื่นกันมาแล้ว เช่น Gemini Nano บน Google Pixel 8 Pro และ Galaxy S24 หรือ Apple Intelligence ที่กำลังจะมาใน iOS 18 ที่จะเปิดให้นักพัฒนาสามารถเรียกใช้งานผ่าน SiriKit ได้ ซึ่ง Concept นี้ก็จะเป็นเจ้าของ Platform เองที่จะ Build in model ของตัวเองมาให้ ซึ่งจริงๆก็จะมี ออีก concept คือ AI on Edge ที่ทำการ Ship AI Model ไปกับ source code แล้วก็ Cache ไว้บน เครื่อง Client ซึ่งถ้าเป็นเว็บก็จะใช้ WASM ในการรัน Model ซึ่งปัจจุบันมีหลาย Lib มากๆที่ Support WASM ไม่ว่าจะเป็น transformer.js, TensorFlow.js

Gemini Nano on Chrome

ก่อนอื่นเราจะใช้ Feature นี้เราต้องไปเปิด flag #prompt-api-for-gemini-nano ใน chrome://flags ก่อน

หลังจากนั้นก็ลองเทสได้เลย code สั้นๆ ตามตัวอย่างนี้ได้เลย อยากใส่ prompt อะไรก็ใส่ไปได้เลย

ซึ่ง API Doc ของ Feature นี้ ก็สามารถเข้าไปดูได้ที่นี่ จะเห็นว่าใช้ง่ายมากๆไม่ต้องเรียนรู้อะไรแปลกๆเลย ตอนนี้ก็คงเกิดคำถามว่า เราเอาไปทำอะไรได้บ้าง ซึ่งเอาไปทำได้หลายอย่างมากๆเช่น

1. Live translation แปลภาษาแบบ Realtime ไม่ต้องรอ call server
2. Chat Prediction ใช้ แนะนำว่าประโยคต่อไปที่ควรพิมพ์ใน Chat คืออะไร
3. Rating Prediction ใช้แนะนำว่าจาก Comment นี้ ควรแปลงเป็นดาว rating กี่ดาว

** ผมได้ลองทำ Example ง่ายๆที่ใช้ feature นี้เอาไว้สามารถลองไปอ่าน code แล้วก็ไปลองเล่นกันได้ แต่อย่าลืม enable flag ก่อนนะครับ

อนาคตมันจะเป็นยังไงนะ

ผมมีความเชื่อลึกๆว่าอนาคต On Device AI จะกลายเป็นเรื่องที่ใกล้ตัวเรามากขึ้น พอ Model LLM เล็กลง เราก็น่าจะเห็นผู้ผลิต Browser bundle LLM model เข้ามาไว้ใน Browser กันมากขึ้น ส่วนเรื่อง Standard จะเป็นยังไง ก็บอกได้แค่ว่า บันเทิงแน่นอน…

ช่วย Google IOX Season ผมได้พูดเรื่อง session นี้เอาไว้ใครอยากเข้าไปดูก็ไปดู slide ได้ที่นี่นะครับ

Reference

• https://developer.chrome.com/docs/ai/built-in
• https://docs.google.com/document/d/1VG8HIyz361zGduWgNG7R_R8Xkv0OOJ8b5C9QKeCjU0c/edit
• https://docs.google.com/presentation/d/151HFNZCap3w8CBXUgOJUcPVcIiSZ2Xu-axR62BOmqGM/edit#slide=id.g273b0ad44a0_2_113

หลังจากที่ Experiment กันอยู่หลายเดือนตอนนี้ Popover API ก็พร้อมใช้บน ทุก Browser แล้ว แต่ก่อนอื่นต้องมาเล่ากันก่อนว่า Popover API คืออะไร Popover API เป็น Feature บนเว็บที่ทำให้เราสามารถสร้าง Element แบบที่เป็น Lightbox บนหน้าเว็บโดยไม่ต้องพึ่ง Lib ได้โดยที่การเปิดปิด element นี้ สามารถกำหนดใน HTML Element ได้เลย

ซึ่งถ้าใครเคยใช้พวก Lib ที่เป็น Javacsript ก็จะเห็นว่ามีวิธีการใช้งานที่ค่อนข้างใกล้เคียงกันมากๆ ซึ่งในเวลาเดียวกันถ้าใคร อยากจะทำ ปุ่มปิด ตัว popover element ก็เปิดให้เราทำตัวปุ่มปิดง่ายๆได้เลย แค่ใส่ element ที่มี attribute popovertarget="my-popover" popovertargetaction="hide" ไว้ก็จะกลายเป็นปุ่มปิดได้เลย

นี่ก็เป็นตัวอย่างที่ผมลองเขียน Popover ง่ายๆ

เรามี Dialog Element อยู่แล้วไม่ใช่หรอ…..

ใช่ครับ!!! นั่นคือคำถามแรกเลยที่ผมถามตอนเห็น API นี้ ซึ่งพอไปดู Spec แล้วมันก็มีความต่างกันจริงๆแหละ แต่เป็นความต่างแบบแปลกๆ เพราะเหมือนแทนที่จะเพิ่ม Feature ให้ Dialog แต่กลับมาทำ Popover API เป็นอันใหม่ ซึ่งสิ่งที่ต่างกันระหว่าง Dialog Element กับ Popover Api ก็จะมีตามนี้

1. Dialog element ต้องเปิด / ปิดด้วย function Javascript ที่ชื่อว่า showModal หรือ Close แต่ Popover เป็นการเอา Element ไปผูกกับ Element นึง แล้วก็เวลาทำปุ่มปิดก็ทำคล้ายๆกัน

2. By default แล้ว Dialog จะปิดได้ต้อง implement ปุ่มปิดมาเท่านั้น ถ้าไม่มีมันก็จะคาอยู่แบบนั้น แต่ Popover ถ้าเราคลิก element นอก Popover มันก็จะปิดเอง

เอาจริงๆก็จะมีสองอันนี้ที่ต่างกันนอกนั้นก็เป็นแค่วิธีการเขียน CSS ที่ต่างกันเท่านั้นเอง มาถึงตรงนั้นี้แล้วผมก็ยังสงสัยอยู่ดีว่าทำมาสองอันทำไมนะ…

Reference

Popover API lands in Baseline | Blog | web.dev

https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/popover

เข้าไปดู API กันก่อน

สำหรับใครที่อยากจะใช้ Model Gemini Pro หรือ Gemini Vision Pro เนี่ย เราก็สามารถเข้าไปดู Tutorial กับ เอา API Key ได้จาก https://aistudio.google.com/ ซึ่งก็ไม่ได้มีอะไรซับซ้อน แค่กดปุ่ม “Get API Key” หรือถ้าใครอยากดู code ตัวอย่างก็มี ปุ่ม Get code ให้ลองดูตัวอย่าง code แต่ละ ภาษาได้เลย

เริ่มที่แกะเนื้อหาก่อน

คือ เจ้า Model Gemini เนี่ย มันไม่ต่อ Internet ทำให้อยู่ดีๆเราจะโยน Link ไปตรงๆไม่ได้ เราต้องเอาเนื้อหาออกมาก่อน แต่ไอ้จะไปเอา HTML ออกมาทั้งดุ้นก็คงไม่ Work ตอนแรกก็คิดว่าจะไปใช้ Service ที่เป็น API based สำหรับเอาไว้ extract content ออกมาจาก link แต่คิดไปคิดมา อันนี้ทำเล่นๆ ไม่ควรที่จะต้องไปเสียเงินกับเรื่องแบบนั้น ก็เลยคิดว่า โอเคลองหา lib ที่เอาไว้ แกะ content ดูแล้วกันไม่แม่นก็ช่างมันไม่ได้ซีเรียส ก็เลยไปเจอกับ Lib https://github.com/extractus/article-extractor ที่ดูดีเลย วิธีใช้ก็ง่ายแค่โยน link เข้าไปก็จบเลย ตัวอย่าง code ง่ายๆประมาณนี้

ซึ่งพอเราได้ content ออกมา มันก็มักจะมี html tag ติดมาด้วยก็แค่ remove ออก

เขียน prompt ยังไงดี

เอาจริงๆเราก็ลอง prompt อยู่หลายอันพอสมควร แต่อันที่รู้สึกว่ามันน่าจะโอเคที่สุดก็คือ

This is an article or news from website ${request.body.url}. Please summary to 1 paragraph in the ${language} lanaguage. This is full article ${plainContent}

เพราะตอนแรกลองไม่บอกว่า จะเอาแค่ 1 paragraph ตัว Model ก็ พ่นออกมายาวกว่าบทความจริงอีก แถมถ้าไม่บอกภาษาบางครั้งก็พ่นออกมาเป็นภาษา อังกฤษ ทั้งที่ระบุไปแล้วว่าเอาภาษาเดียวกับ บทความก็ยังมีหลุดมาบ้างทำให้ต้อง specific ภาษาลงไป ซึ่ง ถ้าใครอยากเทส prompt ก่อน ก็ลองในหน้า AI studio ได้เลย ยังไม่ต้องลองเขียน code ก็ได้ เอาจนกว่าเราจะโอเคกับมันก็ค่อยมาลองเขียนเป็น code

ถึงเวลาโยน data ให้ Gemini

ตอนแรกเนี่ยเราก็กะว่าจะเขียน ให้ ยิง API เอง เพราะไม่รู้ว่ามันมี lib ของ Google สำเร็จอยู่แล้ว แต่พอไปกดดู code ตัวอย่างก็เลยตัดสินใจว่า ใช้ของที่เค้าเตรียมให้ดีกว่า จะได้ดูดีด้วย ซึ่งก็ลงเป็น npm ปกติเลย https://www.npmjs.com/package/@google/generative-ai ตอนแรกเนี่ยก็คิดว่าจะให้มัน call ผ่าน frontend ให้หมดเลยขี้เกียจ deploy backend แต่พอมาคิดไปคิดมาแล้ว ถ้าต้องเปิด API Key ออกหน้าเว็บก็คงไม่ใช่เรื่องดีเท่าไหร่ ก็เลยย้าย logic ที่จะคุยกับ Gemini ไปไว้ที่ Backend ให้หมด สำหรับ code ที่เอาไว้โยนไปหา Gemini ก็ง่ายแสนจะง่าย

พอได้ข้อมูลออกมาเป็น response text ก็แค่เอาไปแสดงผลบนหน้าบ้าน แค่นี้จบได้ผลออกมาตามนี้เลย

เพิ่ม feature คุยกับข่าว / Share target เข้าไปเพิ่ม

พอเริ่มทำแล้วก็คิดว่ามันน่าจะดีนะถ้าเราให้คนคุยกับข่าวได้ ก็เลยเพิ่มกล่องคล้ายๆกล่องแชทเข้าไปเพื่อให้คนพิมพ์คุยกับข่าวได้ ซึ่งก็ทำ process ทั้งหมดคล้ายๆเดิม เปลี่ยนแค prompt

This is article or news from ${request.body.url}. Based on this is an article or news ${plainContent} please answer this question “${request.body.question}”.

ซึ่งผลออกมาก็เรียกว่าพอใช้ได้ บางทีก็ตอบได้บ้างไม่ได้บ้าง อันนี้คือผลลัพธ์ที่เราถาม Gemini ว่า เค้ามีปัญหาอะไรกัน

เพื่อให้ใช้ ใน Android ง่าย ผมเลย เพิ่ม share target เข้าไป จะได้ไม่ต้องมาคอย Copy url มาแปะทุกครั้งที่จะใช้ ซึ่งก็ เพิ่ม code block นี้เข้าไปในไฟล์ manifest.json ก็จบเลย

{"share_target": { "action": "/", "method": "GET", "params": { "title": "title", "text": "text", "url": "url" } }}

คราวนี้เราก็สามารถใช้แชร์ใน Android แชร์ link ข่าวตรงๆมาหา App เราได้แล้ว

ใครที่อยากจะลองใช้ App นี้ก็เข้าไปได้ที่ https://itlidr.thangman22.com/ นะครับ หรือถ้าใครอยากเข้าไปดู code ว่าทำงานยังไงก็ไปดูได้ที่ repo

GitHub - thangman22/ITLIDR

คราวนี้เรามาพูดถึงตัว Gemini บ้างดีกว่า

Gemini ดีจริงหรือเปล่า?

คนก็สงสัยว่าเราควรใช้ Google Gemini pro หรือ GPT ดีกว่า ผมก็เลยลองเอา prompt เดียวกันไป รันใน model ทุกตัว เพื่อดูว่า model แต่ละตัวตอบอะไรออกมา

This is an article or news from website https://thestandard.co/returning-an-illegal-gun-is-not-a-crime/. Please summary to 1 paragraph in the thai lanaguage. This is full articleวันนี้ (26 กุมภาพันธ์) ไตรศุลี ไตรสรณกุล เลขานุการรัฐมนตรีว่าการกระทรวงมหาดไทย ในฐานะโฆษกกระทรวงมหาดไทย เปิดเผยว่า กระทรวงมหาดไทยได้ดำเนินการตามข้อสั่งการที่ เศรษฐา ทวีสิน นายกรัฐมนตรี และรัฐมนตรีว่าการกระทรวงการคลัง ได้ให้กระทรวงมหาดไทยกำหนดมาตรการให้ผู้ครอบครองอาวุธปืนและเครื่องกระสุนปืนผิดกฎหมาย นำอาวุธปืนและเครื่องกระสุนปืนมาส่งมอบให้แก่ทางราชการ พร้อมกำหนดยกเว้นความรับผิดทางอาญาให้แก่บุคคลนั้นด้วย เพื่อให้เป็นมาตรการลดจำนวนปืน สิ่งเทียมอาวุธปืนผิดกฎหมาย ที่มีผู้ใช้ในการก่ออาชญากรรมและความรุนแรงในสังคมล่าสุด กระทรวงมหาดไทยได้ยกร่างพระราชกำหนด (พ.ร.ก.) ยกเว้นความรับผิดทางอาญาให้แก่ผู้นำอาวุธปืนหรือเครื่องกระสุนปืนที่ไม่ได้รับอนุญาตหรือที่กฎหมายห้ามออกใบอนุญาต หรือสิ่งเทียมอาวุธ มามอบให้แก่ทางราชการ พ.ศ. … พร้อมกับยกร่างหลักเกณฑ์และวิธีการในการส่งมอบการรับมอบการเก็บรักษาและการทำลายอาวุธปืนที่ได้มีการนำมาคืนดังกล่าวเสร็จเรียบร้อยแล้ว และ อนุทิน ชาญวีรกูล ในฐานะรัฐมนตรีว่าการกระทรวงมหาดไทย ได้ลงนามในร่าง พ.ร.ก. และร่างหลักเกณฑ์ดังกล่าวแล้ว ขณะนี้อยู่ระหว่างการนำเสนอให้สำนักเลขาธิการคณะรัฐมนตรี (สลค.) นำไปบรรจุเป็นวาระเสนอให้ที่ประชุมคณะรัฐมนตรี (ครม.) พิจารณาอนุมัติและดำเนินการตามขั้นตอนทางกฎหมายเพื่อมีผลบังคับต่อไปไตรศุลีกล่าวต่ออีกว่า ที่รัฐบาลและกระทรวงมหาดไทยได้มีมาตรการทางกฎหมายดังกล่าว เนื่องด้วยปัจจุบันได้เกิดกรณีการประทุษร้ายทำลายชีวิตและทรัพย์สินของประชาชนที่ปรากฏขึ้นจำนวนมาก ซึ่งสถิติปี 2559–2566 พบว่า อาวุธปืนที่ใช้ก่อเหตุอาชญากรรมนั้น ร้อยละ 83 เป็นอาวุธปืนผิดกฎหมาย ขณะที่สิ่งเทียมอาวุธปืนซึ่งดัดแปลงเป็นอาวุธปืนได้เพิ่มจำนวนมากขึ้นจากการลักลอบทำ ดัดแปลง สั่ง นำเข้า หรือค้า ทั้งช่องทางปกติและช่องทางออนไลน์ ซึ่งเพียงการจับกุมปราบปรามไม่สามารถแก้ไขปัญหาได้ทั้งหมด จำเป็นต้องมีหลายมาตรการควบคู่กัน เพื่อเร่งลดผลกระทบต่อทางสังคมจากปัญหาอาวุธปืน ทั้งทางด้านความเชื่อมั่น ความปลอดภัยสาธารณะ ความสงบเรียบร้อย ความมั่นคง ทางเศรษฐกิจ การท่องเที่ยว และการลงทุน”การควบคุมอาวุธปืนและสิ่งเทียมอาวุธปืนให้มีจำนวนลดน้อยลงถือเป็นกรณีฉุกเฉิน จำเป็นเร่งด่วนที่ต้องเร่งดำเนินการ เพื่อประโยชน์ในอันที่จะรักษาความปลอดภัยของประเทศและความปลอดภัยสาธารณะ ซึ่งการออก พ.ร.ก.ยกเว้นความรับผิดทางอาญาให้แก่ผู้นำอาวุธปืนหรือสิ่งเทียมอาวุธที่ไม่ได้รับอนุญาตมาส่งมอบให้ทางราชการในเวลาที่กำหนด พร้อมกำหนดเกณฑ์การส่งมอบ การเก็บรักษา และการทำลายอาวุธปืนดังกล่าว จะเป็นมาตรการที่จะช่วยให้มีการลดจำนวนอาวุธปืนในระบบลงได้ในเวลาอันสั้น” ไตรศุลีกล่าว

อันนี้คือ Prompt ที่ส่งไปถาม ทั้ง 4 Model ( Gemini Pro 1.0, Gemini Pro 1.5, GPT 3.5 Turbo, GPT 4)

ผลจาก Gemini 1.0

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

ผลจาก Gemini 1.5

กระทรวงมหาดไทยได้ดำเนินการตามคำสั่งของนายกรัฐมนตรี เศรษฐา ทวีสิน ในการกำหนดมาตรการเพื่อลดจำนวนอาวุธปืนผิดกฎหมาย โดยได้ร่างพระราชกำหนด (พ.ร.ก.) ยกเว้นความรับผิดทางอาญาสำหรับผู้ที่นำอาวุธปืนหรือเครื่องกระสุนปืนที่ผิดกฎหมายมาส่งมอบให้แก่ทางราชการ มาตรการนี้เกิดขึ้นเนื่องจากปัญหาอาชญากรรมและความรุนแรงที่เกิดจากอาวุธปืนผิดกฎหมายและสิ่งเทียมอาวุธปืนที่เพิ่มจำนวนมากขึ้น พ.ร.ก. นี้จะช่วยลดจำนวนอาวุธปืนในระบบลงได้อย่างรวดเร็ว และจะช่วยรักษาความปลอดภัยของประเทศและความปลอดภัยสาธารณะ

ผลจาก GPT 3.5 Turbo

วันนี้ ไตรศุลี ไตรสรณกุล เลขานุการรัฐมนตรีว่าการกระทรวงมหาดไทย เปิดเผยว่า กระทรวงมหาดไทยได้ดำเนินการตามข้อสั่งการที่ เศรษฐา ทวีสิน นายกรัฐมนตรี และรัฐมนตรีว่าการกระทรวงการคลัง ได้ให้ กำหนดมาตรการให้ผู้ครอบครองอาวุธปืนและเครื่องกระสุนปืนผิดกฎหมาย นำอาวุธปืนและเครื่องกระสุนปืนมาส่งมอบให้แก่ทางราชการ พร้อมกำหนดยกเว้นความรับผิดทางอาญาให้แก่บุคคลนั้นด้วย เพื่อให้เป็นมาตรการลดจำนวนปืนสิ่งเทียมอาวุธปืนผิดกฎหมาย ที่มีผู้ใช้ในการก่ออาชญากรรมและความรุนแรงในสังคมล่าสุด การออก พ.ร.ก. ยกเว้นความรับผิดทางอาญาให้แก่ผู้นำอาวุธปืนหรือสิ่งเทียมอาวุธที่ไม่ได้รับอนุญาตมาส่งมอบให้ทางราชการ และร่างหลักเกณฑ์ดังกล่าว จะช่วยให้มีการลดจำนวนอาวุธปืนในระบบลงได้ในเวลาอันสั้น ไม่ว่าใครที่ลดปืนมาส่งจะได้รับการยกเว้นความรับผิดทางอาญาไปเช่นกัน นอกจากนี้ ยังต้องมีมาตรการควบคู่กัน เพื่อเร่งลดผลกระทบต่อทางสังคมจากปัญหาอาวุธปืน ด้วยความปลอดภัยของประเทศและความปลอดภัยสาธารณะ โดยรัฐบาลและกระทรวงมหาดไทยเข้ามีมาตรการดังกล่าวเพื่อลดการใช้อาวุธปืนในการก่ออาชญากรรมในสังคมลงได้ในเร็ววันข้างหน้า.

ผลจาก GPT 4 Turbo

กระทรวงมหาดไทยประกาศมาตรการตามคำสั่งของนายกรัฐมนตรี เศรษฐา ทวีสิน ให้มีการกำหนดยกเว้นความรับผิดทางอาญาสำหรับผู้ที่ครอบครองอาวุธปืนและเครื่องกระสุนปืนผิดกฎหมายเมื่อนำมาส่งคืนให้กับทางราชการ เพื่อลดจำนวนอาวุธที่ใช้ในการก่ออาชญากรรมและความรุนแรงในสังคม โดยมีการยกร่างพ.ร.ก. เกี่ยวกับหลักเกณฑ์ในการส่งมอบ การเก็บรักษา และการทำลายอาวุธดังกล่าว ซึ่งอยู่ระหว่างการนำเสนอให้คณะรัฐมนตรีพิจารณา เพื่อดำเนินการตามกฎหมายและลดผลกระทบจากปัญหาอาวุธปืนต่อสังคมอย่างเร่งด่วนและมีประสิทธิภาพ.

สำหรับผมแล้วเนื่องจาก context มันไม่ได้ซับซ้อนมากก็เลยไม่คิดว่าแต่ละตัวต่างกันเท่าไหร่ จะมีแต่ GPT 3.5 ที่บอกให้เขียน paragraph เดียว แต่ดันเขียนมาซะยาวกว่าข่าวเลย ส่วนเรื่องการใช้ภาษาก็ดูไม่ได้ต่างกันเท่าไหร่

แล้วเรื่องราคาหละ?

ต้องบอกว่าตอนนี้ Gemini Pro ยังฟรีอยู่เนื่องจากยังเป็น beta เพราะฉะนั้นการเทียบฟรีกับ ไม่ฟรีก็คงไม่สมเหตุสมผล ผมก็เลยไปเอาราคาที่ Google ประกาศว่าหลัง GA จะคิดเงินมาเทียบกันว่าทั้งสอง

จะเห็นว่าถ้าเทียบกับ GPT แล้ว Gemini ราคาถูกกว่ามากๆ ไม่นับว่าเทียบกับ GPT4 ที่ถูกกว่า เป็น 100 เท่า แถม เอาจริงๆ ส่วนตัวผมก็รู้สึกว่า Gemini Pro ก็ไม่ได้ต่างกับ GPT 4 ขนาดนั้น แต่สุดท้ายแล้วก็ต้องไปลองครับว่าอันไหนดีกับ Application ของคุณและตัวไหนตอบโจทย์คุณมากที่สุด

Links

• GitHub - thangman22/ITLIDR
• ITLIDR - It Too Long I Don't Read
• Google AI Studio

Project Thailand Web Landscape เป็น โครงการที่ผมอยากจะเห็นภาพรวมของเว็บไซต์ในประเทศไทยว่าแต่ละเว็บเร็วช้ายังไง ได้ score บน light house มากขนาดไหนหรือใช้ Stack อะไรในการทำ เว็บ ซึ่งจะทำแบบนั้นได้ เราจะต้องเอาเว็บไซต์ทั้งหมดในประเทศไทยมารัน Lighthouse และ Builtwith ซึ่ง ระหว่างทางก็วุ่นวายมากๆแต่สุดท้ายแล้วก็ได้ผลออกมา

เอาเว็บมาจากไหน

ใน version นี้ เรา Run test บน website ทั้งหมด 2,144 เว็บไซต์ โดย เว็บไซต์ส่วนใหญ่เป็น List เว็บไซต์จากสมาคมต่างๆ อย่าง สมาคม startup หรือ สมาคม สื่อ รวมถึงเป็น list เว็บไซต์ จาก Set ด้วยเหมือนกัน

ผลการเทส Web Vitals

ถ้าดูผลบน mobile จะเห็นว่า Web vitals ใน Mobile ผลออกมาค่อนข้างต่ำถ้าเทียบกับ Desktop ส่วนนึงน่าจะมาจาก Evironment ที่จำลองการเทส Mobile ค่อนข้าง optimize ได้ยากรวมถึง Internet มือถือในไทยค่อนข้างเร็วทำให้คนไทยอาจจะไม่ ค่อย นิยม Optiomize เว็บ เพื่อ Mobile จะเห็นว่าปัญหาใหญ่ๆของเว็บไทยอยู่ ที่ LCP ที่มีค่าสูงกว่าเพื่อนทั้ง mobile และ Desktop

ผลการเทส Light House

Lighthouse Score ฝั่ง performance ออกมาอยู่ที่ 49 ซึ่งถือว่าค่อนข้างช้า แต่ถ้าดู Desktop ก็เรียกได้ว่าค่อนข้างสูง อยู่ที่ 71 ส่วนคะแนนด้านอื่นค่อนข้างออกมาดียกเว้นแต่ PWA ที่ออกมาเพียงแค่ ประมาณ 30 นิดๆเท่านั้น

คราวนี้มาดูกันบ้างว่าเว็บไทยเสียเวลาโหลดไปกับอะไร จะเห็นกว่า เราโดนสิ่งที่ไม่ได้ optimize ทำให้เว็บบน Mobile ช้าลงไปถึง 31 วินาที และ เกือบ 7 วินาที บน Desktop และถ้าตัดปัญหา Main thread ที่แก้แสนยากออกไป จะเห็นว่าปัญหาส่วนใหญ่เป็นเรื่องรูป อันนึงเลยคือการที่ไม่ใช้รูปที่เป็น WebP (Legecy Image) และที่น่าตลกอีกอันคือ ใน Mobile รูป GIF ที่ทำให้เว็บโหลดช้าไปเกือบครึ่งนาที ส่วนปัญหาเรื่อง Minify ต่างๆเรียกว่าแทบจะไม่มีอีกแล้วเพราะเว็บส่วนใหญ่ ตอนนี้ minify กันหมดแล้ว

ผลการเทส Best practice / PWA

มีเว็บไทยถึง 24.5% ที่ไม่ Support HTTPS และ เว็บส่วนใหญ่ใช้บริการ HTTPS ของ Let’encypt และ Cloudflare ส่วน Popup notification กวนใจที่หลายๆเว็บชอบทำนั้น มีเพียงแค่ 0.7% จากเว็บทั้งหมด ส่วนเรื่อง PWA ต้องบอกว่าน่าตกใจมากๆเพราะมีเว็บไทยถึง 10% ที่ support การ Add to home screen

ผลการเทส SEO

จริงๆเรื่องนี้ไม่ค่อยน่าแปลกใจที่ Score SEO ออกมาแบบนี้ แต่ว่า มีมากเกือบครึ่งเลยที่ไม่มี description data

ผลการเทส เรื่อง Tech stack

มาดูฝั่ง Langauge และ framework บ้างถ้าเป็น ฝั่งภาษา PHP ก็ยังมีมากถึง 31% ส่วนฝั่ง Frontend framework ก็ไม่ surprise เลยที่จะเป็น React ที่มากถึง 9.3% ของเว็บทั้งหมดส่วนฝั่ง CMS Wordpress ก็กินขาด

ส่วนฝั่ง Library จะเยอะนิดนึงแต่ที่น่าสนใจเลยคือ jQuery ยังครองโลกอยู่ Bootstrap ก็เช่นเดียวกัน มีเว็บที่ใช้ Firebase อยู่ 1% มีเว็บที่ใช้ Google font สูงถึง 30% Google tag manager ก็ 30% ส่วน E-commerce ก็ Woo commerce website ชิงล่วนแบ่งการตลาดไปมากถึง 68% ส่วนพวก Script โฆษนา ก็เป็น Google adsense ซัก 45% ทิ้งห่างคนอื่นไป3.5 เท่า ส่วนฝั่ง Google Analytics ก็ไม่แพ้กัน GA กินส่วนแบ่งไปถึง 55%

ผลการเทส เรื่อง Server

Server ส่วนใหญ่แล้วก็เป็น Apache แต่ Nginx ก็ไม่ได้ทิ้งห่างมาก ส่วนฝั่ง Cloud AWS กินขาดไปเลยในประเทศนี้ ส่วนเรื่อง Email Provider เรียกได้ว่า Google / Microsoft แทบจะ 50/50

หมายเหตุ

ด้วยข้อจำกัดด้านเวลากับความรู้ทำให้list เว็บไซต์ในปีนี้อาจจะยังไม่ได้เยอะเท่าไหร่ ถ้าใครอยากมาช่วย contribute list เว็บไซต์ที่จะถูกเทส ก็เข้าไป เปิด PR หรือ เปิด issue ใน repo นี้ได้เลย https://github.com/thangman22/thailand-web-landscape ผมสัญญาว่าปีหน้ามันจะดีกว่านี้