5 กลยุทธ์ Prompt Optimization ยกระดับผลลัพธ์ LLM ให้แม่นยำจริง

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

ความแตกต่างนี้สำคัญมาก เพราะผู้ใช้งานส่วนใหญ่มักมี prompt ที่ทำงานได้ในระดับหนึ่งอยู่แล้ว พวกเขาไม่ได้ต้องการเริ่มจากหน้ากระดาษว่างเปล่า แต่ต้องการทราบว่าการปรับเปลี่ยนจุดใดจะส่งผลต่อผลลัพธ์อย่างแท้จริง บทความนี้จึงรวบรวม 5 วิธีที่พิสูจน์แล้วว่าช่วยได้จริง โดยใช้ตัวอย่างจากบันทึกการประชุมที่ซับซ้อนเพื่อเปลี่ยนเป็นรายการสิ่งที่ต้องทำ (action items) ที่แม่นยำ

นี่คือบันทึกการประชุมตัวอย่างที่ประกอบด้วยผู้สนทนาสามคน ท่ามกลางความวุ่นวายและการเปลี่ยนใจไปมา ซึ่งเราจะใช้เป็นเกณฑ์วัดผลของทุกกลยุทธ์:

Priya: โอเค อย่างแรกเลย เรื่องการออกแบบหน้า checkout ใหม่ ถึงไหนกันแล้ว

Tom: ส่วนใหญ่เสร็จแล้ว ผมแค่ต้องการใครสักคนมาตรวจ mobile layout ก่อนวันศุกร์

Priya: เดี๋ยวฉันทำเอง อ้อ เดี๋ยวก่อน Jake บอกว่าเขาจะดูให้ งั้นยกให้เป็นหน้าที่เขาแล้วกัน

Jake: ได้ครับ เดี๋ยวผมดู mobile review ให้ จะทำให้เสร็จภายในวันพฤหัสบดีนี้

Tom: เยี่ยม เรื่องที่สอง เราคุยกันเมื่อสัปดาห์ที่แล้วว่าจะย้าย billing service ไปยังคิวใหม่ แต่บอกตามตรงผมว่าเราควรชะลอไว้ก่อน ตัว library ของคิวเพิ่งมี security patch เมื่อวานนี้ และผมยังไม่ได้อ่าน changelog เลย

Priya: เห็นด้วย อย่าไปยุ่งกับระบบ billing จนกว่าจะตรวจสอบเรื่องนั้นก่อน Tom คุณช่วยอ่าน changelog แล้วแจ้งจุดที่น่ากังวลหน่อยได้ไหม

Tom: ได้ครับ เดี๋ยวผมจัดการให้พรุ่งนี้เช้า

Jake: แล้วก็ ขอโทษที่แทรกนะครับ แต่คิวงาน support เริ่มแย่อีกแล้ว ตอนนี้มี ticket ค้างอยู่ประมาณ 40 ใบ ต้องมีคนมาจัดลำดับความสำคัญ (triage) ในสัปดาห์นี้ ไม่งั้นมันจะพอกพูนจนคุมไม่อยู่

Priya: ใช่ ถูกต้องเลย ฉันไม่คิดว่าควรเป็น Tom หรือ Jake เพราะงานล้นมืออยู่แล้ว เดี๋ยวฉันจะดึงคนจากทีม support มาช่วยคนหนึ่ง แค่ขอเช็คก่อนว่าใครว่าง

Tom: อีกเรื่องหนึ่ง ย้อนกลับไปเรื่อง mobile review นะ Jake ช่วยเช็ค tablet breakpoint ตอนที่ดูด้วยได้ไหม เราได้รับเรื่องร้องเรียนมาเมื่อสัปดาห์ที่แล้ว

Jake: ได้ครับ เดี๋ยวผมรวมเข้าไปในการรีวิวครั้งเดียวกันเลย

โจทย์นี้มีความยากแฝงอยู่สามจุด: การเปลี่ยนตัวผู้รับผิดชอบจาก Priya เป็น Jake, การรวมงาน tablet-breakpoint เข้ากับงานเดิม และสถานะผู้รับผิดชอบงาน triage ที่ยังสรุปไม่ได้ หาก Prompt ไม่สามารถเก็บรายละเอียดเหล่านี้ได้ครบถ้วน จะถือว่าล้มเหลวในการใช้งานจริง

1. การกำหนดโครงสร้างผลลัพธ์ (Specifying Structured Output)

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

from pydantic import BaseModel, ValidationError
 
class ActionItem(BaseModel):
    owner: str
    task: str
    due: str
 
class ActionItemList(BaseModel):
    action_items: list[ActionItem]
 
def parse_structured_output(raw_json: str) -> tuple[ActionItemList | None, str | None]:
    """Validates a model's raw output against the schema. Returns the
    parsed object or a clear error, never a silent partial result."""
    try:
        return ActionItemList.model_validate_json(raw_json), None
    except ValidationError as e:
        return None, str(e)

จากการทดสอบพบว่า Prompt แบบกว้างๆ มักส่งผลลัพธ์เป็นข้อความธรรมดาซึ่ง parse_structured_output จะรายงานความผิดพลาดทันทีเพราะไม่ใช่ JSON แต่เมื่อใช้ Schema ที่ชัดเจน ข้อมูลจะถูกจัดระเบียบเป็นวัตถุ ActionItem ที่พร้อมใช้งานในโค้ดทันทีโดยไม่ต้องใช้คนมาคัดลอกด้วยมือ

2. การกำหนดบทบาทและตัวตน (Assigning a Role and Persona)

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

ก่อนปรับ: สรุปรายการสิ่งที่ต้องทำจากบันทึกการประชุมนี้

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

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

3. การเลือกตัวอย่างแบบ Few-Shot (Selecting Few-Shot Demonstrations)

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

from sklearn.feature_extraction.text import TfidfVectorizer
 
from sklearn.metrics.pairwise import cosine_similarity
 
def select_diverse_examples(candidates: list[str], k: int = 3) -> list[str]:
    """Greedily picks k examples that are maximally dissimilar from each
    other, so the few-shot set covers different patterns instead of
    k near-duplicates of the same case."""
    vectorizer = TfidfVectorizer(stop_words="english")
    vectors = vectorizer.fit_transform(candidates)
    similarity_matrix = cosine_similarity(vectors)
 
selected_idx = [0]
    while len(selected_idx) < k:
        remaining = [i for i in range(len(candidates)) if i not in selected_idx]
        scores = [(i, 1 - max(similarity_matrix[i][j] for j in selected_idx)) for i in remaining]
        best_idx = max(scores, key=lambda pair: pair[1])[0]
        selected_idx.append(best_idx)
    return [candidates[i] for i in selected_idx]

การสุ่มตัวอย่างที่คล้ายกันจะทำให้เสียโควตาไปโดยเปล่าประโยชน์ การใช้เทคนิคเลือกตัวอย่างที่แตกต่างกัน (เช่น ตัวอย่างที่มีเจ้าของชัดเจน, ตัวอย่างที่ยังไม่สรุปเจ้าของงาน และตัวอย่างงานที่รวมกัน) จะช่วยให้โมเดลเรียนรู้แพทเทิร์นที่หลากหลายและทำงานได้แม่นยำขึ้น

4. การใช้ Prompt สำหรับ Chain-of-Thought

การขอให้โมเดลใช้เหตุผลทีละขั้นตอน (Chain-of-Thought) ยังคงมีประโยชน์ในกรณีที่ข้อมูลมีความคลุมเครือสูง แม้ว่า Frontier models รุ่นใหม่ๆ จะมีความสามารถในการใช้เหตุผลในตัวอยู่แล้วก็ตาม

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

วิธีนี้บังคับให้โมเดลมองภาพรวมแทนการจับคู่แพทเทิร์นเพียงอย่างเดียว นอกจากนี้ยังมีเทคนิค "Chain of Draft" ที่ช่วยลดต้นทุนได้ โดยให้โมเดลร่างเหตุผลสั้นๆ ซึ่งงานวิจัยพบว่าให้ความแม่นยำใกล้เคียงกันแต่ใช้ token น้อยลงเหลือเพียง 7.6% เท่านั้น

5. การใช้ Automated, Iterative Prompt Optimization

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

CANDIDATE_FRAGMENTS = [
    "If an assignment changes mid-conversation, use the FINAL owner, not the first one mentioned.",
    "If a task gets folded into an existing item later in the conversation, merge it, don't create a duplicate.",
    "If no owner is explicitly assigned, use 'unassigned' rather than guessing.",
    "Do not include general discussion or decisions that aren't concrete action items.",
    "Match each due date to what was actually said, not an assumed default.",
]
 
def composite_score(extracted: list[dict], ground_truth: list[dict]) -> float:
    """Recall alone misses real quality problems: a wrong owner or a
    fabricated extra item both matter and both get penalized here."""
    result = score_extraction(extracted, ground_truth)
    fabrication_penalty = result["fabricated_items"] * 0.15
    return max(0.0, (result["recall"] * 0.5 + result["owner_accuracy"] * 0.5) - fabrication_penalty)
 
def optimize(n_iterations: int = 6) -> tuple[PromptCandidate, list]:
    """Hill-climbing: at each step, try adding one unused instruction
    fragment, keep whichever addition improves the score most."""
    current = PromptCandidate(instructions=[])
    # ... logic for iterative optimization

ระบบจะทำการค้นหาชุดคำสั่งขั้นต่ำที่ให้ผลลัพธ์ดีที่สุด จากการทดสอบพบว่าการใช้ระบบอัตโนมัติสามารถเพิ่มคะแนนจาก 51.6% เป็น 100% ได้โดยการเลือกใช้เฉพาะชุดคำสั่งที่จำเป็นจริงๆ ช่วยลดความฟุ่มเฟือยของ Prompt และเพิ่มความแม่นยำได้อย่างมหาศาล

การนำมารวมกัน

เมื่อผสานทั้ง 5 กลยุทธ์เข้าด้วยกัน เราจะได้ Prompt ที่แข็งแกร่งซึ่งประกอบด้วย: บทบาทที่ชัดเจน, โครงสร้าง JSON Schema, ตัวอย่าง Few-shot ที่หลากหลาย, การใช้เหตุผลแบบ Chain-of-Thought และชุดคำสั่งที่ผ่านการขัดเกลาด้วยระบบอัตโนมัติ วิธีนี้ช่วยลดความเสี่ยงที่งานจะตกหล่นหรือการกุชื่อผู้รับผิดชอบขึ้นมาเอง (Fabrication) ซึ่งเป็นสิ่งที่การอ่านด้วยตาเปล่าอาจมองข้ามได้

สรุป

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