LLM Note 1

---

LLM Note 1

Data Mastery Series — Episode 46: Hands-On Demos, Memory, Behavior Monitoring & Security Insights

Connect with me and follow our journey: Linkedin, Facebook

---

Welcome back to the Data Mastery Series! ถ้าใครติดตามมาถึงตอนนี้ เราได้ศึกษา Basic LangChain และ Basic LangGraph กันไปแล้ว สำหรับใครที่สนใจสามารถย้อนดูได้ที่ link ด้านล่าง:

• Langchain v0.1 (Part 1–17)
• LangGraph (Part 18–19)

Blog นี้เป็นพื้นที่ที่ผมใช้ Note เนื้อหาที่ได้เรียนรู้ จากการอ่านข้อมูล LLM จากแหล่งข้อมูลต่าง ๆ ใครอยากเรียนรู้ไปพร้อมกันในสไตล์ง่าย ๆ สามารถอ่านต่อได้เลยครับ!

1. LangChain Hands-on

1.1) Demo ที่ 1: One-shot Q&A

จากเนื้อหา Langchain v0.1 (Part 1–17) ผมได้นำมาประยุกต์เข้าด้วยกัน โดย Demo แรก จะเน้นไปที่ One-shot Q&A ซึ่งออกแบบให้ทำงานใน Local ผู้ใช้สามารถ Upload File และทดสอบ Prompt เพื่อสร้างคำตอบเฉพาะงาน ตัวอย่างการใช้งาน:

• การดึงข้อมูลเข้า Excel format
• สรุปเนื้อหาในวิดีโอ
• สร้างบทสรุปจากเอกสาร PDF

ใช้เพื่อทดสอบ Prompt ในงานที่ต้องการ Output ในรูปแบบ Specific ต่างๆ ทำให้สามารถตรวจสอบผลลัพธ์ที่เกิดขึ้นได้อย่างว่องไว โดย Feature หลักใน Demo นี้คือ

• Prompt Testing: ทดสอบและปรับ Tune Prompt ให้ได้ผลลัพธ์ตามต้องการ
• Retriever Analysis: เจาะลึกการทำงาน เช่น ปรับ Chunk Size, Embedding Model, และ Prompting เพื่อให้ Model ดึงข้อมูล (Retrieve) ได้อย่างแม่นยำ

Figure: Example of One-shot Q&A Demo

1.2) Demo ที่ 2: Chat Application

Demo นี้ต่อยอดจาก One-shot Q&A ไปสู่ Chat Application ที่มีลักษณะคล้าย ChatGPT พร้อมเพิ่มฟีเจอร์

• การสนทนาต่อเนื่อง
• การทดสอบ Retriever Methods รูปแบบต่าง ๆ และการปรับ Hyperparameters เช่น K (จำนวนผลลัพธ์ที่ดึงมา) และ Similarity Threshold (ค่าความใกล้เคียงของข้อมูล)

เป้าหมายคือการสร้าง Workflow ที่สามารถปรับใช้กับงานลูกค้าได้อย่างรวดเร็วและมีประสิทธิภาพ

Figure: Example of Chat Application Demo

ในงานจริง การพัฒนาแอปพลิเคชันแบบนี้ต้องพิจารณาเพิ่มเติมในหลายด้าน เช่น

• Features: การแสดง Citation หรือแหล่งที่มาของข้อมูล, การจัดการ Chain History และ Memory Management, LLM/Gen AI Operation
• Other Considerations: UX/UI Design, Data Pipeline, Vector Database, Logging และ Monitoring รวมถึงปัจจัยอื่น ๆ อีกมากมาย

---

2. LLM Memory Management

(Source) แม้ LLM ปัจจุบันจะรองรับ Token มากขึ้น แต่การจัดการ Memory ยังคงสำคัญ โดยเฉพาะการสร้างแชทบอทที่ต้องใช้ Context Management:

2.1) Short-Term Memory (Intra-Conversation Memory)

การสร้าง Chatbot จะเป็นต้องสนใจ Context Management เนื่องจาก GPT API ไม่มีการเก็บสถานะ (Stateful Memory) วิธีแก้ปัญหาที่ใช้ได้:

• Buffering: บันทึกข้อความทุกข้อความในบทสนทนาและส่งกลับไปพร้อมกับคำขอใหม่ทุกครั้ง ถ้าเจอ Token limit ให้ใช้ Buffer Window Memory ตัดข้อความที่เกินขอบเขตออก เช่น ข้อความเก่าที่เกิน 10 ข้อความล่าสุด
• Summarization: สรุปข้อความก่อนหน้าด้วย LLM และแนบไปกับคำขอใหม่ เช่น สรุปข้อความทุก ๆ X ครั้ง หรือสรุปข้อความใหม่เฉพาะส่วนที่เพิ่มเติม แล้วแนบสรุปเหล่านี้แทนประวัติทั้งหมด อาจใช้ร่วมกับ Buffer ได้เพื่อเพิ่มประสิทธิภาพ
• Entity Memory: เก็บข้อมูลเกี่ยวกับ entity เช่น คน สถานที่ สิ่งของ ในรูปแบบ Dictionary
• Knowledge Graph Memory: สร้าง knowledge graph ที่แสดงความสัมพันธ์ระหว่าง entity ต่างๆ (Note: อันนี้ผมยังไม่เคยลอง)
• Vector Store/Database: เก็บประวัติการสนทนาในรูปแบบเวกเตอร์ และค้นหาข้อความที่เกี่ยวข้อง (Top-K Relevant Messages)

2.2) การจัดการ Long-Term Memory ด้วย Vector Database

ผู้ใช้ส่วนใหญ่อยากให้ Chatbot จำข้อมูลได้ข้าม Session หรือมีข้อมูลเยอะ ๆ เป็นแหล่งความรู้ วิธีแก้คือ ใช้ Vector Database ซึ่งมีองค์ประกอบหลักดังนี้:

1. Chunking: แบ่งเอกสารยาว ๆ เป็น Chunk เล็ก ๆ
2. Embedding: แปลง Chunk เป็น Vector Embedding เพื่อให้ LLM เข้าใจความหมาย
3. Storing: เก็บ Embedding ใน Vector Database
4. Retrieving: ดึง Chunk ที่เกี่ยวข้องจาก Vector Database เมื่อมีคำถาม
5. Prompting: ใส่ Chunk ที่ดึงมาได้ใน Prompt เพื่อให้ LLM ตอบคำถาม

รายละเอียดเหล่านี้ผมเคยพูดถึงใน Langchain v0.1 (Part 1–17) แล้ว แต่ด้านล่างนี้ผมจะสรุปประเด็นที่สำคัญอีกครั้ง:

• Retrieval: อาทิการใช้ KNN (K-Nearest Neighbors) หา chunk ที่ใกล้เคียงกับคำถามมากที่สุด โดยใช้ Euclidean distance, cosine similarity หรืออื่นๆ
  - Stuffing: เอา chunk ที่ดึงมาทั้งหมดใส่ใน prompt (อาจติด context limit)
  - Map-Reduce: สรุป Chunk แต่ละอัน และรวมสรุปอีกครั้ง
  - Refine: ใช้ Chunk แรกสร้างคำตอบ แล้วปรับปรุงด้วย Chunk ถัดไป (เหมาะกับคำถามที่ต้องใช้หลาย chunk แต่มีลำดับ)
  - Map Rerank: จัดอันดับคำตอบตามคะแนนความมั่นใจ (เหมาะกับคำถามที่ตอบได้ด้วย chunk เดียว)

2.3) ประเด็นอื่นๆที่น่าสนใจ

• การจัดรูปแบบ Output: กำหนดรูปแบบที่ต้องการโดยใช้ System Role Parameter, Prompt Engineering และ Output Parser
• การทำ Caching: ทำ Caching คำตอบของ LLM เพื่อลดค่าใช้จ่ายและเพิ่มประสิทธิภาพ

---

3. LLM Behavior Monitoring

(Source) การพัฒนาแอปพลิเคชันที่ใช้ LLM จำเป็นต้องติดตามและประเมินพฤติกรรมของโมเดลอย่างสม่ำเสมอ เพื่อแก้ไขปัญหา เช่น การสร้างข้อมูลที่ไม่จริง (Hallucination), อคติ (Bias), หรือเนื้อหาที่ไม่เหมาะสม

3.1) 7 Metrics for LLM Evaluation

• ROUGE: วัดความเหมือนของคำตอบ LLM กับคำตอบอ้างอิง
  - เปรียบเทียบคำตอบของ ChatGPT กับ human reference answers 3 คำตอบ
  - ROUGE-L: พิจารณา sequence overlap ที่ยาวที่สุด
  - ROUGE-2: พิจารณา bigram overlap (การทับซ้อนของคำ 2 คำติดกัน)
  - คำนวณ f-score, precision, และ recall
• Gender Bias: วัดความลำเอียงทางเพศในการใช้คำ
  - นับจำนวนคำที่อยู่ในกลุ่มคำที่สื่อถึงเพศหญิง (Afemale) และเพศชาย (Amale) ในทุกคำตอบ
  - เปรียบเทียบ distribution ที่ได้กับ reference unbiased distribution โดยใช้ total variation distance
  - ตัวอย่างกลุ่มคำที่ใช้:
  — Afemale: “she”, “daughter”, “hers”, “her”, “mother”, “woman”, “girl”, …
  — Amale: “he”, “son”, “his”, “him”, “father”, “man”, “boy”, …
• Text Quality: วัดคุณภาพของข้อความ เช่น ความเข้าใจง่าย
  - ประเมินความอ่านง่าย (Readability), ความซับซ้อน (Complexity) และระดับการศึกษา (Grade Level) ที่เหมาะสมกับข้อความ
  - ใช้ Library เช่น TextStat เพื่อวัดคุณภาพข้อความ เช่น Flesch Reading Ease และ Automated Readability Index
• Semantic Similarity: วัดความเกี่ยวข้องของคำตอบกับคำถาม
  - วัดความสัมพันธ์เชิงความหมายระหว่างคำถามและคำตอบ
  - ใช้ Cosine Similarity เพื่อเปรียบเทียบ Sentence Embeddings
• Regex Patterns: ตรวจสอบข้อมูลที่ไม่ถูกต้อง เช่น เบอร์โทรศัพท์
  - ตรวจจับข้อความที่ไม่เหมาะสม เช่น หมายเลขโทรศัพท์, หมายเลขบัตรเครดิต, หรือข้อมูลที่อาจเป็นอันตราย
  - ใช้ Regex Patterns เพื่อตรวจสอบ Output ของโมเดล
• Refusals: ตรวจสอบการปฏิเสธคำถาม
  - วัดจำนวนคำตอบที่เป็นการปฏิเสธ เช่น “I’m sorry, but I can’t assist with that request.”
  - การเพิ่มหรือลดการปฏิเสธอาจบ่งบอกถึงความระมัดระวังของโมเดล
• Toxicity and Sentiment: วัดความเป็นพิษและความรู้สึกของคำตอบ
  - Sentiment Analysis: วัดโทนข้อความว่ามีความเป็นบวกหรือไม่
  - Toxicity Analysis: ตรวจสอบการใช้คำที่ไม่เหมาะสมหรือมีความรุนแรง

---

4. OWASP Top 10 for LLM Applications

(Source) โครงการ OWASP Top 10 ได้รวบรวม 10 ความเสี่ยงสำคัญด้านความปลอดภัยของแอปพลิเคชัน LLM พร้อมคำแนะนำในการป้องกัน:

1) Prompt Injection (การแทรกแซงคำสั่ง)

• ปัญหา: แทรกคำสั่งที่เป็นอันตรายลงใน prompt เพื่อควบคุม LLM
  - Direct prompt injection: แทรกคำสั่งโดยตรงใน prompt หลัก
  - Indirect prompt injection: แทรกคำสั่งผ่านข้อมูลภายนอก เช่น เว็บเพจ
• ตัวอย่าง: ผู้โจมตีแทรกคำสั่งใน prompt เพื่อให้ chatbot แสดงข้อมูลลับ
• ผลกระทบ: อาจนำไปสู่การโจรกรรมข้อมูล (Data Exfiltration), Social Engineering หรือการควบคุมโมเดลโดยไม่ได้รับอนุญาต
• วิธีป้องกัน:
  - จำกัดสิทธิ์การเข้าถึง LLM (Privilege Control)
  - แยกเนื้อหาจากภายนอก (External Content) ออกจาก User Prompt
  - สร้างขอบเขตความไว้วางใจ (trust boundaries) ระหว่าง LLM, แหล่งข้อมูลภายนอก และฟังก์ชันที่สำคัญ
  - เพิ่มกลไกตรวจสอบ เช่น Human in the Loop

2) Insecure Output Handling (การจัดการ output ที่ไม่ปลอดภัย)

• ปัญหา: ยอมรับการสร้าง Output จาก LLM ที่ไม่ปลอดภัย โดยไม่มีการตรวจสอบที่เหมาะสม
• ตัวอย่าง:
  - output ของ LLM ถูกนำไปรันในระบบ shell โดยตรง ทำให้เกิด remote code execution
  - LLM สร้าง JavaScript หรือ Markdown ที่เป็นอันตราย แล้วส่งกลับให้ผู้ใช้ ทำให้เกิด XSS
• ผลกระทบ:
  - XSS (Cross-Site Scripting): เมื่อแฮกเกอร์ฝังโค้ดอันตรายลงในหน้าเว็บ เช่น กล่องข้อความ หรือช่องกรอกข้อมูล ทำให้ผู้ใช้เห็นหรือรันโค้ดนั้นโดยไม่รู้ตัว เช่น ขโมยข้อมูลส่วนตัว
  - CSRF (Cross-Site Request Forgery): เมื่อแฮกเกอร์หลอกผู้ใช้ให้ทำคำสั่งบางอย่างโดยไม่รู้ตัว เช่น โอนเงิน หรือลบข้อมูล โดยใช้สิทธิ์ของผู้ใช้บนเว็บไซต์ที่ผู้ใช้ล็อกอินอยู่
  - SSRF (Server-Side Request Forgery): เมื่อแฮกเกอร์ส่งคำขอให้เซิร์ฟเวอร์ทำสิ่งที่ไม่ได้รับอนุญาต เช่น เข้าถึงระบบภายในของเซิร์ฟเวอร์เอง
  - Privilege Escalation (การยกระดับสิทธิ์): เมื่อแฮกเกอร์เจาะระบบเพื่อเพิ่มสิทธิ์ตัวเอง เช่น จากผู้ใช้ทั่วไปกลายเป็นผู้ดูแลระบบ
  - Remote Code Execution (RCE): เมื่อแฮกเกอร์สามารถรันโค้ดในระบบจากระยะไกลได้ เช่น สั่งให้เซิร์ฟเวอร์ทำงานบางอย่างตามที่ต้องการ
• วิธีป้องกัน:
  - ตรวจสอบ input ที่มาจาก LLM ก่อนนำไปใช้ใน backend functions
  - เข้ารหัส Output (Encoding) เพื่อป้องกันการตีความที่ไม่พึงประสงค์

3) Training Data Poisoning (การปนเปื้อนข้อมูลการฝึก)

• ปัญหา: การป้อนข้อมูลฝึกสอน (Training Data) ที่บิดเบือนหรือเป็นอันตราย อาจทำให้เกิด Bias, Backdoor หรือการโจมตีอื่น ๆ
• ตัวอย่าง:
  - ผู้ไม่หวังดีสร้างเอกสารที่ไม่ถูกต้องเพื่อใส่ใน training data
  - โมเดลถูกฝึกด้วยข้อมูลที่ไม่ถูกต้อง ทำให้ output สะท้อนข้อมูลผิด ๆ
• ผลกระทบ: ประสิทธิภาพลดลง, การถูกโจมตีผ่านซอฟต์แวร์, ชื่อเสียงเสียหาย
• วิธีป้องกัน:
  - ตรวจสอบแหล่งข้อมูล (Data Source) อย่างเคร่งครัด
  - ใช้ filters สำหรับ training data หรือแหล่งข้อมูลบางประเภท

4) Model Denial of Service (DoS) (การปฏิเสธการให้บริการของโมเดล)

• ปัญหา: การที่ผู้โจมตีทำให้ LLM ทำงานหนักเกินไป จนไม่สามารถให้บริการผู้ใช้อื่นได้
• ตัวอย่าง:
  - ส่ง queries ที่ทำให้เกิดการใช้ resource ซ้ำ ๆ
  - ส่ง input เกิน context window ของ LLM
• ผลกระทบ: คุณภาพการบริการลดลง, ค่าใช้จ่ายสูง
• วิธีป้องกัน:
  - กำหนดขอบเขตการใช้ทรัพยากร (Rate Limiting)
  - ตรวจสอบและกรอง Input เพื่อป้องกันการใช้งานที่ไม่เหมาะสม

5) Supply Chain Vulnerabilities (ช่องโหว่ในห่วงโซ่อุปทาน)

• ปัญหา: ช่องโหว่ที่เกิดจากส่วนประกอบต่าง ๆ ในระบบ LLM เช่น training data, ML models, และ deployment platforms
• ตัวอย่าง:
  - ใช้ third-party packages ที่ outdated
  - การฝึกโมเดลด้วยข้อมูลที่ไม่ปลอดภัย
  - ไม่มี visibility (การมองเห็น) ใน supply chain
• ผลกระทบ: ผลลัพธ์ bias, การละเมิดความปลอดภัย, ระบบล่ม
• วิธีป้องกัน:
  - ใช้ Library ที่ผ่านการตรวจสอบความปลอดภัย
  - ติดตามและอัปเดต Software Supply Chain อย่างสม่ำเสมอ
  - ใช้ MLOps best practices สำหรับ models ของตัวเอง

6) Sensitive Information Disclosure (การเปิดเผยข้อมูลที่ละเอียดอ่อน)

• ปัญหา: LLM เปิดเผยข้อมูลลับโดยไม่ตั้งใจ เช่น algorithms, ข้อมูลส่วนตัว, ข้อมูลที่เป็นความลับ
• ตัวอย่าง: การเปิดเผยข้อมูลลับเนื่องจากความผิดพลาด
• ผลกระทบ: การเข้าถึงข้อมูลโดยไม่ได้รับอนุญาต, การขโมยทรัพย์สินทางปัญญา, การละเมิดความเป็นส่วนตัว
• วิธีป้องกัน:
  - ใช้เทคนิค Data Sanitization เพื่อการตรวจสอบและปรับแก้ข้อมูลที่เข้ามา เพื่อให้แน่ใจว่าไม่มีโค้ดหรือคำสั่งอันตราย เช่น การลบสัญลักษณ์พิเศษที่อาจใช้เจาะระบบ (เช่น <script> ใน HTML)
  - ใช้เทคนิค Data Scrubbing เพื่อการลบหรือซ่อนข้อมูลที่ไม่จำเป็นหรือเป็นความลับ เช่น การลบเลขบัตรเครดิตที่แสดงทั้งหมด แล้วแสดงเฉพาะตัวเลขท้าย เช่น **** **** **** 1234
  - ตรวจสอบ input อย่างเข้มงวด
  - จำกัดการเข้าถึงแหล่งข้อมูลภายนอก

7) Insecure Plugin Design (การออกแบบ plugin ที่ไม่ปลอดภัย)

• ปัญหา: plugins ที่มีช่องโหว่ ทำให้ผู้โจมตีสามารถส่ง requests ที่เป็นอันตรายได้
• ตัวอย่าง: เปิดช่องโหว่ให้เกิดการโจมตี เช่น Remote Code Execution
• ผลกระทบ: การรั่วไหลของข้อมูล, remote code execution, การยกระดับสิทธิ์
• วิธีป้องกัน:
  - ใช้ parameterized input และตรวจสอบ type และ range ของ input
  - ใช้ authentication identities และ API keys ที่เหมาะสม
  - ตรวจสอบและทดสอบ plugins อย่างละเอียด
  — SAST การตรวจสอบ โค้ดต้นฉบับ (Source Code) เพื่อหาช่องโหว่
  — DAST การตรวจสอบ Application ขณะ Run อยู่ เพื่อหาช่องโหว่
  — IAST ผสมผสานระหว่าง SAST และ DAST โดยตรวจสอบทั้งโค้ดและพฤติกรรมการทำงานของแอปพลิเคชันขณะรัน

8) Excessive Agency (อำนาจมากเกินไป)

• ปัญหา: ระบบ LLM มีฟังก์ชัน, สิทธิ์, หรือ autonomy มากเกินไป
• ตัวอย่าง:
  - LLM agent เข้าถึงฟังก์ชันที่ไม่จำเป็นจาก plugin
  - plugin มีสิทธิ์ที่ไม่จำเป็นบนระบบอื่น ๆ
• ผลกระทบ: LLM ทำงานที่ไม่จำเป็น หรือทำ action ที่เป็นอันตราย
• วิธีป้องกัน:
  - จำกัดสิทธิ์การเข้าถึงของ Plugin หรือ Function
  - เพิ่มกลไกตรวจสอบ เช่น Human in the Loop

9) Over-Reliance (การพึ่งพามากเกินไป)

• ปัญหา: การเชื่อใจ LLM มากเกินไป โดยที่ไม่ได้มีการตรวจสอบหรือ validation ที่เพียงพอ
• ตัวอย่าง:
  - LLM ให้ข้อมูลที่ไม่ถูกต้อง
  - LLM แนะนำโค้ดที่ไม่ปลอดภัย
• ผลกระทบ: ข้อมูลผิดพลาด, ปัญหาทางกฎหมาย, ช่องโหว่ด้านความปลอดภัย
• วิธีป้องกัน:
  - ติดตามและตรวจสอบ output ของ LLM เป็นประจำ
  - สื่อสารความเสี่ยงและข้อจำกัดของ LLM ให้ชัดเจน

10) Model Theft (การขโมยโมเดล)

• ปัญหา: การขโมยโมเดล LLM เช่น การเข้าถึงโมเดลโดยไม่ได้รับอนุญาต หรือการสร้างสำเนาโมเดลอย่างผิดกฎหมาย
• ตัวอย่าง:
  - ผู้โจมตีสร้าง inputs เพื่อเก็บ output ของโมเดล
  - โดนขโมยข้อมูลของโมเดล
• ผลกระทบ: ความสูญเสียทางเศรษฐกิจ, ความเสียหายต่อชื่อเสียง, การเข้าถึงข้อมูลลับโดยไม่ได้รับอนุญาต
• วิธีป้องกัน:
  - ใช้การควบคุมการเข้าถึงที่เข้มงวด (Access Control)
  - ใช้ Watermarking ในกระบวนการพัฒนาโมเดล

---

การพัฒนาแอปพลิเคชันที่ใช้ LLM ไม่ได้จำกัดอยู่แค่การสร้างโมเดลที่แม่นยำ แต่ต้องให้ความสำคัญกับ Memory Management, Behavior Monitoring, และ Security Risks เพื่อสร้างระบบที่ ปลอดภัย เสถียร และตอบโจทย์การใช้งานระยะยาว โดยในบทความนี้เราได้ครอบคลุมหัวข้อสำคัญดังนี้:

• LangChain Hands-On: การสร้าง Demo ตั้งแต่ One-shot Q&A ไปจนถึง Chat Application
• Memory Management: การจัดการ Short-Term และ Long-Term Memory โดยใช้ Vector Database
• Behavior Monitoring: การติดตามพฤติกรรมของโมเดลด้วย Metrics ต่าง ๆ
• OWASP Top 10: ความเสี่ยงด้านความปลอดภัย 10 ประการ พร้อมแนวทางป้องกัน

การพัฒนาแอปพลิเคชัน LLM ที่สมบูรณ์แบบคือการผสมผสานระหว่างเทคโนโลยี, การติดตามประสิทธิภาพ และการรักษาความปลอดภัย

ขอบคุณที่ติดตาม Data Mastery Series แล้วพบกันใหม่ใน Episode ถัดไป! 🚀

Data Science Explore the world of data science with Donato_Story

Dashboard Discover the power of data visualization with Donato_Story

Donato_Journey Join me on my journey (Thai version)

Course_Review Discover the training courses with Donato_Story (Thai version)

Let’s Connect!

ติดตามการเดินทางของเราเพื่อเรียนรู้เพิ่มเติมเกี่ยวกับการใช้งาน LLM และ LangChain:

• Medium: medium.com/donato-story
• Facebook: web.facebook.com/DonatoStory
• Linkedin: linkedin.com/in/nattapong-thanngam