WUPHF - ระบบที่ให้เอเจนต์ดูแลวิกิ LLM สไตล์ Karpathy ได้ด้วยตัวเอง
(github.com/nex-crm)- เลเยอร์วิกิสำหรับเอเจนต์ AI ที่ทำงานบนพื้นฐานของ Markdown & Git
- เป็นเลเยอร์ฐานความรู้แบบ LLM-native ที่ออกแบบมาเพื่อให้เอเจนต์ AI สะสมคอนเท็กซ์ข้ามเซสชัน ได้ โดยเก็บไว้แบบโลคัลที่
~/.wuphf/wiki/และสามารถยกไปทั้งชุดด้วยgit clone - แทนที่จะใช้โครงสร้างพื้นฐานขนาดใหญ่อย่าง Postgres, pgvector, Neo4j, Kafka ระบบนี้ใช้เพียง markdown + git สำหรับจัดการความรู้ด้วย BM25 + SQLite โดยไม่ต้องมี vector DB
- เก็บข้อมูลเป็น markdown, ใช้ bleve สำหรับ การค้นหาแบบ BM25 และใช้ SQLite จัดการเมทาดาทาแบบมีโครงสร้าง (facts, entities, edges, redirects, supersedes)
- ในสถานะที่ไม่ใช้ vector DB สามารถทำ recall@20 85% ได้ จากเบนช์มาร์ก 500 artifacts และ 50 queries
- มีแผนจะใช้ sqlite-vec สำหรับกรณีที่คลาสของคิวรีบางประเภทมีผลลัพธ์ต่ำกว่าเกณฑ์นี้
- เอเจนต์แต่ละตัวมี สมุดบันทึกส่วนตัว อยู่ที่
agents/{slug}/notebook/*.mdและเข้าถึง วิกิที่ใช้ร่วมกัน ได้ที่พาธteam/- มีโฟลว์สำหรับ เลื่อนสถานะ (promotion) รายการจากสมุดบันทึกไปเป็นวิกิ หลังจากเอเจนต์หรือมนุษย์รีวิวแล้ว และจะสร้างแบ็กลิงก์ให้อัตโนมัติ
- state machine ขนาดเล็กจะจัดการเรื่องการหมดอายุ (expiry) และการเก็บถาวรอัตโนมัติ
- Per-entity fact log: บันทึกเป็น append-only JSONL ที่
team/entities/{kind}-{slug}.facts.jsonl- worker สำหรับสังเคราะห์จะสร้าง entity brief ใหม่ทุก ๆ N facts และคอมมิตจะถูกบันทึกด้วย git identity แยกชื่อ "Pam the Archivist" ทำให้ตรวจสอบที่มาได้ทันทีจาก
git log - Fact ID เป็น ID แบบกำหนดแน่นอน ที่รวม sentence offset และ canonical slug เมื่อกำหนดแล้วจะไม่มีการเปลี่ยนอีก โดยจะถูกรวมผ่าน redirect stub เท่านั้น
- การ rebuild ให้ผลลัพธ์เหมือนกันในเชิงตรรกะ แต่ไม่รับประกันความเหมือนกันแบบ byte ต่อ byte
- worker สำหรับสังเคราะห์จะสร้าง entity brief ใหม่ทุก ๆ N facts และคอมมิตจะถูกบันทึกด้วย git identity แยกชื่อ "Pam the Archivist" ทำให้ตรวจสอบที่มาได้ทันทีจาก
- รองรับ [[Wikilinks]] และลิงก์เสียจะแสดงเป็นสีแดง โดยมี lint cron รายวันคอยตรวจจับความขัดแย้ง รายการที่ล้าสมัย และวิกิลิงก์ที่เสีย
- ให้บริการ การค้นหาแบบอ้างอิงแหล่งที่มา ผ่าน slash command
/lookupและเครื่องมือ MCP- ตัวจำแนกแบบ heuristic จะส่งต่อคำค้นสั้น ๆ ไปยัง BM25 และส่งคิวรีเชิงบรรยายไปยัง cited-answer loop
- ข้อจำกัดที่ทราบ
- ยังอยู่ระหว่างปรับแต่ง recall และค่า 85% ไม่ใช่ตัวเลขรับประกันแบบทั่วไป
- คุณภาพของการสังเคราะห์ขึ้นอยู่กับคุณภาพของ facts ที่เอเจนต์บันทึกไว้ (garbage in, garbage out) โดย lint ช่วยเสริมได้ แต่ไม่ใช่ judgment engine
- ปัจจุบันรองรับเพียงขอบเขตออฟฟิศเดียว ยังไม่รองรับ cross-office federation
- ให้มาเป็นส่วนหนึ่งของ WUPHF (ออฟฟิศเอเจนต์ AI โอเพนซอร์สที่รองรับ Claude Code, Codex, OpenClaw และ local LLM) แต่ สามารถใช้เฉพาะเลเยอร์วิกิแยกเดี่ยวได้ — หากเชื่อม WUPHF เข้ากับ agent setup เดิม วิกิจะถูกแนบให้อัตโนมัติ
- ไลเซนส์ MIT
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ยังไม่ค่อยเข้าใจประเด็นของ การทำโน้ตอัตโนมัติ เท่าไร แต่ก่อนก็เคยมีวิธีคัดลอกข้อความแล้วแปะลงโน้ต ซึ่งไม่ได้ช่วยอะไรเลย แล้วพอเพิ่มสิ่งนั้นขึ้น 100 เท่า มันจะต่างออกไปจริงหรือ
สำหรับฉัน แก่นของการจดโน้ตคือการอ่านแหล่งข้อมูลอย่างมีวิจารณญาณ ย่อยให้เข้ากับ mental model ของตัวเอง แล้วจึงบันทึกมันไว้
รายละเอียดค่อยกลับไปค้นทีหลังได้ สุดท้ายสิ่งสำคัญคือกระบวนการขัดเกลาโมเดลนั้น
ถ้าอย่างนั้น เป้าหมายอาจเป็นการโยนงานให้ LLM brain ที่ใช้ร่วมกัน แทนที่จะสร้าง mental model นั้นด้วยตัวเองก็ได้
แต่ก็ยังน่าสงสัยมากว่าแนวทางแบบนี้จะสร้างอะไรที่มีคุณค่าจริงต่อเจ้าของผลิตภัณฑ์ได้หรือไม่ ถ้าสินค้าที่มีคุณค่าเกิดจากแค่พรอมป์ต์กับ agent harness ได้ ใคร ๆ ก็ทำซ้ำได้ การพัฒนาผลิตภัณฑ์เองก็จะกลายเป็น commodity และสุดท้ายสิ่งที่เหลือมูลค่าอาจมีแค่ token
สมมติฐานของฉันคือแนวคิดของ Paul Graham เรื่อง do things that don’t scale จะยังใช้ได้ต่อไป เพียงแต่เนื้อหาของ งานที่ขยายสเกลไม่ได้ อาจเปลี่ยนไปมาก
ถึงอย่างนั้น ช่วงนี้ฉันก็เพิ่งเริ่มใช้ Obsidian อย่างจริงจัง พอตั้งสกิลสำหรับจดโน้ต ค้นคว้า เชื่อมลิงก์ แยกย่อย และจัดโครงสร้างฐานความรู้ใหม่ไว้แล้ว ก็รู้สึกเหมือนมี ผู้ช่วยดิจิทัล มาคอยจัดระเบียบแทน
ตอนนี้แค่จดความคิดกระจัดกระจายลงไป เอเจนต์ก็ช่วยจัดโครงสร้าง ตั้งคำถามต่อยอด และเชื่อมกับงานอื่นให้เอง ส่วนการอ่านแหล่งข้อมูลและสร้าง mental model ยังเป็นหน้าที่ของฉันอยู่ แต่โน้ตคุณภาพดีแทบจะได้มาแบบฟรี ๆ
เป็นความสิ้นเปลืองมาก
ของส่วนใหญ่แต่แรกก็ไม่จำเป็นต้องเข้าไปอยู่ในโน้ตอยู่แล้ว และ LLM ก็เพิ่ม noise มากเกินไปโดยแทบไม่มีการตรวจสอบหรือกรองเลย
มีวิดีโอที่พูดถึงประเด็นนี้ได้ดี เป็นบทความของ JA Westenberg
https://youtube.com/watch?v=3E00ZNdFbEk
ค่อนข้างน่าสนใจ
ฉันคิดว่าจุดที่เหมาะที่สุดคือ การคัดสรรโดยมนุษย์ และถ้าไม่บริหาร debt หรือ drift อย่างตั้งใจ การปล่อยให้เดินเองแบบไม่มีผู้กำกับก็คงไม่ใช่คำตอบ
ยิ่งชื่อดันไปเหมือน ผลิตภัณฑ์ไร้ประโยชน์และซ้ำซ้อน อย่าง Wuphf.com ที่เคยโผล่ใน The Office ด้วย ก็ยิ่งทำให้นึกแบบนั้น
แค่ใส่คำว่า AI ในชื่อผลิตภัณฑ์ก็เหมือนจะได้เงินระดับหลายพันล้านดอลลาร์ และแค่ใส่ชื่อ Karpathy ลงในบล็อกโพสต์ก็ดูเหมือนจะได้งานเป็นวิศวกรหลักของ Anthropic
มันดูเหมือนมีแต่การรีดเงินจากกระแสตราบเท่าที่ยังฮิตอยู่ โดยไม่ค่อยสนใจว่าลูกค้าต้องการอะไร
ทุกคนกำลังแห่กันเข้าไปแบบขอแค่ได้ฉวยโอกาสตอนมีคลื่นก็ยังดี
แต่ตอนนั้นอย่างน้อยก็มีคนสร้างของจริง และสภาพเงินทุนที่ตึงกว่าก็ช่วยกดความร้อนแรงลงได้บ้าง
กระแส LLM รอบนี้อย่างน้อยก็มีความเป็นไปได้และคุณค่าจริงอยู่พอสมควร แถมยังเป็นเทคโนโลยีที่สนุกดีในการเรียนรู้และลองใช้งาน
ฉันยอมรับมานานแล้วว่าถ้าเงินไหลเข้าที่ไหน และมันไม่ได้ผิดจริยธรรม การคว้าโอกาสตรงนั้นก็นับว่าสมเหตุสมผล ระหว่างที่เงิน VC/PE ยังล้นอยู่ ก็อาจสร้างของเจ๋ง ๆ ที่มีคุณค่าได้
ฉันยังรอ CLI harness ระดับโลกที่จะมาแทน Claude Code อยู่ ต้องการอะไรสักอย่างที่แก้ปัญหาเรื่อง memory และการออกแบบได้
งานเว็บดีไซน์ยังแทบเป็นฝันร้ายถ้าจะทำด้วย LLM
เราทำ PoC ระดับองค์กรด้วย และทั้งหมดนั้นสุดท้ายก็ควบแน่นมาเป็นโปรเจ็กต์นี้ที่ทำขึ้นข้าง ๆ เพื่อช่วยงานส่วนตัวของผมเอง ผลคือ context infra ที่ใช้งานจริงได้สะดวกก็คือสิ่งนี้นี่เอง
ผมไม่ได้สนใจตำแหน่งวิศวกรหลักของ Anthropic ก่อนหน้านี้ผมเป็น Product Manager ที่ HubSpot และรายได้ก็ดีกว่าตอนนี้มาก แถมอีกหลายปีข้างหน้าก็อาจยังหาไม่ได้เท่าระดับนั้น
ที่เดิมพันหลายครั้งและปรับแก้ไปเรื่อย ๆ ก็เพราะได้คุยกับลูกค้าโดยตรงแล้วปล่อยให้มันวิวัฒน์ตามนั้น ขณะที่คู่แข่งเก่า ๆ ยังทำ AI CRM แบบ stealth กันอยู่
ในฐานะคนที่อยู่ในวงการมานาน ผมมองว่าตัวคลื่นไม่สำคัญเท่าไร แต่ใต้คลื่นนั้นมี คุณค่าที่จับต้องได้ ให้เก็บขึ้นมาแน่นอน
ผมเห็นรีวิวนี้มา: https://zby.github.io/commonplace/agent-memory-systems/reviews/wuphf/
นี่เป็น LLM wiki ตัวที่สามในรอบ 24 ชั่วโมงที่ขึ้นหน้าแรก แปลว่าเป็นหัวข้อที่ร้อนแรงจริง
ผมเองก็มีส่วนได้ส่วนเสียในด้านนี้ เลยไม่ได้เป็นกลางเต็มร้อย แต่ก็เคยแยกเขียนไว้ว่าคาดหวังอะไรจากระบบแบบนี้บ้าง
https://zby.github.io/commonplace/notes/designing-agent-memory-systems/
ทุกคนต่างสร้างระบบของตัวเองใหม่หมด ดูจะลงทุนซ้ำซ้อนกันมากเกินไป เลยหวังว่าจะมีทางให้ร่วมมือกันได้บ้าง
แต่พอดูจากสำนวนแล้วเห็นได้ชัดว่า LLM เป็นคนเขียน เลยสงสัยว่าเวลาทำ design note แบบนี้ คุณกลับมาเรียบเรียงใหม่เป็นคำของตัวเองทีหลังเพื่อเช็กไหมว่ามันสะท้อนความคิดของคุณจริง ๆ
เราเริ่มจากการเป็นบริษัท context infra ชื่อ nex.ai มาตั้งนานก่อนที่ Karpathy จะโยนไอเดีย LLM wiki ออกมาเสียอีก ฟีเจอร์เหล่านั้นยังแทบไม่แสดงใน WUPHF แต่ตอนนี้กำลังค่อย ๆ เปิดออกมา
ข้อกังวลหลายอย่างที่เขียนไว้ในบทความเปรียบเทียบ เป็นสิ่งที่เราจัดการมาก่อนแล้วใน context infra ที่สร้างไว้ จึงรู้สึกดีที่ได้เห็นมัน
ถึงอย่างนั้น การลดความซ้ำซ้อนและร่วมมือแบ่งปันสิ่งที่แต่ละฝ่ายเรียนรู้กันก็ยินดีอย่างมาก
คุณบอกว่าอยากให้มีโอกาสร่วมมือกัน ฟังดูเหมือนตอนนี้ยังไม่มีโอกาสแบบนั้นอยู่ เลยรู้สึกแปลกนิดหน่อย
แค่เอา QMD ไปวางบน Obsidian vault ก็น่าจะได้สัก 80% แล้ว และคงใช้เวลาไม่ถึง 2 ชั่วโมงด้วยซ้ำ
เผื่อเอาไว้เป็นบริบท มีลิงก์ต้นฉบับของ Karpathy ด้วย
https://x.com/karpathy/status/2039805659525644595
https://xcancel.com/karpathy/status/2039805659525644595
สงสัยว่า AI Notes จะเพิ่มคุณค่าหรือแค่สร้าง noise เพิ่มขึ้นกันแน่
แต่ก็ชอบ สไตล์ ASCII ของเว็บไซต์พอสมควร
อยากให้มีใครสักคนทำอะไรแนว StackOverflow revival ขึ้นมาเพื่อแก้ปัญหานี้
ให้มนุษย์เป็นคนคัดสรร แต่ถ้า LLM ส่วนรวมแก้ปัญหาแล้วติดขัด ก็ย้อนกลับไปโพสต์คำถามแบบสมัยก่อนใน กราฟความรู้แบบกระจายศูนย์
ถ้าเอเจนต์ของฉันจะพูดว่า "ผมติดตรงนี้และได้โพสต์คำถามไว้ใน SO แล้ว งั้นเดี๋ยวค่อยกลับมาดูอีกทีเมื่อมีคำตอบ" ก็ดูโอเคมาก
สงสัยว่าจะทำอย่างไรไม่ให้ LLM เขียนมากเกินไป
ผมเคยสร้างเครื่องมือและระบบคล้าย ๆ กันมาหลายตัว ทุกตัวลงเอยด้วยการที่ LLM ขยายเอกสารไปเรื่อย ๆ จนทั้งระบบเละ และยิ่งใหญ่ก็ยิ่งใช้งานน้อยลง
การทดลองหนึ่งที่เคยทำคือให้ลิงก์ไม่กี่อันแก่ LLM แล้วให้มันไปค้นหัวข้อที่เกี่ยวข้อง สร้าง knowledge wiki ของตัวเองขึ้นมา พร้อมสรุป ลิงก์ข้ามหน้า และที่มาในแต่ละหน้า
ภายนอกดูเหมือนดี แต่พออ่านข้อมูลจริงแล้วไม่ค่อยดีเท่าไร
มันเป็นการทดลองเมื่อหลายปีก่อน ตอนนี้อาจคุ้มที่จะลองใหม่ด้วยอะไรอย่าง opus 4.7 ก็ได้
ขอตั้งข้อสังเกตว่าในชุมชน TiddlyWiki เองก็สำรวจเครื่องมือ AI กันมาตามธรรมชาติ
TiddlyWiki เป็นวิกิแบบไฟล์ HTML เดี่ยวที่แก้ไขตัวเองได้ และมีมานานกว่า 20 ปีแล้ว
มันอาจไม่ได้พัฒนาไปถึงสภาพแวดล้อมแบบ agentic โดยตรง แต่ก็มี markdown plugin และมีเครื่องมือที่ทำให้ไฟล์รันได้หรือแปลงเป็นเว็บแอปแบบ self-serving ได้ ส่วน Git ค่อนข้างจุกจิกหน่อย
เพราะงั้นในทางทฤษฎี วิกิ agentic แบบไฟล์เดี่ยวที่เดินทางไปไหนมาไหนและแก้ไขตัวเองก็เป็นไปได้
https://tiddlywiki.com/
โครงแบบ single-file ที่คุณพูดถึงมีตัวเชื่อมต่อ LLM อยู่แล้วหลายตัว เช่น https://github.com/rimir-cc/tw-llm-connect
เสน่ห์ของมันก็อยู่ตรงนั้นเลย ไม่มี dependency ไม่ต้องติดตั้ง และเก็บรักษาได้ง่ายมาก ดังนั้นการตั้งค่าวิกิ agentic แบบไฟล์เดี่ยวให้แก้ไขตัวเองได้นั้นทำได้เลยตั้งแต่วันนี้
ส่วนที่ใกล้กับ แพตเทิร์น LLM Wiki ของ Karpathy มากขึ้นคือ twillm ที่ผมกำลังทำอยู่
https://github.com/Jermolene/twillm
มันใช้การตั้งค่า Node.js ของ TiddlyWiki และเก็บ tiddler เป็นไฟล์แยก จึงชี้ไปที่ Markdown vault เดิมได้ตรง ๆ และใช้ร่วมกับเครื่องมืออย่าง Claude Code ได้
ข้อดีของ TiddlyWiki ก็ชัดเจนพอสมควร เป็นโอเพนซอร์สจึงใช้งานได้ต่อเนื่องในระยะยาว และเพราะเป็นเว็บเบสจึงเข้าถึงได้จากทุกที่
อีกอย่างคือ computed view ทำหน้าที่แทน materialized index file ได้ วิธีของ Karpathy ต้องให้ LLM ซิงก์ index.md ตลอดทุกครั้งที่เพิ่มโน้ต ซึ่งเป็นงานที่ stale ได้ง่ายเมื่อข้ามหลายเซสชัน และเป็นสิ่งที่ LLM ทำได้ไม่ดีเป็นพิเศษ
แต่ view ของ TiddlyWiki เป็นนิพจน์ filter แบบเรียลไทม์ ดังนั้นผลลัพธ์อย่างเช่น "เรียง tiddler ที่ติดแท็ก concept ตาม rating" จะถูกคำนวณสดทันทีตอนเรนเดอร์
Frontmatter ก็กลายเป็นโครงสร้างที่ query ได้เช่นกัน Obsidian จะแสดง YAML frontmatter เป็นกล่อง metadata ที่ด้านบนของโน้ต แต่ TiddlyWiki ยกระดับฟิลด์เหล่านั้นให้เป็นฟิลด์ของ tiddler ชั้นหนึ่งที่เอาไปใช้กรอง เรียงลำดับ และรวมสถิติได้ทันที
และ LLM ยังเขียนได้ไม่ใช่แค่เนื้อหา แต่รวมถึง แอปเพล็ต เล็ก ๆ ด้วย นอกจาก Markdown note แล้ว ยังใส่ wikitext tiddler (.tid) เพื่อสร้าง live view แบบโต้ตอบได้ เช่น dashboard, เครื่องมือสำรวจแท็ก, ดัชนี journal หรือ glossary
วงการ self building artefacts น่าสนใจ และตอนนี้กำลังโตมากเพราะ LLM โดยเฉพาะโมเดลสายโค้ด เก่งขึ้นด้านนี้อย่างรวดเร็ว
ช่วงหลังผมเองก็ทดลองโปรเจ็กต์ที่เน้นลด dependency ให้เหลือน้อยที่สุด และควบคุมเอเจนต์บนเครื่องโลคัล
https://github.com/GistNoesis/Shoggoth.db/
มันสร้างและจัดระเบียบ ฐานข้อมูล sqlite ด้วยตัวเองเพื่อทำงานระยะยาวตามพรอมป์ต์ โดยใช้สำเนา Wikipedia ในเครื่องเป็นข้อมูลต้นทาง
ผมยังใส่ฮาร์เนสและเครื่องมือสำหรับทดลอง agent drift ไว้อย่างน้อยที่สุดเท่าที่จำเป็น
การต่อเครื่องมือประมวลผลภาพเข้าไปก็ทำได้ค่อนข้างง่าย แค่เข้ารหัสภาพเป็น base64 แล้วส่งให้ llama.cpp ส่วนรายละเอียดก็ใช้ local LLM ทำ vibecoding คร่าว ๆ เอาได้
ผมมองว่ามันเป็นเครื่องมือที่มีประโยชน์ค่อนข้างกว้าง
ตัวอย่างเช่น เมื่อก่อนผมมีสคริปต์ที่ใช้ Amazon Textract เพื่อดึงยอดเงิน วันที่ และผู้ขายออกจากใบแจ้งหนี้กับใบเสร็จในโฟลเดอร์ แล้วให้คนตรวจเลขอีกทีเพื่อทำ CSV ส่งให้นักบัญชี
ตอนนี้สามารถแทนที่การเรียก Amazon Textract นั้นด้วยการเรียกโมเดล llama.cpp ที่มีพรอมป์ต์เหมาะสมได้ และยังคงใช้เครื่องมือจัดการใบแจ้งหนี้เดิมต่อไป พร้อมเพิ่มความยืดหยุ่นด้านงานบัญชีได้สร้างสรรค์ขึ้นมาก
ผมยังทดลองดัดแปลงมันให้ขยับหุ่นยนต์จริงจากลำดับภาพจากกล้องด้วย ซึ่งในกรณีง่าย ๆ มันก็เคลื่อนที่และไปถึงเป้าหมายได้จริง
แต่ LLM ที่ผมใช้ไม่ได้ถูกฝึกมาสำหรับบังคับหุ่นยนต์ตั้งแต่แรก และใช้เวลา 10 วินาที ในการเลือกแอ็กชันถัดไป จึงยังไม่ใช้งานได้จริง ขณะที่คอนโทรลเลอร์แบบดั้งเดิมที่ไม่ใช่ดีปเลิร์นนิงในปัจจุบันรัน vision loop ที่ 20Hz
โมเดล LLM และเอเจนต์ที่อยู่บนมันไม่ได้เป็นแบบกำหนดตายตัว แต่เป็นเชิงความน่าจะเป็น
มันทำบางอย่างสำเร็จได้ในอัตราหนึ่ง แต่ไม่ใช่ทุกครั้ง
ดังนั้นยิ่งให้งานของเอเจนต์ลากยาวเท่าไร ความน่าจะเป็นที่จะล้มเหลวก็ยิ่งเพิ่มขึ้น เอเจนต์ที่รันยาวแบบนี้สุดท้ายจะล้มเหลว และยังเผาค่า token ไปมหาศาลระหว่างทางด้วย
หนึ่งในสิ่งที่เอเจนต์ LLM ทำได้ดีคือการเขียน คำสั่งของตัวเอง ใหม่
เคล็ดลับคือจำกัดเวลาและจำนวนขั้นการคิดของโมเดลประเภท thinking จากนั้นค่อยประเมิน อัปเดต แล้วรันใหม่
ถ้าเปรียบเทียบง่าย ๆ ก็เหมือนเอเจนต์นั้นล้มได้ อย่าปล่อยให้มันวิ่งนานจนล้ม ความหมายคือ 5 นาทีสองครั้ง ดีกว่า 10 นาทีครั้งเดียว
อีกไม่กี่สัปดาห์ เอเจนต์แบบ self-referential พวกนี้คงขึ้นไปเต็มด้านบนของฟีด Twitter กันหมด
เพราะงั้นวิกิแบบนี้พอถึงสถานะหนึ่งแล้วก็มีแนวโน้มจะหยุดนิ่งอยู่ตรงนั้น