SymbolicAI: มุมมองเชิงประสาท-สัญลักษณ์ต่อ LLM

• SymbolicAI เป็น เฟรมเวิร์กการเขียนโปรแกรมเชิงประสาท-สัญลักษณ์ ที่ผสาน Python และ LLM เข้าด้วยกันได้อย่างเป็นธรรมชาติ
• รองรับทั้งการจัดการเชิงไวยากรณ์ (syntactic) และเชิงความหมาย (semantic) ผ่าน อ็อบเจ็กต์ Symbol ซึ่งเป็นหน่วยพื้นฐาน
• ฟีเจอร์ Contracts นำการตรวจสอบความถูกต้องของข้อมูลและตรรกะการแก้ไขอัตโนมัติมาใช้กับการคาดการณ์ของ LLM เพื่อรับประกันความน่าเชื่อถือและความทนทาน
• สามารถเชื่อมต่อและใช้งานร่วมกับ เอนจินภายนอกหลากหลายตัว (OpenAI, Anthropic, huggingface ฯลฯ) รวมถึงเว็บเสิร์ช การสร้างภาพ และการประมวลผลเสียง
• จุดเด่นคือ ระบบจัดการคอนฟิกแบบอิงลำดับความสำคัญ และความสามารถในการปรับแต่งที่ทรงพลัง

---

SymbolicAI: ภาพรวมโครงการและความสำคัญ

• SymbolicAI เป็น ไลบรารีแบบ Neuro-Symbolic ที่รองรับการผสาน การเขียนโปรแกรม Python แบบดั้งเดิม กับ LLM (โมเดลภาษาขนาดใหญ่) ที่ตั้งโปรแกรมได้และมีความแตกต่างชัดเจน ได้อย่างเป็นธรรมชาติ
• ด้วยการออกแบบแบบโมดูลาร์ จึงสามารถ ขยาย, สลับเอนจิน และ เชื่อมต่อเครื่องมือ ได้อย่างง่ายดาย
• รองรับการทำงานร่วมกับเครื่องมือหลากหลาย เช่น เอนจินแบบ local, เว็บเสิร์ช, การสร้างภาพ ทำให้เหมาะทั้งกับการใช้งานเชิงทดลองและเชิงปฏิบัติ

แนะนำแนวคิดหลัก

Primitives

• Primitives คือหน่วยประกอบพื้นฐาน โดยแกนหลักคืออ็อบเจ็กต์ Symbol

• อ็อบเจ็กต์ Symbol รองรับทั้งโหมด เชิงไวยากรณ์ (syntactic) และ เชิงความหมาย (semantic)

  • เชิงไวยากรณ์ (syntactic): ทำงานเหมือนค่า Python ทั่วไป รองรับการเปรียบเทียบ การคำนวณ และการทำงานที่ปลอดภัยและรวดเร็ว
  • เชิงความหมาย (semantic): เชื่อมต่อกับเอนจินเชิงประสาท-สัญลักษณ์ เข้าใจ ความหมายและบริบท และรองรับการเปรียบเทียบ/จัดการเชิงความหมายที่ยืดหยุ่น

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

วิธีสลับโหมดเชิงความหมาย/เชิงไวยากรณ์

• ระบุออปชัน semantic=True ตอนสร้าง
• สลับได้อย่างอิสระผ่านพร็อพเพอร์ตี .sem (semantic) และ .syn (syntactic)
• แปลงเป็นโหมดเชิงความหมายอัตโนมัติเมื่อเรียกใช้ฟังก์ชันเชิงความหมาย (เช่น map)

ตัวอย่างการดำเนินการ

• == : ในโหมดเชิงไวยากรณ์คือการเปรียบเทียบแบบ literal ส่วนโหมดเชิงความหมายคือความเท่าเทียมเชิงความหมาย (เช่น 'Hi' == 'Hello' เป็น True)
• +, &, .startswith(), .choice(), .foreach(), .cluster(), .similarity() เป็นต้น
• รองรับ การจัดการเชิงความหมายที่ซับซ้อนและการเชื่อมตรรกะแบบต่อเนื่อง

Contracts

• นำหลักการ Design by Contract มาใช้เพื่อชดเชยความไม่แน่นอนของ LLM
• กำหนด โมเดลข้อมูลและกฎการตรวจสอบความถูกต้อง ผ่านเดคอเรเตอร์
• รองรับฟีเจอร์ด้านเสถียรภาพหลากหลาย เช่น การแก้ไขข้อผิดพลาดอัตโนมัติ การลองใหม่ และการสะสมประวัติ เมื่อมีอินพุต/เอาต์พุตที่ไม่ถูกต้อง
• รองรับโมเดลข้อมูลของ Pydantic การตรวจสอบฟิลด์ การสร้างพรอมป์อัตโนมัติ และการจัดการข้อผิดพลาดในตัว

คุณสมบัติหลักของฟีเจอร์ Contracts

• pre_remedy/post_remedy: แก้ไขข้อผิดพลาดของอินพุต/เอาต์พุตอัตโนมัติ
• accumulate_errors: ป้อนประวัติข้อผิดพลาด
• remedy_retry_params: ระบุพารามิเตอร์ควบคุมการลองใหม่ (จำนวนครั้งที่ลอง, ดีเลย์, แบ็กออฟ ฯลฯ)

ตัวอย่างแบบละเอียดและคำอธิบายเพิ่มเติมสามารถดูได้จากเอกสารทางการและหน้า DeepWiki

เอนจินภายนอกและความสามารถในการขยายฟังก์ชัน

• ปัจจุบันรองรับเอนจินเชิงประสาท-สัญลักษณ์หลายตัว เช่น OpenAI, Anthropic (ทั้ง API/โลคัล)
• สามารถรันเอนจินของตนเองแบบโลคัลได้ เช่น {huggingface, llama.cpp}
• รองรับการเชื่อมต่อเอนจินเพิ่มเติมสำหรับเสียง ภาพ และเว็บเสิร์ช (ต้องติดตั้งแพ็กเกจ dependency เพิ่มเติมแยกต่างหาก)
• มอบฟังก์ชัน ML/AI สำหรับใช้งานจริงแบบบูรณาการ เช่น การค้นหา การทำคลัสเตอร์ OCR และการทำดัชนี

ระบบจัดการคอนฟิก (Configuration)

การจัดการไฟล์คอนฟิกแบบอิงลำดับความสำคัญ

• โหมดดีบัก (โฟลเดอร์โปรเจกต์): สำหรับการพัฒนาและทดสอบ

• การตั้งค่า แยกตามสภาพแวดล้อม Python ({python_env}/.symai/)

• การตั้งค่า โกลบอล (~/.symai/): สำหรับค่าเริ่มต้น/การสำรอง

• ระบบจะนำค่าที่มีลำดับความสำคัญสูงกว่าจากทั้งสามตำแหน่งมาใช้โดยอัตโนมัติ

ไฟล์คอนฟิกหลัก

• symai.config.json: จัดการออปชันหลักของ SymbolicAI
• symsh.config.json, symserver.config.json: การตั้งค่าสำหรับเชลล์และเซิร์ฟเวอร์

ตัวอย่างไฟล์คอนฟิก

• ระบุค่าอย่างชัดเจน เช่น API Key, ชื่อโมเดล, ประเภทเอนจิน
• ออปชัน SUPPORT_COMMUNITY ใช้สำหรับยินยอมให้เก็บรวบรวมข้อมูล (เพื่อการวิจัยและปรับปรุงคุณภาพ)
• สามารถเปิด/ปิดคำเตือนผู้ใช้ผ่านตัวแปรสภาพแวดล้อม SYMAI_WARNINGS

การตั้งค่าสภาพแวดล้อมและการทดสอบ

• ต้องใช้แพ็กเกจภายนอก เช่น ffmpeg (เสียง), chromedriver (เว็บครอว์เลอร์)
• รันทดสอบด้วย pytest และรองรับการตรวจสอบ coverage

เอกสารอ้างอิงและแนวทางการใช้งาน

• มีเอกสารอ้างอิงจำนวนมากและวิดีโอสอนใช้งานบน DeepWiki และ GitBook ทางการ
• มีบทความวิชาการบน Arxiv ที่อธิบายทฤษฎีและรายละเอียดของเฟรมเวิร์ก
• ใช้ไลเซนส์ BSD-3-Clause

บทสรุป

• SymbolicAI เป็น เฟรมเวิร์กที่เหมาะอย่างยิ่งสำหรับบริการที่เน้นความน่าเชื่อถือและงานวิจัยเชิงทดลองบนพื้นฐาน LLM โดยผสาน ความชัดเจนของระบบเชิงสัญลักษณ์ เข้ากับ ความยืดหยุ่นของโครงข่ายประสาท
• การออกแบบที่เน้นคอนฟิก การขยายฟังก์ชัน และการสร้างความน่าเชื่อถือ ทำให้มีศักยภาพต่อการประยุกต์ใช้หลากหลายรูปแบบสำหรับสตาร์ทอัพและผู้ปฏิบัติงานสาย IT

การสนับสนุนนักพัฒนาและชุมชน

• เปิดเผยทรัพยากรสำหรับการคอนทริบิวต์ ช่องทางติดต่อ และช่องทางสนับสนุน (อีเมล เว็บไซต์ Discord) อย่างชัดเจน

[GN⁺]

ความคิดเห็นจาก Hacker News

• เวทมนตร์แบบงูๆ ปลาๆ ลักษณะนี้น่าสนใจมากจริงๆ
  ตัวอย่างที่ผมชอบคือการใช้ semantic map lambda
  เช่น ถ้ามีรายการ Symbol ชื่อ S เมื่อเรียก S.map('แปลงผลไม้ทั้งหมดเป็นผัก') ก็จะมีแค่ผลไม้ที่ถูกเปลี่ยนเป็นผัก ส่วนอย่างอื่นคงเดิม
  และยังรับพารามิเตอร์ตามบริบทเพื่อใช้เปรียบเทียบได้ด้วย เช่น ในบริบทของคำทักทาย จะตัดสินว่า 'Hello, good morning!' กับ 'Hi there, good day!' มีความหมายเดียวกันหรือไม่ หรือจะเทียบ 'Good morning, sir.' กับ 'Hey, what’s up?' ในแง่ระดับความสุภาพก็ได้
  นอกจากนี้ยังเชื่อมเชิงตรรกะแบบมีความหมายได้เหมือนตัวดำเนินการบิต ใช้ & รวมกฎกับข้อสังเกตแบบรายการหัวข้อย่อยแล้วสรุปผลออกมา
  ฟังก์ชัน interpret() ดูทรงพลังมาก
  อยากรู้ว่าอะไรเป็นแรงบันดาลใจให้ OP ทำโปรเจ็กต์นี้ นำไปใช้จริงในด้านไหนบ้าง และกรณีใช้งานที่ชอบที่สุดคืออะไร

  • ขอแนะนำ ไลบรารี dataframe ของ Python ชื่อ Lotus
    มันขยาย relational operation หลักทั้งหมดให้ใช้งานแบบมีความหมายเชิงความหมายได้ง่าย
    แต่ละการเรียกจะกลายเป็นจุดของ “โมเดล” ทำให้ภายหลังขยายไปทางแมชชีนเลิร์นนิงได้ง่ายด้วย
    แม้แต่ cloud SQL อย่าง Snowflake ก็ดูเหมือนกำลังค่อยๆ ไปในทิศทางนี้
    ที่ louie.ai เราสร้างระบบคล้ายกัน ผ่าน AI notebook, dashboard และ API เพื่อจัดการข้อมูลแบบโต้ตอบได้จาก (Splunk, Databricks, graph DB ฯลฯ) และตรวจจับ symbolic + semantic operator แบบอัตโนมัติตามบริบท
    ช่วยงานจริงได้มาก
    use case หลักของผมคือ:
    ใช้ semantic map ดึงการแจ้งเตือนจากดัชนีของ Splunk แล้วติดธงรายการที่น่าสงสัย พร้อมใส่คำอธิบาย
    จากนั้นใช้ semantic reduce เพื่อสรุปออกมาเป็นรายงานภาษาธรรมชาติอีกที

  • ถามว่าทำไมผลลัพธ์ของการแปลงแครอตของแอปเปิลให้เป็นผักถึงออกมาแบบนั้น

  • ถ้าจะตอบคงยาวมาก
    โปรเจ็กต์เริ่มมาตั้งแต่ปลายปี 2022 แต่ช่วงหลังแค่โมเดลดีขึ้น ส่วนพื้นฐานหลักๆ มีมาตั้งแต่ยุค GPT-3 แล้ว
    DbC (Design by Contract) ที่เพิ่งออกมานี่มีเอกลักษณ์มากจริงๆ
    มันแก้ปัญหาทุกอย่างที่ผมเคยเจอเกี่ยวกับเอเจนต์ได้ โดยเฉพาะเวลาต่อ contract หลายตัวเป็นสายเดียวกัน guardrail จะถูกส่งต่ออย่างเป็นธรรมชาติ เลยมีประสิทธิภาพมาก
    เครื่องมือคัสตอมแทบทั้งหมดผมทำเอง
    เช่น web search ของ OpenAI ก็ดี แต่ปรับแต่งได้น้อยเกินไป เลยพัฒนา deep research agent ของตัวเองขึ้นมาใช้
    เธรดตัวอย่างผลลัพธ์วันแรก
    ตอนนี้ผมกำลังทำบริษัทอยู่ และได้สร้างระบบอัตโนมัติสำหรับสร้างเอกสารแบบ e2e โดยเชื่อม contract 3 ตัวเข้าด้วยกัน
    ดู เดโม PDF ได้
    พรอมป์ต์อินพุตคือ
    “สร้างรายงานที่เปรียบเทียบทั้งภาพรวม เช่น การวิเคราะห์แพตเทิร์นจากไฟล์, รูปแบบพรอมป์ต์หลายแบบ (XML, markdown ฯลฯ), แนวโน้มการประจบ, วิธีใช้เครื่องมือ, ethical guardrail, ความพิเศษเชิงสถาปัตยกรรม ฯลฯ”
    ผมแนะนำ contract ครั้งแรกใน โพสต์นี้ เมื่อมีนาคม 2025 และหลังจากนั้นมันก็พัฒนาไปมาก แต่เจตนาและแรงจูงใจพื้นฐานยังเหมือนเดิม

• การใช้ตัวดำเนินการเชิงความหมายอย่าง ==, + ได้ ให้ความรู้สึกเหมือนใส่ปุ๋ยให้กับไอเดียสดใหม่
  ให้ความตื่นเต้นคล้ายตอนเริ่มรู้จักพีชคณิตของแนวคิดในช่วงแรกๆ ที่ word embedding ออกมา พร้อมตัวอย่างอย่าง ‘King - Man + Woman = Queen’
  แต่การรวม neural network กับสัญลักษณ์ (logic) ตรงนี้ก็ยังตื้นหรือยังแยกส่วนกันอยู่ เหมือนกับระบบส่วนใหญ่
  อ้างอิง
  นวัตกรรมที่แท้จริงน่าจะเกิดขึ้นได้เมื่อมีการรวมกันอย่างลึกซึ้งกว่านี้มากในอนาคต
  ที่บริษัทของเรา (Onton) ก็วิจัยไปในทิศทางนั้นเหมือนกัน
  เป้าหมายคือ 1) representation ที่รวมเป็นหนึ่งอย่างสมบูรณ์ (ไม่ใช่ทั้ง symbolic/ไม่ใช่ทั้ง deep learning), 2) เรียนรู้ต่อเนื่องได้แม้มีข้อมูลมี noise น้อยมาก (ไม่ลืม), 3) ความน่าเชื่อถือของการคำนวณเชิงคณิตศาสตร์/สัญลักษณ์ 100%, 4) ไม่มี hallucination เลย
  ตอนนี้การเอาหลายระบบมาต่อกันแบบ hot glue ก็ยังมีประโยชน์ แต่สถาปัตยกรรมแบบบูรณาการจะพลิกกระดานได้

• แชร์ลิงก์ โค้ดโน้ตบุ๊กทางการ ที่อธิบายและยกตัวอย่างไว้ดี และ PDF ของเปเปอร์ทางการ

• รายงานข้อผิดพลาดในโค้ด (valid_sizes ยังไม่ได้ถูกนิยามใน ‘correctness contracts’)

  • ขอบคุณสำหรับฟีดแบ็กครับ เป็นร่องรอยที่หลงเหลือจากการรีแฟกเตอร์ ตอนนี้แก้แล้ว

• ขอบคุณทุกคนที่แสดงความคิดเห็นและสนับสนุนหัวข้อนี้
  ไม่คิดว่าจะได้รับกระแสตอบรับแบบนี้ และติดต่อกันได้เสมอทางอีเมล/ทวีต
  คุยกับทุกคนแล้วดีใจมากจริงๆ

• มีจุดที่น่าเสียดาย
  คำว่า ‘Symbolic AI’ เองนั้นมีนิยามที่ชัดเจนอยู่แล้ว

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

• มีเรื่องที่อยากรู้
  นโยบายค่าใช้จ่ายเป็นอย่างไร
  หมายความว่าทุกครั้งที่รันหนึ่งบรรทัดที่มี natural language operation อยู่ในนั้น (ยิ่งถ้าใช้ external API ก็ยิ่งชัด) จะต้องจ่ายค่าอนุมานของ LLM ไปเรื่อยๆ ใช่ไหม
  เช่นแม้แต่ตอนที่ฟังก์ชัน "symbolic" ถูกเรียกซ้ำๆ อยู่ในลูปก็ด้วยหรือเปล่า

  • ใช่
    เช่นถ้าใช้ OpenAI API ก็จะมีการเรียก OpenAI หนึ่งครั้งต่อ semantic operation ทำให้เกิดค่าใช้จ่าย
    แต่ถ้าโฮสต์ local LLM เองด้วย llama.cpp หรืออย่างอื่น ก็มีแค่ค่าโฮสต์ ไม่มีค่าการอนุมานแยก

  • น่าจะต้องมีอะไรอย่างแคชแน่ๆ

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

• คล้าย functional programming (FP) ที่ Symbol ทุกตัวทำงานเป็นค่าบริสุทธิ์
  การดำเนินการต่างๆ ถูกประกอบเข้าด้วยกันเป็นโฟลว์ที่สะอาดและตรวจสอบย้อนกลับได้
  โมเดลจะเข้ามาแทรกในขั้นที่กำกวม
  เหมือน IO operation ใน FP การเรียก generative model ถูกมองเป็น side effect ที่ถูกจำกัดขอบเขต
  ปกติ reasoning graph จะเป็น deterministic และจะส่งต่อให้โมเดลเฉพาะเมื่อจำเป็น
  เดโมน่าทึ่งมากจริงๆ

  • เกือบถูกทั้งหมด
    ผมออกแบบมันให้เป็นเชิงฟังก์ชันตั้งแต่แรก
    ในระดับ low-level ก็ยึดหลักการเชิงฟังก์ชันทั้งหมด และภายในก็ใช้ชื่ออย่าง functional.py หรือ core.py ด้วย
    ยังใช้ decorator อยู่ทั่วไปด้วย ซึ่งช่วยมากในเรื่องรีแฟกเตอร์ การขยายระบบ และการจัดการบั๊ก

• ทุกวันนี้ LLM ก็เขียนโค้ดได้หมดแล้ว
  เลยสงสัยว่าโครงสร้างอย่าง Symbol ที่เก็บบริบทและจัดการได้ง่ายผ่าน Python operator
  มีข้อได้เปรียบอะไรเมื่อเทียบกับการที่มนุษย์คอยตรวจเช็กแล้วเขียนโค้ดเองทีละส่วน
  เช่นการแปลงเชิงความหมายแบบนั้น แม้จะเขียนด้วยไวยากรณ์ลักษณะนี้ได้โดยตรง แต่ก็อาจแค่พรอมป์ต์ให้ LLM สร้างโปรแกรมที่แปลงรายการผลไม้เป็นผักก็ได้ไม่ใช่หรือ
  อยากเข้าใจว่าความแตกต่างเชิงสาระคืออะไร

  • ผมคิดว่ามันช่วยลด hallucination ได้
    ถ้าให้ LLM สร้างระบบที่เป็นทางการขึ้นมา การตรวจสอบจะง่ายกว่าระบบอเนกประสงค์มาก