RAG は「外部知識を検索してプロンプトに渡す」手法であり、ファインチューニングは「モデル自体を追加学習で作り替える」手法です。知識をどこに持たせるかが根本的に異なります。 この違いを理解しておくと、後の比較軸や選定ステップがすっきりと理解できるようになります。まずは両者の仕組みを、動作原理に沿って個別に整理します。

RAG (Retrieval-Augmented Generation / การสร้างข้อความโดยอาศัยการดึงข้อมูล) คือวิธีการที่ไม่ได้ปรับเปลี่ยนตัวโมเดลโดยตรง แต่ใช้วิธีการดึงข้อมูลความรู้ที่จำเป็นต่อการตอบคำถามจากแหล่งภายนอกมาใส่ไว้ใน Prompt

สำหรับการเตรียมการเบื้องต้น จะต้องแบ่งเอกสารภายในองค์กรหรือ FAQ ออกเป็นส่วนๆ ที่มีความยาวเหมาะสม (Chunking) จากนั้นนำไปแปลงเป็นเวกเตอร์ด้วย Embedding Model และจัดเก็บไว้ใน Vector Database เมื่อมีคำถามจากผู้ใช้ ระบบจะแปลงคำถามนั้นเป็นเวกเตอร์เพื่อค้นหา Chunk ที่มีความหมายใกล้เคียงกันออกมา จากนั้นจะนำ Chunk ที่ดึงมาได้ส่งให้ LLM พร้อมกับคำถามในฐานะ "ข้อมูลอ้างอิง" เพื่อให้โมเดลสร้างคำตอบโดยอาศัยข้อมูลเหล่านั้น

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

ファインチューニング（Fine-tuning）とは、既存の学習済みモデルに対して追加のデータセットで再学習を行い、モデルの重み（パラメータ）そのものを目的に合わせて調整する手法である。知識や振る舞いをモデルの内部に染み込ませるイメージとなる。

流れとしては、まず「入力と望ましい出力」のペアからなる教師データを用意する。データの品質と量がそのまま結果を左右するため、ここが最も労力のかかる工程である。次に、用意したデータでモデルを追加学習させ、検証データで精度や副作用を確認し、問題なければデプロイする。全パラメータを更新する方式は計算コストが大きいため、一部のパラメータだけを効率的に調整するLoRAなどの手法（PEFT）が実務ではよく使われる。

利点は、出力のフォーマットや文体、専門領域の言い回しといった「振る舞い」を安定して再現できる点である。反面、知識を更新するたびに再学習が必要であり、外部知識の即時反映には向かない。

RAG とファインチューニングは、コスト・精度・データ要件の観点において性質が大きく異なるため、自社の制約に照らして比較軸を決めることが選定の出発点となる。 「どちらが優れているか」ではなく「自社のユースケースではどの軸が重要か」という観点で考える。ここでは、選定に用いる代表的な比較軸を、コスト・精度・データの3つの観点から掘り下げる。

ในด้านต้นทุน จำเป็นต้องแยกพิจารณาระหว่างการลงทุนเริ่มแรก (Initial Investment) และค่าใช้จ่ายในการดำเนินงานและบำรุงรักษา (Operational Maintenance Cost)

การลงทุนเริ่มแรกสำหรับ RAG จะเน้นไปที่การทำ Document Chunking, การสร้าง Vector Database และการติดตั้งระบบ Search Pipeline เนื่องจากไม่จำเป็นต้องทำการ Re-training โมเดล จึงสามารถเริ่มดำเนินการได้แม้ไม่มีผู้เชี่ยวชาญด้าน Machine Learning สำหรับค่าใช้จ่ายในการดำเนินงานและบำรุงรักษานั้น จะเป็นต้นทุนที่เกิดขึ้นต่อเนื่องจากการเรียกใช้งาน Embedding ทุกครั้งที่ทำการค้นหา และการเพิ่มขึ้นของ Input Token จากการที่ Prompt มีความยาวขึ้น

การลงทุนเริ่มแรกสำหรับ Fine-tuning จะเน้นไปที่การเตรียมข้อมูลสอน (Training Data) และทรัพยากรคำนวณสำหรับการเรียนรู้ ภาระหลักคือค่าแรงในการเตรียมข้อมูลคุณภาพสูงและค่าใช้จ่ายด้านสภาพแวดล้อม GPU สำหรับการประมวลผลการเรียนรู้ ในทางกลับกัน ในช่วงการดำเนินงาน เนื่องจากไม่จำเป็นต้องใส่ความรู้ภายนอกลงใน Prompt ทุกครั้ง จึงสามารถควบคุมปริมาณ Token ในขณะประมวลผล (Inference) ได้ง่ายกว่า อย่างไรก็ตาม ทุกครั้งที่มีการอัปเดตความรู้ ต้นทุนในการ Re-training จะเกิดขึ้นซ้ำอีกครั้ง

โดยสรุปแล้ว RAG เหมาะสำหรับการเริ่มต้นขนาดเล็กในช่วงแรก ส่วน Fine-tuning จะได้เปรียบหากความรู้มีความเสถียรและมีการใช้งานในปริมาณมากในระยะยาว เนื่องจากจุดคุ้มทุนที่แท้จริงจะเปลี่ยนไปตามขนาดการใช้งานและความถี่ในการอัปเดตข้อมูล จึงควรนำตัวเลขของบริษัทมาประกอบการตัดสินใจผ่านการทำ PoC ที่จะกล่าวถึงต่อไป

ในแง่ของความแม่นยำ มักจะมีความแตกต่างในเรื่องความสดใหม่ของข้อมูลและความเสี่ยงต่อการเกิดอาการหลอน (Hallucination)

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

ในขณะที่ Fine-tuning สามารถถ่ายทอดสำนวนหรือรูปแบบในโดเมนที่เรียนรู้มาได้อย่างเสถียร แต่เนื่องจากความรู้ถูกฝังไว้ภายในโมเดล การอัปเดตข้อมูลหลังจากช่วงเวลาที่เรียนรู้จึงไม่สามารถทำได้หากไม่มีการเรียนรู้ใหม่ (Re-training) และมีแนวโน้มที่จะให้คำตอบที่ดูน่าเชื่อถือแต่ผิดพลาด (Hallucination) สำหรับคำถามที่ไม่อยู่ในข้อมูลที่ใช้ฝึกสอน

ในโดเมนที่ความรู้มีการเปลี่ยนแปลงบ่อยครั้ง RAG จะช่วยรักษาความสดใหม่ของข้อมูลได้ดีกว่า ส่วนในโดเมนที่ข้อมูลมีการเปลี่ยนแปลงน้อยและต้องการความสม่ำเสมอของพฤติกรรม Fine-tuning จะเป็นตัวเลือกที่เหมาะสมกว่า

ในมุมมองของข้อมูล ประเภท ปริมาณ และคุณภาพของข้อมูลที่จำเป็นสำหรับทั้งสองวิธีนั้นมีความแตกต่างกันอย่างมาก

สิ่งที่ RAG ต้องการคือ "เอกสารความรู้" ที่ใช้ในการสืบค้นโดยตรง ไม่จำเป็นต้องสร้างคู่ข้อมูลอินพุตและเอาต์พุตเหมือนกับข้อมูลสำหรับสอน (Training Data) เพียงแค่นำเอกสารภายในบริษัท FAQ หรือคู่มือที่มีอยู่มาแบ่งเป็นส่วนย่อย (Chunking) ก็สามารถเริ่มต้นได้แล้ว ดังนั้นเกณฑ์ในการเตรียมข้อมูลจึงค่อนข้างต่ำ อย่างไรก็ตาม หากเอกสารมีความเก่า ข้อมูลซ้ำซ้อนมาก หรือโครงสร้างไม่เป็นระเบียบ จะส่งผลให้ความแม่นยำในการสืบค้นลดลง การจัดระเบียบข้อมูลต้นฉบับจึงมีความสำคัญ

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

สถานการณ์ที่มีเอกสารความรู้พร้อมใช้งานแต่ไม่มีกำลังพอที่จะสร้างข้อมูลสำหรับสอนนั้นพบได้บ่อย ในกรณีเช่นนี้ การเริ่มต้นด้วย RAG จึงเป็นทางเลือกที่เหมาะสมในทางปฏิบัติ

RAG เหมาะสำหรับสาขาที่มีการอัปเดตความรู้บ่อยครั้ง หรือสถานการณ์ที่ยากต่อการเตรียมข้อมูลสำหรับฝึกสอน (Training Data) จำนวนมาก คุณสมบัติของ RAG ที่สามารถรองรับได้เพียงแค่การเปลี่ยนข้อมูลภายนอกนั้นมีประสิทธิภาพในสถานการณ์เหล่านี้ เราจะมาดูตัวอย่างกรณีศึกษาที่สำคัญ 2 กรณีกัน

สำหรับการจัดการความรู้ที่มีการแก้ไขเนื้อหาเป็นประจำ เช่น เอกสารภายในองค์กรหรือระเบียบข้อบังคับต่างๆ การใช้ RAG จะมีความเหมาะสมและสอดคล้องกับการใช้งานมากกว่า

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

นอกจากนี้ RAG ยังสามารถแสดงเอกสารที่เป็นที่มาของคำตอบได้ ทำให้สามารถระบุได้ว่า "คำตอบนั้นอ้างอิงมาจากระเบียบข้อบังคับฉบับใดและข้อใด" ในการตอบคำถามภายในองค์กรหรือการค้นหาความรู้ การแสดงหลักฐานอ้างอิงเช่นนี้จะช่วยรับประกันความน่าเชื่อถือของคำตอบ ยิ่งในส่วนงานที่การจัดการประวัติการแก้ไขมีความสำคัญ โครงสร้างของ RAG ที่เก็บความรู้ไว้ภายนอกโมเดลจะยิ่งตอบโจทย์การใช้งานจริงได้ดีกว่า

สำหรับภาษาที่มีทรัพยากรข้อมูลน้อย (low-resource languages) เช่น ภาษาลาวหรือภาษาไทย RAG ถือเป็นทางเลือกที่มีประสิทธิภาพ

ในภาษาที่มีทรัพยากรข้อมูลน้อย การรวบรวมข้อมูลสอน (training data) ที่มีคุณภาพเพียงพอสำหรับการทำ Fine-tuning นั้นทำได้ยาก หากฝืนทำ Fine-tuning ในสภาวะที่ข้อมูลมีจำกัด อาจส่งผลให้ผลลัพธ์ที่ได้ไม่มีเสถียรภาพ ในทางกลับกัน RAG สามารถดึงคำตอบที่อ้างอิงจากความรู้เฉพาะขององค์กรหรือภาษานั้นๆ ได้โดยไม่ต้องสร้างข้อมูลสอน เพียงแค่นำเอกสารที่มีอยู่เดิมในภาษานั้น (เช่น ระเบียบข้อบังคับ คู่มือ หรือคลังความรู้) มาเป็นแหล่งข้อมูลในการค้นหา

ในภูมิภาคเอเชียตะวันออกเฉียงใต้ซึ่งเป็นพื้นที่ดำเนินธุรกิจของเรา สถานการณ์ทั่วไปคือมีเอกสารภายในที่เป็นภาษาท้องถิ่นอยู่แล้ว แต่ขาดข้อมูลคู่ขนาน (parallel data) ที่ผ่านการเตรียมไว้สำหรับ Machine Learning ในสภาพแวดล้อมเช่นนี้ แนวทางที่เป็นจริงที่สุดคือการนำเอกสารภาษาท้องถิ่นที่มีอยู่มาใช้เป็นแหล่งความรู้สำหรับ RAG และเลือกใช้ Embedding model ที่มีความเชี่ยวชาญในลักษณะเฉพาะของภาษานั้นๆ ตามความจำเป็น

การทำ Fine-tuning เหมาะสำหรับกรณีที่ต้องการควบคุมรูปแบบของผลลัพธ์หรือสไตล์การเขียนให้มีความสม่ำเสมออย่างเคร่งครัด หรือกรณีที่ต้องการย้ายพฤติกรรมของโมเดลไปไว้ในโมเดลขนาดเล็กเพื่อลดต้นทุนในการประมวลผล (Inference cost) วิธีนี้จะเห็นผลชัดเจนในสถานการณ์ที่ให้ความสำคัญกับ "ความสม่ำเสมอของพฤติกรรม" (Behavioral consistency) หรือ "ประสิทธิภาพในการประมวลผล" (Inference efficiency) มากกว่าการอัปเดตความรู้ โดยเราจะมาดู 2 กรณีตัวอย่างที่สำคัญกัน

หากต้องการกำหนดรูปแบบของเอาต์พุตหรือสไตล์การเขียนให้เป็นมาตรฐานเดียวกันอย่างเคร่งครัด การทำ Fine-tuning จะให้ผลลัพธ์ที่มีประสิทธิภาพสูง

ตัวอย่างเช่น ในกรณีที่มีความต้องการให้เอาต์พุตออกมาเป็น JSON schema ที่กำหนดไว้เสมอ, ต้องการให้ใช้คำศัพท์เฉพาะทางในอุตสาหกรรมหรือระดับของคำสุภาพที่สม่ำเสมอ หรือต้องการให้สร้างข้อความที่ตรงตาม Tone & Manner ของบริษัทอย่างคงเส้นคงวา สิ่งเหล่านี้หากใช้เพียงคำสั่งใน Prompt มักจะเกิดความคลาดเคลื่อนได้ง่าย และรูปแบบอาจผิดเพี้ยนไปตามอินพุตที่ได้รับ

การใช้ Fine-tuning เพื่อเรียนรู้ตัวอย่างเอาต์พุตที่ต้องการอย่างเพียงพอ จะช่วยให้ "พฤติกรรม" เหล่านี้ฝังลึกอยู่ในตัวโมเดล ทำให้สามารถสร้างผลลัพธ์ที่เสถียรได้โดยไม่ต้องระบุคำสั่งอย่างละเอียดใน Prompt ทุกครั้ง นอกจากนี้ยังช่วยลดจำนวนโทเค็นในการอนุมาน (Inference) เนื่องจาก Prompt จะสั้นลง สำหรับการใช้งานที่ไม่อนุญาตให้รูปแบบผิดเพี้ยน หรือการใช้งานที่ต้องสร้างข้อมูลในรูปแบบเดิมซ้ำๆ เป็นจำนวนมาก ความสม่ำเสมอนี้ถือเป็นคุณค่าที่สำคัญอย่างยิ่ง

หากต้องการถ่ายโอนพฤติกรรมของโมเดลขนาดใหญ่ไปยังโมเดลขนาดเล็กเพื่อลดต้นทุนการอนุมาน (Inference cost) การทำ Fine-tuning ก็เป็นทางเลือกหนึ่งที่น่าสนใจ

โมเดลขนาดใหญ่มีความแม่นยำสูง แต่มีต้นทุนต่อการเรียกใช้งาน (Unit price) และค่าความหน่วง (Latency) ที่สูง ดังนั้นจึงมีแนวทางที่เรียกว่า "Distillation" (การกลั่นกรองความรู้) ซึ่งเป็นการนำเอาต์พุตจากโมเดลขนาดใหญ่มาใช้เป็นข้อมูลสอน (Teacher data) เพื่อทำ Fine-tuning ให้กับโมเดลขนาดเล็ก เพื่อให้สามารถสร้างผลลัพธ์ที่มีคุณภาพใกล้เคียงกันในงานเฉพาะทาง หากจำกัดขอบเขตของงานให้แคบลง โมเดลขนาดเล็กก็มีโอกาสที่จะรักษาความแม่นยำในระดับที่ใช้งานได้จริง พร้อมทั้งลดต้นทุนการอนุมานและค่าความหน่วงลงได้

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

โดยสรุปแล้ว หากข้อมูลมีการอัปเดตบ่อยครั้งและมีทรัพยากรจำกัดในการเตรียมข้อมูล RAG จะเป็นตัวเลือกหลัก แต่หากให้ความสำคัญกับความสม่ำเสมอของพฤติกรรม (Behavioral Consistency) และประสิทธิภาพในการอนุมาน (Inference Efficiency) รวมถึงสามารถบริหารจัดการการทำ Fine-tuning ได้อย่างต่อเนื่อง Fine-tuning จะเป็นตัวเลือกพื้นฐาน ต่อไปนี้จะสรุปเกณฑ์การเปรียบเทียบทั้งหมดไว้ในตาราง รวมถึงตัวเลือกแบบ Hybrid ที่นำทั้งสองวิธีมาผสมผสานกัน เพื่อให้เห็นภาพรวมทั้งหมดชัดเจนยิ่งขึ้น

ตารางด้านล่างนี้คือรายการสรุปเกณฑ์การเปรียบเทียบทั้งหมดที่กล่าวมา โปรดนำไปปรับใช้กับข้อจำกัดขององค์กรท่านเพื่อพิจารณาว่าเกณฑ์ใดมีความสำคัญที่สุด สำหรับองค์กรส่วนใหญ่แล้ว ลำดับที่เหมาะสมและเป็นจริงที่สุดคือ "เริ่มจากการสร้าง RAG อย่างรวดเร็ว แล้วจึงค่อยเพิ่มการทำ Fine-tuning เฉพาะในส่วนที่จำเป็น"

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

RAG และ Fine-tuning ไม่ใช่ทางเลือกที่ต้องเลือกอย่างใดอย่างหนึ่ง แต่สามารถออกแบบให้ใช้งานร่วมกันเพื่อดึงจุดแข็งของทั้งสองวิธีมาใช้ได้

รูปแบบทั่วไปคือการใช้ Fine-tuning เพื่อปรับ "พฤติกรรม" (Behavior) และใช้ RAG เพื่อจัดหา "ความรู้" (Knowledge) ตัวอย่างเช่น การใช้ Fine-tuning เพื่อให้โมเดลจดจำโทนเสียง รูปแบบการแสดงผล หรือสำนวนเฉพาะทางของบริษัท ในขณะที่ใช้ RAG เพื่อสืบค้นและส่งมอบความรู้เฉพาะเจาะจงที่มีการอัปเดตอยู่บ่อยครั้ง วิธีนี้จะช่วยให้ได้ทั้งความสม่ำเสมอของรูปแบบและความสดใหม่ของข้อมูลไปพร้อมกัน

อย่างไรก็ตาม การใช้งานร่วมกันจะเพิ่มความซับซ้อนในการดำเนินงานและต้นทุน เนื่องจากต้องดูแลทั้งไปป์ไลน์การสืบค้น (Search pipeline) และการดำเนินการฝึกฝนใหม่ (Re-training) จึงไม่ควรเริ่มด้วยความต้องการที่มากเกินไปตั้งแต่ต้น ควรเริ่มต้นด้วยวิธีใดวิธีหนึ่งก่อน (ส่วนใหญ่มักเป็น RAG) แล้วค่อยเพิ่ม Fine-tuning เข้าไปเมื่อพบว่าความไม่สม่ำเสมอของรูปแบบหรือความแม่นยำในงานเฉพาะทางกลายเป็นคอขวด การค่อยๆ ขยายไปสู่การใช้งานร่วมกันหลังจากที่ปัญหาเริ่มชัดเจนขึ้น เป็นแนวทางที่จะช่วยให้การลงทุนไม่สูญเปล่า

การเลือกใช้วิธีการควรดำเนินการผ่าน 3 ขั้นตอน ได้แก่ การสำรวจ Use Case (Step 1), การทดสอบด้วย PoC (Step 2) และการตรวจสอบ Governance ก่อนการย้ายเข้าสู่ระบบงานจริง (Step 3) เพื่อลดโอกาสความล้มเหลว สิ่งสำคัญคือการสร้างกระบวนการทดสอบในสเกลเล็กและตัดสินใจโดยใช้ตัวเลขจริงของบริษัท แทนการตัดสินใจเพียงแค่การเปรียบเทียบทางทฤษฎี ต่อไปนี้คือรายละเอียดสิ่งที่ต้องทำในแต่ละขั้นตอน

ขั้นตอนแรกคือการสำรวจユースケース (Use Case) ที่ต้องการและตรวจสอบว่าความรู้นั้นมีการอัปเดตบ่อยเพียงใด

โดยเฉพาะอย่างยิ่ง ให้ระบุว่า "ต้องการให้ตอบคำถามเรื่องอะไร" "แหล่งข้อมูลที่เป็นพื้นฐานของคำตอบอยู่ที่ไหน" "ข้อมูลนั้นมีการเปลี่ยนแปลงบ่อยแค่ไหน" และ "รูปแบบผลลัพธ์ที่ต้องการมีความเข้มงวดเพียงใด" หากข้อมูลมีการอัปเดตบ่อยและยอมรับความยืดหยุ่นของรูปแบบได้ จะถือเป็นปัจจัยที่เอนเอียงไปทาง RAG แต่หากข้อมูลมีการอัปเดตน้อยแต่ต้องการความสม่ำเสมอของรูปแบบที่เข้มงวด การทำ Fine-tuning จะกลายเป็นตัวเลือกที่น่าสนใจ

ในขณะเดียวกัน ให้ตรวจสอบสินทรัพย์ที่มีอยู่ในมือด้วย เช่น มีเอกสารความรู้ที่พร้อมใช้งานหรือไม่ หรือมีกำลังคนและเวลาในการสร้างข้อมูลสอน (Training Data) หรือไม่ องค์กรส่วนใหญ่มักอยู่ในสถานะที่ "มีเอกสารความรู้แต่ไม่มีกำลังพอที่จะสร้างข้อมูลสอน" ซึ่งในกรณีนี้ การเริ่มต้นด้วย RAG ถือเป็นทางเลือกที่สมเหตุสมผล การสรุปประเด็นเหล่านี้ออกมาเป็นลายลักษณ์อักษรจะช่วยให้เห็นภาพชัดเจนว่าควรตรวจสอบอะไรในการทำ PoC ครั้งต่อไป

ถัดมา คือการวัดต้นทุนและความแม่นยำจริงในระดับ PoC (Proof of Concept) โดยมีจุดประสงค์เพื่อเก็บตัวเลขจากข้อมูลและคำถาม (Query) ของบริษัทเอง แทนที่จะใช้เพียงตารางเปรียบเทียบเชิงทฤษฎี

ในการตรวจสอบ เราจะเตรียมชุดคำถามที่เป็นตัวแทนของงานจริง เพื่อวัดคุณภาพของคำตอบ (อัตราความถูกต้อง, ความสมเหตุสมผลของแหล่งอ้างอิง, การปฏิบัติตามรูปแบบที่กำหนด) รวมถึงต้นทุนและค่า Latency ต่อครั้ง หากเป็น RAG จะเน้นดูว่าการค้นหาสามารถดึง Chunk ที่เหมาะสมออกมาได้หรือไม่ หากเป็น Fine-tuning จะเน้นดูว่าคำตอบจะผิดเพี้ยนไปมากน้อยเพียงใดเมื่ออยู่นอกเหนือขอบเขตการเรียนรู้

PoC ไม่ได้เป็นเพียงพื้นที่สำหรับดูว่า "จะทำสำเร็จหรือไม่" แต่ยังเป็นพื้นที่สำหรับค้นหาว่า "จะล้มเหลวที่จุดไหน" โดยต้องระบุเงื่อนไขที่ทำให้เกิดคำตอบที่ผิดพลาด (False response) หรือเงื่อนไขที่ต้นทุนสูงเกินคาด เพื่อทำความเข้าใจความเสี่ยงในการใช้งานจริงล่วงหน้า หากมีตัวเลขที่ได้จากการทดลองในสเกลเล็ก เราจะสามารถคำนวณจุดคุ้มทุนระหว่างต้นทุนเริ่มต้นและต้นทุนการดำเนินงานตามเงื่อนไขของบริษัทได้ ซึ่งจะช่วยยืนยันหรือปรับแก้สมมติฐานที่ตั้งไว้ใน Step 1

ก่อนการย้ายขึ้นระบบงานจริง (Production) ให้ตรวจสอบข้อกำหนดด้านความปลอดภัยและธรรมาภิบาล แม้ว่าความแม่นยำและต้นทุนจะสมเหตุสมผล แต่หากไม่ดำเนินการในส่วนนี้ให้รัดกุมก่อนเริ่มใช้งานจริง อาจนำไปสู่ปัญหาการรั่วไหลของข้อมูลหรือปัญหาด้านการปฏิบัติตามกฎระเบียบ (Compliance) ได้

ในกรณีของ RAG เนื่องจากความรู้จะถูกเก็บไว้ใน Vector Database ภายนอก ประเด็นสำคัญจึงอยู่ที่การควบคุมการเข้าถึง (Access Control) ว่าใครสามารถสืบค้นเอกสารใดได้บ้าง ดังนั้นจึงต้องออกแบบการควบคุมในระดับเอกสารและระดับผู้ใช้งาน เพื่อป้องกันไม่ให้เนื้อหาในเอกสารลับถูกเปิดเผยแก่ผู้ใช้ที่ไม่มีสิทธิ์ผ่านการสืบค้น สำหรับกรณีของ Fine-tuning จำเป็นต้องระมัดระวังในจุดที่ข้อมูลการเรียนรู้จะถูกนำเข้าไปเก็บไว้ภายในโมเดล หากนำข้อมูลที่เป็นความลับไปใช้ในการเรียนรู้ อาจมีความเสี่ยงที่ข้อมูลดังกล่าวจะถูกสร้างขึ้นมาใหม่โดยไม่ตั้งใจผ่านผลลัพธ์ของโมเดล ดังนั้น การคัดกรองและการทำ Masking ข้อมูลการเรียนรู้จึงมีความสำคัญ

นอกจากนี้ ให้ตรวจสอบข้อกำหนดด้านอธิปไตยของข้อมูล (Data Sovereignty) เช่น สามารถส่งข้อมูลไปยัง Cloud API ภายนอกได้หรือไม่ หรือขัดต่อกฎระเบียบเรื่องสถานที่จัดเก็บและระยะเวลาในการเก็บรักษาข้อมูลหรือไม่ โดยให้รวบรวมสิ่งเหล่านี้ไว้เป็นรายการตรวจสอบ (Checklist) สำหรับการใช้งานจริง และดำเนินการย้ายระบบหลังจากได้รับอนุมัติจากแผนกที่เกี่ยวข้องแล้วเท่านั้น

ไม่ว่าจะเป็น RAG หรือ Fine-tuning สาเหตุส่วนใหญ่ที่ทำให้สะดุดหลังจากนำไปใช้งานจริง มักจะสรุปได้ว่าเป็นรูปแบบทั่วไปที่สามารถคาดการณ์ได้ล่วงหน้า ตัวอย่างที่พบบ่อยสำหรับ RAG คือการออกแบบ Chunk และความแม่นยำในการค้นหา (Search accuracy) ส่วน Fine-tuning คือการเสื่อมถอยของความสามารถเดิมจากการเรียนรู้เพิ่มเติม หากทราบไว้ก่อนก็จะหลีกเลี่ยงได้ง่ายขึ้น เรามาดูหลุมพรางทั้ง 2 ประการนี้อย่างละเอียดกัน

RAG で最も多いつまずきが、チャンク設計のミスによる検索精度の低下だ。

ドキュメントを分割する単位が大きすぎると、1つのチャンクに複数の話題が混ざり、検索でノイズの多い情報が返ってきて回答がぼやける。逆に小さすぎると、文脈が途切れて、回答に必要な情報が複数チャンクに分断され、検索で取りこぼす。見出しや段落の構造を無視して機械的に文字数で切ると、文の途中で分断されて意味が壊れることもある。

回避策としては、文書の論理構造（見出し・段落・項目）に沿って分割し、チャンクに前後の文脈や見出し情報を付与して、単体でも意味が通るようにする。チャンク同士を少し重ねる（オーバーラップ）と、境界付近の情報落ちを減らせる。さらに、検索で取りすぎた候補を関連度で並べ替える再ランキングを挟むと精度が安定する。チャンク設計は一度で完成しないため、実際のクエリで検索結果を確認しながら調整していく。

สิ่งที่มักถูกมองข้ามในการทำ Fine-tuning คือ Catastrophic Forgetting (การลืมแบบหายนะ) ซึ่งหมายถึงปรากฏการณ์ที่โมเดลสูญเสียความสามารถทั่วไปที่เคยมีอยู่เดิมไป อันเป็นผลมาจากการเรียนรู้เพิ่มเติมในงานใหม่

หากฝึกฝนโมเดลด้วยข้อมูลเฉพาะทางเพียงอย่างเดียวอย่างเข้มข้น แม้โมเดลจะเก่งขึ้นในด้านนั้น แต่ก็อาจส่งผลให้ความสามารถในการตอบคำถามทั่วไปลดลง กล่าวคือ ความพยายามในการปรับจูนให้เหมาะสมกับงานเฉพาะทางกลับทำให้เสียสมดุลกับความสามารถในการใช้งานทั่วไป

วิธีหลีกเลี่ยงปัญหานี้คือการใช้เทคนิคอย่าง LoRA ซึ่งเป็นการปรับจูนเพียงบางพารามิเตอร์แทนการเขียนทับพารามิเตอร์ทั้งหมด เพื่อลดผลกระทบต่อโมเดลต้นฉบับ นอกจากนี้ การปรับจูนค่า Learning rate ไม่ให้สูงเกินไป, การไม่ฝึกฝนมากจนเกินไป (ป้องกัน Overfitting) และการผสมข้อมูลทั่วไปเข้าไปในสัดส่วนที่เหมาะสมระหว่างการฝึกฝนก็เป็นวิธีที่มีประสิทธิภาพเช่นกัน และที่สำคัญที่สุดคือ หลังจากทำการเรียนรู้เพิ่มเติมแล้ว ต้องตรวจสอบกับข้อมูลทดสอบ (Validation data) เสมอว่า นอกจากความแม่นยำในงานเป้าหมายจะเพิ่มขึ้นแล้ว งานทั่วไปที่เคยทำได้ต้องไม่เสื่อมถอยลง การไม่ด่วนสรุปว่า "ความแม่นยำเพิ่มขึ้น" โดยดูเพียงตัวชี้วัดแคบๆ คือหัวใจสำคัญที่จะช่วยให้ไม่มองข้าม Catastrophic Forgetting ไป