ขั้นนี้ใช้ LLM (temperature 0) แปลงคำถามให้เป็น "โครงเหตุการณ์" หรือที่เรียกว่า EventFrame:

อะไร — สินค้า บริการ อุตสาหกรรม ใบอนุญาต หรือวัตถุดิบที่เหตุการณ์นั้นเกี่ยวข้อง
ใคร — บทบาท เช่น ผู้ผลิต ผู้ขาย ผู้ถือหุ้น ผู้รับจ้างผลิต
อย่างไร — กลไกที่กระทบ เช่น รายได้ลด ต้นทุนเพิ่ม หรือต้องขอใบอนุญาตใหม่
เมื่อไหร่ — เทียบกับ as_of_date

เจาะลึก understand_event() จะโหลด prompt จาก prompts/understand_event.md แล้วเรียก llm.generate(..., temperature=0.0, json_schema=FRAME_SCHEMA) เพื่อบังคับให้ผลลัพธ์ตรงกับ schema ของ pydantic EventFrame

📝 Prompt ที่ใช้จริง (จาก prompts/understand_event.md — Gemini Flash, temperature 0)

ขั้นนี้ป้อนคำถามพร้อมวันที่อ้างอิงให้ Gemini Flash แล้วรับ JSON กลับมา ด้านล่างคือ prompt จริงที่ระบบใช้ทุกครั้ง:

บทบาท: นักวิเคราะห์ผลกระทบบริษัทจดทะเบียน SET
งาน: แตกคำถาม/เหตุการณ์ออกเป็น frame เพื่อใช้ค้นหาบริษัท ห้ามเดาข้อเท็จจริงเกี่ยวกับบริษัทใดๆ

อินพุต: {{question}} | as_of_date: {{as_of_date}}
ให้ตอบเป็น JSON ตาม schema: {what:[], who:[], how:[], when:""}
- what: สินค้า/บริการ/อุตสาหกรรม/ใบอนุญาต/วัตถุดิบที่เหตุการณ์แตะ
- who: บทบาท (ผู้ผลิต/ผู้ขาย/ผู้นำเข้า/ผู้ถือหุ้น/ผู้รับจ้างผลิต)
- how: กลไกผลกระทบ (รายได้ลด/ต้นทุนเพิ่ม/หยุดจำหน่าย/ต้องขอใบอนุญาต)
- when: timing เทียบ as_of_date

INPUT   question = "ณ 1 ม.ค. 2566 หุ้นใดมี exposure ต่อ Digital Asset/Crypto"   as_of_date = 2023-01-01

OUTPUT

{
  "what": ["สินทรัพย์ดิจิทัล", "คริปโทเคอร์เรนซี", "ศูนย์ซื้อขายสินทรัพย์ดิจิทัล (exchange)", "โทเคนดิจิทัล"],
  "who":  ["ผู้ได้รับใบอนุญาต ก.ล.ต.", "ผู้ถือหุ้นใน exchange", "ผู้ลงทุน/ผู้ขุดเหรียญ"],
  "how":  ["รายได้จากค่าธรรมเนียมซื้อขาย", "การด้อยค่าเงินลงทุนในสินทรัพย์ดิจิทัล"],
  "when": "ณ 2023-01-01 — ข้อมูลที่เกิดหลังวันนี้ถูกตัดทิ้ง"
}

ขั้นนี้แปลง EventFrame ให้เป็น ExposureCriteria โดยวิเคราะห์ตาม taxonomy 7 มิติ ได้แก่ ผลิตภัณฑ์/บริการ, วัตถุดิบ, ลูกค้า/ตลาด, ช่องทางจำหน่าย, ใบอนุญาต, ที่ตั้ง และ business segment

Query expansion — เพิ่มคำพ้องความ ชื่อแบรนด์ และชื่อใบอนุญาต ทั้งภาษาไทยและอังกฤษ เพื่อให้ค้นพบเอกสารที่เกี่ยวข้องได้ครบมากขึ้น

เจาะลึก ผลลัพธ์ที่ได้นำไปใช้สองทาง คือเป็นเงื่อนไข graph match และเป็น query text สำหรับ vector search — ดูที่ criteria_query_text()

📝 Prompt ที่ใช้จริง (จาก prompts/map_exposure.md — Gemini Flash, temperature 0)

ขั้นนี้ป้อน EventFrame และ taxonomy ให้ Gemini Flash แล้วรับ ExposureCriteria พร้อมชุดคำค้นขยายกลับมา:

อินพุต: EventFrame {{frame}} + taxonomy {{taxonomy}}
งาน: แปลง "ประเด็น/เหตุการณ์" เป็น ExposureCriteria 7 มิติ + query_expansion เพื่อเพิ่ม recall

กฎการทำ query_expansion (สำคัญต่อความแม่นยำ — กัน false positive ข้ามอุตสาหกรรม):
- ใส่ได้: synonym ไทย/อังกฤษ, ชื่อแบรนด์/ผลิตภัณฑ์, ชื่อทางวิทยาศาสตร์, ชื่อใบอนุญาต/มาตรฐาน,
  คำที่เฉพาะเจาะจงกว่า (hyponym), และ แนวคิด/เทคโนโลยีที่เกี่ยวข้องใกล้ชิดในโดเมนเดียวกัน
- ห้าม: หมวดหมู่กว้าง (hypernym) ที่ครอบ "อุตสาหกรรมอื่น" ที่ไม่เกี่ยวกับแก่นคำถาม
  เช่น "รถยนต์ไฟฟ้า" → EV, แบตเตอรี่ EV, สถานีชาร์จ — แต่ห้าม "ยานยนต์"/"พลังงาน" ลอย ๆ
- เกณฑ์ตัดสิน: คำขยายต้องทำให้ "เจอบริษัทที่ทำสิ่งที่ถามจริง ๆ" ไม่ใช่ "บริษัทใดก็ได้ในหมวดพ่อแม่"

มิติ exposure 7 มิติมาตรฐาน = product_service / raw_material / customer_market /
distribution_channel / license / location / business_segment — ถ้าเหตุการณ์กระทบผ่านมิติอื่น
(แหล่งเงินทุน, เทคโนโลยี/IP, พันธมิตร/JV, กฎระเบียบ, FX, ราคาโภคภัณฑ์, ESG) ให้ใส่ใน other_dimensions

ตอบเป็น JSON ตาม schema ExposureCriteria

INPUT   EventFrame จากขั้น 1 (ด้านบน) + taxonomy 7 มิติ

OUTPUT (JSON — ExposureCriteria)

{
  "theme_key": "digital_asset_crypto",
  "theme_label_th": "สินทรัพย์ดิจิทัล/คริปโท",
  "product_service": ["ศูนย์ซื้อขายสินทรัพย์ดิจิทัล", "นายหน้าสินทรัพย์ดิจิทัล", "การขุดเหรียญ"],
  "license": ["ใบอนุญาตประกอบธุรกิจสินทรัพย์ดิจิทัล (ก.ล.ต.)"],
  "business_segment": ["ธุรกิจสินทรัพย์ดิจิทัล"],
  "other_dimensions": ["เงินลงทุนในโทเคน/เหรียญ", "การร่วมทุน (JV) กับผู้ประกอบการ DA"],
  "query_expansion": ["crypto", "คริปโท", "สินทรัพย์ดิจิทัล", "bitcoin", "โทเคน", "ICO",
                      "exchange", "ก.ล.ต.", "Validator Node", "Bitkub", "KUB", "..."]
}
(มิติที่ไม่เกี่ยว เช่น raw_material / customer_market เว้นว่างได้)

ขั้นนี้ค้นหา candidate แบบ recall สูง คือยังไม่ตัดบริษัทใดออก ปล่อยให้ขั้น 4 เป็นผู้ตัดสิน:

① Graph match — ดึงทุกบริษัทที่มีเส้นเชื่อม EXPOSED_TO / PRODUCES / HOLDS_LICENSE / HAS_SEGMENT ตรงกับ criteria โดยแยกว่าเป็น current หรือ historical ด้วย valid_from/valid_to เทียบกับ as_of

② Vector search — ดึง top_k chunks ที่ match query ที่สุด (กรอง doc_date <= as_of) แล้วเก็บ symbol ที่พบเพิ่มเติม

③ Union — รวมเป็น candidate set

เจาะลึก retrieve() คืน RetrievalResult ซึ่งมี candidates, graph_current, graph_historical, vector_hits และ query_vector สำหรับ theme ที่อยู่ใน taxonomy ระบบจะ "pin" chunk ที่ใช้สร้าง edge เข้าไปในขั้น assess เพื่อให้ผลคงที่ (deterministic) ส่วน surprise theme จะไม่ pin เพื่อป้องกัน evidence แกว่ง

🔎 ตรรกะ/Query ที่ใช้ (ไม่ใช้ LLM)

ขั้นนี้ไม่มี prompt — ระบบค้นฐานข้อมูลโดยตรงด้วย 2 วิธีพร้อมกัน แล้วรวมผลเข้าด้วยกัน:

① Spanner Graph query — ดึงทุกบริษัทที่มีเส้นเชื่อม EXPOSED_TO ยังมีผล ณ as_of:

GRAPH corp_radar
MATCH (c:Company)-[e:EXPOSED_TO]->(t:Theme {key: @theme})
WHERE e.valid_from <= @as_of
  AND (e.valid_to IS NULL OR e.valid_to > @as_of)   -- เฉพาะ current ณ as_of
RETURN c.symbol, e.source_chunk_id, e.confidence;

② Vector search — ค้น chunks ที่ความหมายใกล้เคียง query_expansion โดยกรอง doc_date <= as_of แล้ว union กับผลกราฟ

INPUT   criteria จากขั้น 2 + as_of = 2023-01-01

OUTPUT

candidates       = {BTC: current, COMAN: current, PROEN: current, AS: current, BC: current, ...}
graph_current    : บริษัทที่ยังมี exposure ณ 1 ม.ค. 66
graph_historical : บริษัทที่เคยมีแต่เลิกไปก่อน as_of
vector_hits      : chunk หลักฐานเพิ่มเติมที่ความหมายใกล้เคียง
pinned           : source_chunk_id ที่ใช้สร้าง edge → ส่งต่อให้ขั้น 4 (ให้ผลคงที่)
(ข่าวปี 2566 เป็นต้นไป ถูกกรองทิ้งเพราะ doc_date > as_of)

สำหรับแต่ละบริษัท ระบบจะดึงหลักฐานเฉพาะบริษัทนั้น จากนั้นrerank จัดอันดับให้หลักฐานที่ตรงประเด็นที่สุดอยู่บนสุด ลดทั้ง token และ noise แล้วเลือก top_n เข้าสู่การประเมิน

ขั้นนี้แบ่งหน้าที่ออกจากกันอย่างชัดเจน: LLM ทำหน้าที่เพียง "อ่านหลักฐานแล้วสกัดข้อมูล" เท่านั้น ส่วน "การตัดสินระดับผลกระทบ" เป็นหน้าที่ของโค้ดที่ทำงานตามตาราง Analysis Logic ของ SET แบบ deterministic โดย LLM จะสกัดข้อมูล 4 อย่างจากหลักฐาน ได้แก่ (1) exposure_type ว่าบริษัทเกี่ยวข้องโดยตรง โดยอ้อม เคยเกี่ยวข้องในอดีต หรือไม่มีความเกี่ยวข้อง (2) สัดส่วนรายได้ของธุรกิจที่เกี่ยวข้อง หาก disclosure ระบุตัวเลขไว้ (3) materiality สำรองจากตัวชี้วัดอื่น เช่น เงินลงทุน สินทรัพย์ หรือกำลังการผลิต ซึ่งใช้เมื่อไม่มีตัวเลขรายได้ และ (4) direction ว่าผลกระทบเป็นบวกหรือลบ โดยพิจารณาจากทิศทางของเหตุการณ์ในคำถาม ไม่ใช่จากน้ำเสียงของเอกสาร ทั้งนี้ หากคำถามไม่ระบุทิศทาง ระบบจะตอบว่า "ไม่ระบุ" ไม่เดาเอง จากนั้นโค้ดจะตัดเกณฑ์ Materiality จากสัดส่วนรายได้ (ตั้งแต่ 20% ขึ้นไป = สูง, 10–19% = ปานกลาง, ต่ำกว่า 10% = ต่ำ) แล้วนำไป derive ระดับผลกระทบจากตารางโดยตรง ผลก็คือ LLM ไม่มีสิทธิ์ชี้ขาดระดับผลกระทบเองได้เลย จึงป้องกันทั้งการแต่งเรื่องและความไม่คงเส้นคงวาของคำตอบได้อย่างเป็นระบบ

นอกจากนี้ยังระบุ Direction ว่าเป็นบวกหรือลบ และ Impact type ว่าตรงหรืออ้อม ส่วนใดที่กระทบ และเป็นผลระยะสั้น กลาง หรือยาว

เจาะลึก เนื่องจาก POC มีแค่ 15 บจ. ระบบจึงประเมินทุกบริษัทที่รู้จักในทุกครั้ง แทนการพึ่ง rank cutoff ที่อาจแกว่งตรงขอบ วิธีนี้ทำให้ candidate set คงที่ ได้ stability 100% และไม่พลาดบริษัทใด การประเมินรันแบบขนานด้วย ThreadPoolExecutor โค้ดอยู่ที่ assess_company() และ prompts/assess_impact.md

📝 Prompt ที่ใช้จริง (จาก prompts/assess_impact.md — Gemini Flash, temperature 0, รันทีละบริษัท)

ขั้นนี้ป้อนหลักฐานเฉพาะของแต่ละบริษัทให้ LLM อ่าน แล้วให้ LLM สกัดข้อมูล 4 ค่า เพื่อส่งต่อให้โค้ดคำนวณระดับผลกระทบจากตาราง Impact Matrix:

อินพุต: symbol {{symbol}} + คำถาม/เหตุการณ์ {{scenario}} + evidence chunks {{evidence}} (มี chunk_id)
        + criteria {{criteria}} + as_of {{as_of_date}}

ทำตาม Analysis Logic ของ SET (ระบบจะคำนวณ Impact Level เองจากตาราง — งานของคุณคือประเมิน "อินพุต" ของตาราง):
1. exposure_type — direct (ทำ/ลงทุน/ถือใบอนุญาตโดยตรง) / indirect (ทางอ้อม ต้องมีประโยคในเอกสารเชื่อมชัด)
   / historical (เคยทำแต่เลิกก่อน as_of) / none (ไม่พบ; แผน/MOU/มติที่ยังไม่เริ่ม = none)
2. revenue_proportion_pct — สัดส่วนรายได้ธุรกิจที่เกี่ยวข้อง (%) ถ้า disclosure ระบุ; ไม่ระบุใส่ null
3. materiality (ใช้เมื่อไม่มี revenue %) — ประเมินจากเงินลงทุน/สินทรัพย์/กำลังผลิต: high/medium/low
4. direction บวก/ลบ/ไม่ระบุ — พิจารณาจาก "ทิศทางของเหตุการณ์ในคำถาม" ไม่ใช่ sentiment ในเอกสาร
   ถ้าคำถามไม่บอกทิศทาง (แค่ "มี exposure") → ไม่ระบุ อย่าเดา
5. reasoning 3-5 บรรทัด — ระบุ Materiality + ลักษณะ exposure + ส่วนที่กระทบ + ระยะเวลา + มาตรการผ่อนผัน (ถ้ามี)

กฎเหล็ก (กัน hallucination):
- ใช้เฉพาะข้อมูลใน evidence; ทุกประโยคใน reasoning ต้องมาจาก chunk ที่ให้
- คืน citation_ids ที่ "มีอยู่จริง" ใน evidence เท่านั้น
- หลักฐานไม่พอ/ไม่ตรงประเด็น → exposure_type="none"

ตอบ JSON: {exposure_type, revenue_proportion_pct, materiality, direction, reasoning, citation_ids[]}

INPUT   symbol = "PROEN" + คำถามเดิม + evidence chunks ของ PROEN (แต่ละชิ้นมี chunk_id) + criteria + as_of

OUTPUT (JSON — สิ่งที่ LLM สกัด)

{
  "exposure_type": "direct",
  "revenue_proportion_pct": null,
  "materiality": "low",
  "direction": "ไม่ระบุ",
  "reasoning": "ลงทุนตรงในเหรียญ KUB ทำหน้าที่ Validator Node ร่วมกับ Bitkub มูลค่าเงินลงทุนเล็กเมื่อเทียบสินทรัพย์รวม (materiality ต่ำ) กระทบด้าน 'เงินลงทุน' ระยะกลาง คำถามไม่ระบุทิศทางราคา จึงเป็น 'ไม่ระบุ'",
  "citation_ids": ["PROEN_onereport_2565_p192", "PROEN_news_2565_da"]
}

จากนั้น โค้ด (ไม่ใช่ LLM) นำ exposure_type=direct × materiality=low ไป lookup ตาราง Impact Matrix ได้ผลเป็น "น้อย" — LLM ไม่มีสิทธิ์ชี้ขาดระดับผลกระทบเองได้เลย

เรียง rows ด้วยลำดับคงที่ตาม severity ก่อน แล้วตาม symbol เรียง A→Z จากนั้นประกอบเป็นตาราง Symbol | Impact | Reasoning | Source

แนบ metrics: response_time_sec (จับด้วย time.perf_counter) และ token cost (USD + THB) จาก TokenMeter

เจาะลึก renderer มีให้เลือก 3 แบบ ได้แก่ Markdown table สำหรับ CLI/chat, Excel ที่บันทึกลง outputs/<run_id>.xlsx สำหรับแนบ presentation และ JSON ฉบับเต็มสำหรับ audit — ดูที่ sort_rows() ใน src/agent/format.py

🧾 ตรรกะที่ใช้ (โค้ดล้วน ไม่ใช้ LLM)

ขั้นนี้ไม่มี prompt — เป็นโค้ดล้วนที่เรียงแถวและประกอบตารางจากผลขั้น 4 ทั้งหมด:

INPUT   rows = ผลประเมินทั้ง 15 บริษัทจากขั้น 4 + metrics

OUTPUT

| Symbol | Impact       | Reasoning (ย่อ)                                    | Source                        |
|--------|--------------|---------------------------------------------------|-------------------------------|
| BTC    | มาก          | นายหน้าซื้อขายสินทรัพย์ดิจิทัลโดยตรง...              | ข่าวแจ้งตลาด 2565, One Report |
| COMAN  | ปานกลาง       | ธุรกิจเกี่ยวกับสินทรัพย์ดิจิทัล...                    | One Report 2565               |
| PROEN  | น้อย          | ลงทุนในเหรียญ KUB เป็น Validator Node...            | One Report 2565 น.192         |
| ...    | ไม่มีผลกระทบ   | (อีก 10 บริษัท พร้อมเหตุผลว่าไม่พบหลักฐาน)          | ...                           |

⏱ response_time ≈ 40 วินาที   💰 cost ≈ 7 บาท/คำถาม