หากอยากสร้างแชตบอตสไตล์ ChatGPT แบบโอเพนซอร์สของคุณเอง

 (hacks.mozilla.org)
1 คะแนน โดย GN⁺ 2023-07-31 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ทีมเล็ก ๆ ในกลุ่มนวัตกรรมของ Mozilla สร้าง ต้นแบบแชตบอตสำหรับใช้ภายใน ในแฮกกาธอน 1 สัปดาห์ ทดลองโครงแบบที่รัน LLM โอเพนซอร์สภายในคลาวด์ของ Mozilla โดยไม่ใช้ API จากบุคคลที่สาม
  • เมื่อตัด AI SaaS ภายนอกออกไป จึงต้องตั้งค่าเซิร์ฟเวอร์เองโดยตรงใน บัญชี GCP ของ Mozilla และเปลี่ยนจาก Hugging Face text-generation-inference ไปใช้ llama.cpp ที่รันได้เร็วกว่า
  • การเลือกโมเดลถูกจำกัดด้วย ไลเซนส์และความเข้ากันได้ของรันไทม์ ก่อนคุณภาพ และหลังจากประเมินด้วยตนเองจากตัวเลือกตระกูล LLaMA ที่ใช้งานเชิงพาณิชย์ได้ ก็เลือก LLaMA 2
  • การเชื่อมโยงความรู้ภายในทำด้วย embedding และ vector search โดยผสาน all-mpnet-base-v2, SentenceTransformers, LangChain และ FAISS เพื่อใช้บางส่วนของวิกิบริษัทในการตอบคำถาม
  • แม้ต้นแบบจะเสร็จสมบูรณ์ แต่การสร้างแชตบอตโอเพนซอร์สที่เชื่อถือได้ยังมีหลายด้านที่ต้องตัดสินใจเอง ตั้งแต่โฮสติ้ง การประเมินโมเดล อคติ พรอมป์ ไปจนถึง UI

แชตบอตภายในที่ Mozilla พยายามสร้าง

  • Mozilla ยึดหลัก trustworthy AI ว่าระบบ AI ต้อง โปร่งใส ต่อข้อมูลและการตัดสินใจที่ใช้ เคารพความเป็นส่วนตัว อำนาจการตัดสินใจของผู้ใช้ และความปลอดภัย รวมถึงลดอคติและเพิ่มความเป็นธรรม
  • ช่องทางหลักที่ผู้ใช้จำนวนมากได้สัมผัส AI รุ่นใหม่คือ แชตบอต AI เชิงสร้างสรรค์ อย่าง ChatGPT และ Bard และบริการที่ครองตลาดมักดำเนินการโดยบริษัทเทคโนโลยีทรงอิทธิพลและพึ่งพาเทคโนโลยีแบบปิด
  • Mozilla มองว่าโอเพนซอร์สเป็นวิธีเพิ่มพลังให้ผู้ใช้ เพิ่มความโปร่งใส และทำให้เทคโนโลยีไม่พัฒนาไปตามโลกทัศน์และแรงจูงใจทางการเงินของบริษัทไม่กี่แห่งเท่านั้น
  • เป้าหมายโดยตรงของแฮกกาธอนคือการสร้าง ต้นแบบแชตบอตสำหรับใช้ภายใน ที่ตรงตามเงื่อนไขต่อไปนี้
    • รันทั้งหมดบนโครงสร้างพื้นฐานคลาวด์ของ Mozilla และไม่พึ่งพา API หรือบริการจากบุคคลที่สาม
    • ประกอบด้วย LLM และเครื่องมือโอเพนซอร์สฟรี
    • สะท้อน Mozilla Manifesto และหลัก trustworthy AI
    • รวมความรู้ภายในบางส่วนของ Mozilla เพื่อให้ตอบคำถามพนักงานได้

โฮสติ้ง: เซิร์ฟเวอร์ GCP ของตัวเองแทน SaaS ภายนอก

  • มีบริการโฮสต์แอปแมชชีนเลิร์นนิงอยู่มาก แต่ MLOps เป็นเรื่องยาก และแอป AI ที่ตั้งค่าไม่ดีอาจช้า แพง หรือคุณภาพต่ำได้
  • เป้าหมายที่ทีมระบุไว้อย่างชัดเจนคือ ความปลอดภัยและความเป็นส่วนตัว ที่บุคคลภายนอกไม่สามารถฟังสิ่งที่ใช้งาน เก็บข้อมูลผู้ใช้ หรือสอดส่องสถานะการใช้งานได้
  • ดังนั้นจึงไม่ใช้ AI SaaS hosting จากบุคคลที่สาม แต่ตั้งค่าเซิร์ฟเวอร์เสมือนเองใน บัญชี Google Cloud Platform ที่ Mozilla มีอยู่แล้ว
  • ทางเลือกนี้ทำให้ Mozilla ควบคุมระบบและรักษาให้เป็นส่วนตัวได้ แลกกับการต้องรับภาระ MLOps เอง

รันไทม์: เปลี่ยนจาก Hugging Face ไปใช้ llama.cpp

  • แอป LLM ต้องมี runtime engine สำหรับรันโมเดล และด้วยข้อจำกัดด้านเวลา ทีมจึงมุ่งไปที่ llama.cpp และ ecosystem ของ Hugging Face
  • Hugging Face มีไลบรารีโมเดล เอกสาร ทิวทอเรียล และ hosted inference API
  • text-generation-inference รองรับหลายโมเดลและหลายสถาปัตยกรรมโมเดล และ deploy ด้วย Docker ได้ แต่ระหว่างรันเซิร์ฟเวอร์มี ปัญหาการตั้งค่าสภาพแวดล้อม ค่อนข้างมาก
    • เนื่องจากเป็นเครื่องมือเร่งความเร็วด้วย GPU จึงต้องให้ OS, ฮาร์ดแวร์ และไดรเวอร์ของเซิร์ฟเวอร์เข้ากันได้
    • ต้องใช้ NVIDIA CUDA toolkit
    • ใช้เวลาส่วนใหญ่ของหนึ่งวันไปกับการตั้งค่า และหลังจากรันได้แล้ว output ก็ช้ากว่าที่คาดและผลลัพธ์ไม่ดี
  • ด้วยข้อจำกัดด้านเวลา จึงเปลี่ยนทิศทางไปใช้ llama.cpp ที่เริ่มโดย Georgi Gerganov
    • llama.cpp ช่วยให้รัน LLM บางตระกูลบนฮาร์ดแวร์ระดับผู้บริโภคได้ง่าย
    • ใช้ CPU แทน GPU ระดับสูงได้ และรันโมเดลโอเพนซอร์สสมัยใหม่ขนาดค่อนข้างเล็กบน CPU อย่าง Apple Silicon เช่น M1 และ M2 ได้ดีเป็นพิเศษ
    • llama-cpp-python มี implementation ของ OpenAI API specification ทำให้นำ LLM ของตัวเองมาเสียบแทน ChatGPT ได้ง่าย
  • สุดท้ายทีมรัน llama.cpp ได้อย่างรวดเร็วบน เซิร์ฟเวอร์เสมือน AMD multicore CPU แทนการจัดการกับเวอร์ชัน CUDA และ GPU สำหรับโฮสติ้งราคาแพง

การเลือกโมเดล: ข้อจำกัดด้านไลเซนส์และสถาปัตยกรรม

  • เมื่อเลือก llama.cpp โมเดลที่ใช้ได้ก็แคบลงเหลือ โมเดลที่อิงสถาปัตยกรรม LLaMA
  • Facebook เปิดตัว LLaMA ช่วงปลายปี 2022 และ LLaMA สามารถแยกเป็นข้อมูลโมเดลกับสถาปัตยกรรมได้
    • สถาปัตยกรรม LLaMA ถูกเปิดเป็นโอเพนซอร์ส แต่ข้อมูลโมเดลหรือ weights ไม่ใช่โอเพนซอร์ส
    • การใช้ weights ต้องยื่นขออนุญาตและจำกัดไว้สำหรับวัตถุประสงค์ที่ไม่ใช่เชิงพาณิชย์
  • LLaMA กระตุ้นให้เกิดนวัตกรรมโมเดลจำนวนมาก เช่น Alpaca ของ Stanford และ Vicuna ของ LMSYS
    • แต่โมเดลเหล่านี้พัฒนาจาก weights ของ Facebook จึงสืบทอดข้อจำกัดทางกฎหมายของ weights เดิม
    • ไม่สามารถใช้เพื่อวัตถุประสงค์เชิงพาณิชย์ได้ จึงถูกตัดออกจากตัวเลือกของทีม Mozilla
  • ตัวสถาปัตยกรรม LLaMA เองเป็นโค้ดโอเพนซอร์ส ดังนั้นกลุ่มอื่น ๆ จึงสามารถเทรนโมเดลตั้งแต่ต้นและเผยแพร่ภายใต้ไลเซนส์ MIT, Apache 2.0 หรือ Creative Commons ได้
    • ตัวอย่างคือ OpenLLaMA
    • LLaMA 2 ของ Facebook อนุญาตการใช้งานเชิงพาณิชย์อย่างชัดเจน แต่ด้วยภาระทางกฎหมายหลายประการ จึงยังมีคำถามสำคัญว่าเป็นโอเพนซอร์สอย่างแท้จริงหรือไม่
  • โมเดลที่อิงสถาปัตยกรรมอื่น เช่น MPT, Falcon และ Open Assistant ไม่ได้รันบน llama.cpp ในเวลานั้น จึงหลุดจากตัวเลือก

การประเมินคุณภาพ อคติ และความปลอดภัยของโมเดล

  • การเลือกโมเดลส่งผลโดยตรงต่อ ความน่าเชื่อถือ ไม่ใช่แค่ไลเซนส์และความเข้ากันได้
  • LLM ถูกเทรนด้วยข้อมูลมหาศาล และถูกปรับละเอียดด้วย input เพิ่มเติมเพื่อสร้างพฤติกรรมและ output บางแบบ
    • การเลือกข้อมูลนี้เองเป็นการ curate และมี อคติ หลากหลายรูปแบบ
  • โมเดลแสดงลักษณะแตกต่างกันตามแหล่งข้อมูลที่ใช้เทรน
    • อาจสร้างคำตอบไร้สาระแบบ hallucination ได้
    • อาจนำไปสู่เนื้อหาเป็นพิษ ข้อมูลเท็จ หรือการแชร์ข้อมูลที่อันตรายหรือเป็นภัยได้
    • อาจแสดงอคติต่อแนวคิดหรือกลุ่มคน
    • การที่สื่อการเรียนรู้ออนไลน์ส่วนใหญ่เป็นภาษาอังกฤษ ส่งผลต่อความสามารถในการใช้เครื่องมือและโลกทัศน์ที่ได้รับ
  • มีแหล่งข้อมูลสำหรับประเมินประสิทธิภาพและคุณภาพ เช่น Open LLM leaderboard ของ Hugging Face แต่การเปรียบเทียบโมเดลตามแหล่งที่มาและอคติยังคงทำได้ยาก
  • ทีม Mozilla จำกัดขอบเขตเหลือโมเดลเปิดที่ใช้งานเชิงพาณิชย์ได้และทำงานบนสถาปัตยกรรม LLaMA แล้วทำ การประเมินด้วยตนเอง โดยถามคำถามหลายข้อเพื่อดูความต้านทานต่อเนื้อหาเป็นพิษ อคติ ข้อมูลเท็จ และเนื้อหาอันตราย
  • ตัวเลือกสุดท้ายคือ LLaMA 2 ของ Facebook แต่ระเบียบวิธีประเมินภายในเวลาจำกัดอาจมีข้อบกพร่อง และยังไม่สบายใจกับเงื่อนไขไลเซนส์ทั้งหมด จึงยากจะถือว่าเป็นคำแนะนำ

การรวมความรู้ภายใน: embedding และ vector search

  • ทีม Mozilla ต้องการเชื่อมข้อมูลภายในของ Mozilla บางส่วนที่พนักงานเข้าถึงได้แต่ LLM ทั่วไปไม่รู้ เข้ากับแชตบอต
  • วิธีที่เลือกคือ embedding และ vector search เพื่อให้ใช้เอกสารภายนอกในการสร้างคำตอบได้
  • ขั้นตอนพื้นฐานมีดังนี้
    • นำข้อมูลที่จะใช้จากที่เก็บเดิมมาแปลงด้วย embedding model
    • จัดทำดัชนี embedding ลงใน vector database ที่แชตบอตเข้าถึงได้
    • เมื่อผู้ใช้ถามคำถาม แชตบอตค้นหาเนื้อหาที่เกี่ยวข้องจาก vector database
    • นำเนื้อหาที่เกี่ยวข้องที่ค้นเจอใส่ใน context window ของโมเดลพื้นฐานเพื่อใช้สร้างคำตอบ
  • ทีมไม่ใช้บริการ embedding หรือ vector database จากบุคคลที่สาม เพื่อคงการควบคุมข้อมูลไว้
  • โซลูชันที่เขียนเองด้วย Python ใช้เครื่องมือต่อไปนี้
  • แม้ขอบเขตจะจำกัดเพราะใส่เอกสารจากวิกิภายในบริษัทเพียงไม่กี่ฉบับ แต่ก็ทำงานได้ในฐานะ proof of concept

Prompt engineering และ context window

  • LLM เริ่มทำงานในสภาพที่ไม่จดจำบทสนทนาก่อนหน้าหรือผู้ใช้ทุกครั้ง ดังนั้นถ้าต้องการให้แชตบอตสนทนาต่อเนื่อง นักพัฒนาต้องทำ memory management
  • system prompt คือ คำสั่งเริ่มต้น ที่ระบุความสามารถและพฤติกรรมของแชตบอตเป็นข้อความธรรมดา
  • ทีม Mozilla ออกแบบ system prompt ให้แชตบอตปฏิบัติตาม Mozilla Manifesto พฤติกรรมที่ให้ความเคารพ และนโยบายไม่เลือกปฏิบัติ
    • เมื่อถามเรื่องทฤษฎีสมคบคิดว่าการลงจอดบนดวงจันทร์ของ Apollo เป็นเรื่องจัดฉาก หากมีคำสั่งให้ปฏิเสธคำตอบที่เป็นข้อมูลเท็จ ก็จะตอบว่าการลงจอดบนดวงจันทร์ไม่ได้ถูกจัดฉาก
    • เมื่อลบข้อความห้ามข้อมูลเท็จออกจากโมเดลเดียวกัน ก็ให้รายการข้ออ้างทั่วไปของกลุ่มที่ปฏิเสธ Apollo
  • system prompt รวมถึงชื่อ Mozilla Assistant การปฏิบัติตามหลัก Mozilla Manifesto ความเคารพ ความเป็นมืออาชีพ ความครอบคลุม การปฏิเสธพฤติกรรมที่เป็นภัย ผิดศีลธรรม ผิดจริยธรรม หรืออาจผิดกฎหมาย และการห้ามข้อมูลเท็จรวมถึงภาษาที่เลือกปฏิบัติ
  • LLM ทุกตัวมี context window ซึ่งเป็นความยาวสูงสุดที่จำได้ในการสนทนาปัจจุบัน
    • ส่วนใหญ่ถูกกำหนดตอนเทรนและเปลี่ยนภายหลังไม่ได้
    • ยิ่ง context window ใหญ่ ก็ยิ่งอ้างอิงคำถามและคำตอบก่อนหน้าได้นานขึ้น
    • และยังใส่ชิ้นเนื้อหาขนาดใหญ่ขึ้นที่ดึงมาจาก vector search ได้ด้วย
  • context window ของ LLaMA 2 คือ 4096 tokens หรือประมาณ 3000 คำ
  • ทีมลดความยาวของ system prompt ซ้ำ ๆ เพื่อประหยัด context window และมีแผนจะพิจารณาโมเดลที่รองรับ context window ใหญ่ขึ้นในอนาคต

การ orchestrate และการเลือก UI

  • แชตบอตทั้งระบบต้องมี orchestration เพื่อประสานหลายชั้น เช่น agent prompt injection, การจัดการ context window, embedding ของเนื้อหาภายใน, การเรียก LLM และการประมวลผล response
  • LangChain ซึ่งเป็นเครื่องมือหลักในวงการ LLM ทรงพลังและยืดหยุ่น แต่ก็มีความซับซ้อนสูง
  • ทีม Mozilla ใช้ LangChain ให้น้อยที่สุด เฉพาะ embedding และ vector search
    • เนื่องจากเป็นโปรเจกต์สั้นและมีข้อจำกัดสูง ส่วนใหญ่จึงจัดการด้วยโค้ด Python ที่เขียนเอง
    • หากมีเวลามากกว่านี้ ก็น่าจะไม่ทำทุกอย่างแบบ manual
  • UI ต้องมีฟังก์ชันมากกว่าที่ดูเหมือนง่าย เช่น การแสดงบทสนทนา การติดตามเธรดก่อนหน้า และการจัดการ backend ที่ส่ง output ด้วยความเร็วไม่สม่ำเสมอ
  • ในบรรดา UI แชตบอตโอเพนซอร์ส chatbot-ui implement OpenAI API ทำให้ใช้ได้เหมือนตัวแทน UI ของ ChatGPT และนำมาใช้เป็น frontend ของระบบ LLM ของตัวเองได้ง่าย
  • โดยปกติทีม Mozilla น่าจะใช้โปรเจกต์อย่าง chatbot-ui แต่เนื่องจากมีโค้ดแชตบอตสำหรับทดลองภายในชื่อ Companion และผู้เขียนอยู่ร่วมด้วย จึงใช้สิ่งนี้เป็น UI
    • Companion ช่วยให้ iterate และทดลอง UI ได้อย่างรวดเร็ว

ผลลัพธ์แฮกกาธอนและงานที่ยังเหลือ

  • เมื่อแฮกกาธอนจบ ทีม Mozilla ทำต้นแบบแชตบอตสำหรับใช้ภายในเสร็จ
    • โฮสต์ทั้งหมดภายใน Mozilla
    • ใช้งานได้อย่างปลอดภัยและเป็นส่วนตัว
    • พยายามสะท้อนค่านิยมของ Mozilla ในพฤติกรรม
  • การบรรลุเป้าหมายต้องผ่านการตัดสินใจและการประนีประนอมที่ยากหลายอย่าง
  • สิ่งที่ได้เรียนรู้สรุปได้เป็นสามข้อ
    • แชตบอตโอเพนซอร์สยังอยู่ระหว่างวิวัฒนาการ มีเรื่องต้องตัดสินใจจำนวนมาก เอกสารที่ชัดเจนยังไม่พอ และมีหลายวิธีที่จะล้มเหลว
    • การประเมินและเลือกโมเดลด้วยเกณฑ์นอกเหนือจาก performance ดิบทำได้ยากเกินไป ทำให้การเลือกที่ถูกต้องสำหรับแอป AI ที่เชื่อถือได้ก็ยากตามไปด้วย
    • ณ ตอนนี้ prompt engineering ที่มีประสิทธิภาพมีความสำคัญต่อความสำเร็จของแชตบอต
  • Mozilla เริ่มสร้างวิธีให้ developer เข้าสู่ ecosystem ของแมชชีนเลิร์นนิงโอเพนซอร์สได้ง่ายขึ้น และตั้งใจจะนำงานจากแฮกกาธอนไปมีส่วนร่วมกับชุมชนโอเพนซอร์ส
  • ในสถานการณ์ที่ LLM โอเพนซอร์สมีให้ใช้อย่างแพร่หลาย หากต้องการสร้างอนาคตที่ดีกว่า ทุกคนต้องร่วมกันและลงมือมีส่วนในการกำหนดมัน

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

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

 
GN⁺ 2023-07-31
ความคิดเห็นจาก Hacker News

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

    • ผมทำเว็บซัพพอร์ตให้หลายบริษัทมาหลายปี และจากการสำรวจพบว่า ลูกค้ามากกว่า 40% ไม่ได้ลองค้นหาคำตอบก่อนติดต่อทีมซัพพอร์ตเลย
      ดังนั้นจึงมีเว็บจำนวนมากที่แสดงคำถามจำนวนมากเพื่อแนะนำคำตอบที่เกี่ยวข้องจากคำอธิบาย ก่อนจะให้ติดต่อทีมซัพพอร์ต และ AWS Support ก็ทำแบบนั้น
      บอตอาจน่าหงุดหงิด แต่ก็ลดต้นทุนซัพพอร์ตลูกค้าได้มาก ถ้าประสบการณ์ผู้ใช้ดี และเมื่อบอตตอบไม่ได้ก็ส่งต่อไปยังเจ้าหน้าที่ได้เร็ว ผมก็เห็นด้วย แน่นอนว่าต้องอยู่บนเงื่อนไขว่าบอตจะไม่ hallucinate แล้วพูดข้อมูลปลอมออกมา
    • ผมกำลังทำ micro SaaS ที่มีรายได้ต่อเดือนสี่หลัก
      เราใช้แชตบอตเพราะไม่มีพนักงานซัพพอร์ตคอยตอบคำถาม ถ้าไม่มีบอตก็เท่ากับไม่มีอะไรเลย
      แต่เราคอยมอนิเตอร์ล็อกของบอต หากมีฟีเจอร์ที่ขาดไปในผลิตภัณฑ์หรือเว็บไซต์ เราก็เพิ่มเข้าไป เพื่อให้ผู้ใช้ในภายหลังจัดการเองได้แบบ self-service อย่างสมบูรณ์
      ผู้ใช้สามารถยกเลิกบัญชีหรือขอคืนเงินได้ทุกเมื่อ
    • ผมเคยทำงานซัพพอร์ตเทคนิค ผู้ใช้แบบนั้นแทบจะเป็นข้อยกเว้นเสียมากกว่า คำถามส่วนใหญ่จากลูกค้าเป็นแนว “ต้องทำอย่างไร”
      สำหรับคำถามแบบนี้ large language model แทบจะเหมาะอย่างสมบูรณ์ เพียงแต่อยากให้ปรับปรุงให้บอตตรวจจับคำถามที่มันตอบเองไม่ได้ได้ดีขึ้น
    • ผมเองก็ติดต่อด้วยเหตุผลแบบนั้นเหมือนกัน แต่ในความเป็นจริง การโทรหรือการโต้ตอบส่วนใหญ่ดูเหมือนจะไม่ใช่แบบนั้น หลายคน ค้นหาหรือหาเนื้อหาเองไม่เจอ
    • เห็นด้วย โดยทั่วไปวิศวกรมักพยายามแก้ปัญหาที่ไม่ใช่ปัญหาเชิงเทคนิคด้วยเทคโนโลยีที่มากขึ้น
      แน่นอนว่ามีกรณีที่แชตบอตสามารถแทนคนหรือ FAQ ที่เขียนดี ๆ ได้ แต่ความพึงพอใจในตัวเองแบบนี้พลาดเหตุผลหลักที่ทำให้ซัพพอร์ตเลวร้าย นั่นคือมันถูกออกแบบมาแบบนั้นตั้งแต่แรก
      ลองดูตัวอย่าง “ยกเลิกได้เฉพาะทางโทรศัพท์” การสมัครหรือ upsell เป็นปัญหาทางเทคนิคที่ยากกว่าด้วยซ้ำ แต่กลับทำให้ง่ายกว่ามาก เป้าหมายคือเพิ่มแรงเสียดทานให้กับพฤติกรรมที่ดูเหมือนเป็นต้นทุนหรือการสูญเสียระยะสั้น บริษัทต่าง ๆ รู้ดีว่าหากมีแรงเสียดทาน หลายคนจะล้มเลิกหรือผัดผ่อน
      นี่คือแพราดายม์ของ nudge และ dark pattern ดูได้จากแบนเนอร์คุกกี้ที่ปุ่ม “ปฏิเสธทั้งหมด” ส่วนใหญ่ถูกซ่อนเอาไว้ nudge ทำให้บริษัทดูเหมือนปฏิบัติตามกฎหมาย ขณะเดียวกันก็หลบเลี่ยงผลโดยรวมโดยให้เวล่าและความสนใจของผู้ใช้เป็นต้นทุน
      แชตบอตก็เป็นเพียงอีกชั้นหนึ่งที่เพิ่มเข้าไปในเขาวงกตของซัพพอร์ต

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

    • พูดตามตรง ลูกค้า 99% ไม่อ่านเอกสาร ไม่อ่าน FAQ และไม่ค้น Google ผู้ใช้ขี้เกียจทำให้เสียเวลา และถ้าแชตบอตกรองคนจำนวนมากในนั้นออกไปได้ ก็อาจเป็นกำไรสุทธิต่อมนุษยชาติโดยรวม
      แชตบอตไม่ใช่ยาครอบจักรวาล แต่ลด noise ที่ไม่จำเป็นได้มาก สิ่งที่ต้องการคืออะไรบางอย่างที่ตอบ คำถามพื้นฐาน ที่ผู้ใช้ทั่วไปถามในโดเมนเฉพาะนั้นได้
    • ผมไม่คิดว่าแชตบอตสำหรับลูกค้าจะมีคุณค่ามากนัก แต่แชตบอตสำหรับพนักงานภายในเท่านั้นอาจมีประโยชน์มากจริง ๆ ขึ้นอยู่กับองค์กร
      ที่ทำงานเก่าของผมเป็นบริษัทค่อนข้างใหญ่ และอินสแตนซ์ Confluence ก็ใหญ่มหาศาล ผมเสียเวลาไปมากกับการหาข้อมูลในนั้น ถ้ามีแชตบอตที่ฝึกจากข้อมูลทั้งหมดนั้น ก็น่าจะมีประโยชน์มากทีเดียว
    • พูดตามตรง แชตบอตบางตัวก็ให้ประสบการณ์ที่ดีเหมือนกัน
      นึกถึง Amazon ผมเป็นลูกค้ามานาน และเมื่อไม่นานมานี้ได้รับอุปกรณ์ต่อพ่วงคอมพิวเตอร์ที่มีตำหนิ
      ผมอธิบายปัญหาสั้น ๆ กับแชตบอต มันก็สร้างคำสั่งซื้อใหม่ทันที และบอกว่าของเดิมที่ได้รับให้เก็บไว้ได้เลย พร้อมจัดส่งแบบเร่งด่วนโดยไม่คิดค่าใช้จ่ายเพิ่ม
      แค่นั้นเอง และของก็มาถึงวันถัดไป ใช้งานได้ดี
      แน่นอนว่ามันคงรู้ว่าผมเป็นลูกค้าเก่าและใช้เงินไปมากแล้ว แต่นั่นแทบจะเป็นประสบการณ์ที่ไร้ความเจ็บปวดที่สุดเท่าที่จินตนาการได้ ดีกว่าการคลิกตัวเลือกไปตามหน้าเว็บหลายหน้าอย่างมาก
    • เหมือนกับที่มีอาหาร รับรอง BIO หลายแบบ บางทีตอนนี้เราอาจต้องมีบริษัท “รับรองว่าเป็นมนุษย์” แล้ว ถ้าสามารถแก้ปัญหากับคนได้ ผมยินดีจ่ายเงินเข้าบัญชีธนาคารเพิ่ม
    • ความเสี่ยงใหญ่ที่สุดของ AI ไม่ใช่การได้อำนาจอิสระแล้วหลบหนี แต่คือการที่มนุษย์เอา AI ไปวางเป็นผู้รับผิดชอบในทุกที่
      “ท่านผู้พิพากษา คำแก้ต่างทั้งหมดของผมเป็นเรื่องไร้สาระและอ้างอิงข้อกฎหมายที่ไม่มีอยู่จริง แต่เป็นเพราะผมใช้ ChatGPT ครับ” — เป็นทนายความที่เกิดขึ้นจริง และแม้แต่ใบอนุญาตทนายก็ยังไม่ถูกเพิกถอน

  • วลีที่ว่า “กำลังเปลี่ยนเว็บที่เรารู้จักและรักไปแล้ว” นั้นเป็นการจับผิดถ้อยคำและชัดเจนว่าออกนอกประเด็น แต่ผมไม่ได้รัก เว็บ ในปัจจุบัน
    เว็บกำลังถูกควบคุมโดยบริษัทไม่กี่แห่งมากขึ้นเรื่อย ๆ พวกเขาเป็นคนตัดสินว่าเนื้อหาใดจะถูกมองเห็น (meta, google) และอีเมลใดจะถูกส่งไปยังตัวกรองสแปม (ms, google)
    เว็บในตอนนี้ห่างไกลจากคำว่ารักมาก แม้แต่การเข้าถึงคนที่เลือกติดตามผมเอง ผมก็ยังต้องสู้ต่อเนื่อง
    สุดท้ายการสื่อสารส่วนใหญ่ของผมเกิดขึ้นในโลกจริงหรือแชตส่วนตัว ขอเสริมด้วยว่า messenger สำหรับธุรกิจนั้นแย่และไม่เสถียรเพียงใด
    เว็บในวันนี้จำเป็นต้องมีบางอย่างเกิดขึ้น ผมไม่รู้ว่าอะไรและอย่างไร แต่การเปลี่ยนแปลงย่อมเป็นสิ่งที่ต้อนรับแน่นอน

    • แค่ให้ RSS feed ก็พอแล้ว สิ่งที่ขัดขวางไม่ให้ผู้คนติดตามสิ่งนั้นได้ก็มีแค่ Google Safe Browsing ประมาณนั้น
      ยังควรมีวิธีอื่น ๆ ทั้งหมดที่ทำให้ผู้คนติดตามได้อยู่ดี แต่ถ้าโปรโมต RSS feed ผู้คนก็อาจเริ่มใช้มัน
      ถ้าอยากลองทำเชิงเทคนิค ก็สามารถตั้งค่า ActivityPub bridge เพื่อให้ติดตามบนโซเชียลมีเดียได้ด้วย ถ้าใช้ Wordpress ก็มี https://wordpress.org/plugins/activitypub/

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

    • ถ้าพูดอย่างเป็นธรรม ถ้าทางเลือกคือ “การค้นหาใน Confluence” ไม่ว่าจะเป็นแชตบอตหรือเสิร์ชเอนจินของบุคคลที่สามที่วางทับบนข้อมูล Confluence แทบอะไรก็ดีกว่าทั้งนั้น
      การค้นหาของ Confluence นี่เป็นมุกตลกจริง ๆ แถมเป็นมุกที่แย่ด้วย
    • พอจะรู้ไหมว่าสร้างอย่างไร? ผมก็อยากลองทำแบบเดียวกัน

  • ลูกค้าใช้แชตบอตเพราะ UI ของเว็บไซต์ชวนสับสน พวกเขาอยากได้ข้อมูลแต่หาวิธีไม่เจอ
    สมัยก่อนก็จะค้นใน Google ว่า “ชื่อบริการ + เบอร์โทรศัพท์” หรือ “ชื่อบริการ + ยกเลิกการสมัครสมาชิก”
    เก้าในสิบครั้ง เว็บไซต์ไม่ได้อยากให้เบอร์โทรศัพท์ง่าย ๆ หรือทำให้การยกเลิกการสมัครสมาชิกง่าย ๆ อยู่แล้ว ถ้าตั้งแต่แรกก็ไม่อยากให้ลูกค้าทำการกระทำที่ซ่อนไว้แบบนั้น แล้วแชตบอตมีไว้เพื่ออะไรกันแน่?
    ผมเคยทำงานในช่วงกระแสแชตบอต และต้องบอกลูกค้าหลายรายว่า ถ้าพวกเขาไม่มีความตั้งใจจะช่วยลูกค้าจริง ๆ สิ่งที่เราทำได้ก็มีไม่มาก

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

  • เขาบอกว่า “เราได้ตั้งเซิร์ฟเวอร์เสมือนของเราเองภายในบัญชี Google Cloud Platform (GCP) เดิมของ Mozilla ด้วยวิธีนั้น โดยพฤตินัยแล้วเท่ากับเราตัดสินใจทำ MLOps เอง แต่เราสามารถเดินหน้าต่อไปได้ด้วยความมั่นใจว่าระบบเป็นแบบส่วนตัวและอยู่ภายใต้การควบคุมของเราอย่างสมบูรณ์” แล้วการตั้งเซิร์ฟเวอร์ภายในโครงสร้างพื้นฐานของ Google เป็น ส่วนตัว และอยู่ภายใต้การควบคุมอย่างสมบูรณ์ของ Mozilla ได้อย่างไร?

    • เมื่อเทียบกับการส่งงานแมชชีนเลิร์นนิงไปให้ API ของบุคคลที่สาม การใช้ VPS ถือว่าเป็นส่วนตัวและควบคุมได้มากกว่า
      การอธิบายไปถึงวิธีโฮสต์เองบนเบयरเมทัลนั้นอยู่นอกขอบเขตของบทความสร้างแชตบอต และการทำเหมือนว่า VPS ของ Google Cloud ไม่ปลอดภัยก็ดูฝืนไปหน่อย
    • GCP ปฏิบัติตามมาตรฐานอุตสาหกรรม กฎระเบียบ และการรับรองหลายอย่างที่พิสูจน์การควบคุมด้านความปลอดภัยและการคุ้มครองข้อมูลส่วนบุคคล การรับรองเหล่านี้ให้ความมั่นใจเพิ่มเติมได้ว่าข้อมูลถูกประมวลผลตามมาตรฐานที่ได้รับการยอมรับ
      ISO 27001 เป็นมาตรฐานสากลสำหรับระบบบริหารจัดการความมั่นคงปลอดภัยสารสนเทศ และการปฏิบัติตามของ GCP แสดงถึงคำมั่นต่อการปกป้องข้อมูล
      ISO 27017 มุ่งเฉพาะด้านความปลอดภัยบนคลาวด์ และเน้นการควบคุมที่เฉพาะกับผู้ให้บริการคลาวด์
      ISO 27018 เป็นมาตรฐานที่เกี่ยวข้องกับการคุ้มครองข้อมูลที่ระบุตัวบุคคลได้ในคลาวด์สาธารณะ
      รายงาน SOC 2 สามารถให้ความมั่นใจเกี่ยวกับการควบคุมด้านความปลอดภัย ความพร้อมใช้งาน ความถูกต้องครบถ้วนของการประมวลผล การรักษาความลับ และการคุ้มครองข้อมูลส่วนบุคคล
      หากจัดการข้อมูลทางการแพทย์ ก็จำเป็นต้องปฏิบัติตาม HIPAA และหากจัดการข้อมูลของยุโรปหรือพลเมืองยุโรป การปฏิบัติตาม GDPR ก็สำคัญ
      หากเป็นลูกค้าหน่วยงานรัฐบาลสหรัฐฯ การปฏิบัติตาม FedRAMP อาจเป็นข้อบังคับ และหากประมวลผลข้อมูลบัตรเครดิต การปฏิบัติตาม PCI DSS ก็สำคัญ
      ควรตรวจสอบว่าบริการที่จะใช้ภายใน GCP อยู่ในขอบเขตการรับรองที่จำเป็นสำหรับอุตสาหกรรมหรือกรณีใช้งานนั้น ๆ หรือไม่ โดยปกติการรับรองเหล่านี้ตรวจสอบได้บนเว็บไซต์ Google Cloud และหากต้องการเอกสารทางการ ก็อาจขอผ่านฝ่ายขายหรือทีมสนับสนุนของ Google ได้

  • ถ้าสงสัยว่าในทางปฏิบัติจะสร้าง โมเดลแชตฐานข้อมูลเวกเตอร์ แบบนี้อย่างไร ไลฟ์สตรีมสัปดาห์ที่แล้วได้แสดงขั้นตอนการสร้างในสภาพแวดล้อม Colab แทบตั้งแต่ต้น และทำ inference ด้วย Llama 2 https://www.youtube.com/live/kBB1A2ot-Bw?feature=share
    ความท้าทายใหญ่ของโครงสร้างแบบนี้คือการทำ semantic similarity search ในสเกลใหญ่ Pinecone มีเอกสารเรื่องโครงสร้างข้อมูลสำหรับขยายฐานข้อมูลเวกเตอร์ขนาดใหญ่ที่ค่อนข้างดี

  • ผมรอให้ Mozilla กระโดดเข้ามาในกระแสนี้และพัฒนา โมเดลภาษาขนาดใหญ่ ของตัวเองอยู่ เมื่อคิดถึงพันธกิจขององค์กรที่ว่า “รักษาให้อินเทอร์เน็ตเปิดกว้างและเข้าถึงได้สำหรับทุกคน” ก็สมเหตุสมผลมาก เพียงแต่ไม่รู้ว่ามีทรัพยากรหรือความตั้งใจจะทำหรือไม่

  • เขาบอกว่า “มีเหตุผลที่การดำเนินงานแมชชีนเลิร์นนิง หรือ MLOps เป็นสาขาที่กำลังเติบโต การ deploy และจัดการแอปแบบนี้เป็นเรื่องยาก ต้องใช้ความรู้และทักษะเฉพาะที่นักพัฒนาและผู้ดูแลระบบจำนวนมากยังไม่มี” แล้วอะไรที่ยากหรือแตกต่างขนาดนั้น?
    ผมเข้าใจว่ามันคือการรันเว็บ API ที่โหลดโมเดลซึ่งเป็นแอสเซ็ตที่คอมไพล์แล้ว ในแง่นั้นก็ดูไม่ได้ต่างกันมาก