User Socialization ระดับไหนเหมาะกับ GotoKnow ?

ระบบ text navigation แบบไหน ที่ไม่ต้องเสียเวลา implement นาน ?

ใช้ GotoKnow แล้วรู้สึกว่าลงตัวกับระบบที่ดี

แต่คงต้องมองไปข้างหน้าว่า ทำอย่างไร ระบบที่ดี กลายเป็นระบบที่ดียิ่ง ๆ ขึ้นไปอีก

ประเด็นหนึ่งที่คิดว่าคงสำคัญคือการที่ผู้เขียน blog สามารถหาอ่าน blog จากคนคอเดียวกันได้อย่างเป็นธรรมชาติ

ที่ระดับ blog ไม่กี่หมื่น blog คงยังไม่มีปัญหา ยังพอคุ้ยอ่านได้ทัน และจะเห็นหน้าเห็นตากันได้ หรืออย่างน้อย เห็นชื่อแทนหน้าก็ชื่นใจ (เฮ !)

แต่ในแวดวง IT รู้ ๆ อยู่ว่า กฎการเติบโต เป็นแบบทวีคูณต่อระยะเวลาที่คงที่

ถึงจุดหนึ่ง ที่ blog ขึ้นเป็นหลักแสน ก็เป็นไปได้ว่าจะเห็นกันไม่ทั่วถึง ทั้งที่ความสนใจตรงกันมาก แต่ใช้ tag คนละทิศคนละทาง ซึ่งคงน่าเสียดายมาก

หาไม่เจอ กับ ไม่มีอยู่ในโลก ก็ไม่ต่างกันเท่าไหร่หรอกครับ สำหรับคนอ่าน blog

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

ผมจึงคิดว่า เราคงต้องมองไปข้างหน้าว่าจะนำแนวคิดอะไรมาปรับใช้ในการช่วยควานหาคนคอเดียวกัน

ถ้าใช้วิธี smart text navigation โดยดูจาก document similarity ก็อาจเป็นเรื่องสเกลใหญ่ ต้องรอไป version หน้า เพราะคงเสียเวลาไม่ใช่น้อย ทั้งเขียน และ optimize code ให้ทำงานเร็วสะใจ

แต่ทางออกที่อาจพอเป็นไปได้คือปรับใช้แนวคิดในสเกลที่เล็กกว่า ซึ่งน่าจะดีกว่าการใช้ tag แบบเดิม

วิธีทางเลือกมีมากมหาศาล ผมไม่ขายมะพร้าวให้เจ้าของสวน แต่ผมมีข้อเสนอว่า วิธีหนึ่งที่น่าจะเขียนโปรแกรมง่าย และไม่เป็นภาระระบบนัก คือการใช้ cosine coefficient ของ tag ที่ผ่านการ enriched

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

Cosine coefficient: แนวคิดที่ใช้กันแพร่หลายคือ เจ้าของ blog แต่ละคน จะมี tag ติดตัวเป็นพรวน โดย tag แต่ละคำก็จะมีสถิติอยู่แล้วว่าเคยใช้ไปกี่ครั้ง (frequency) ซึ่งหากมองว่า tag ที่ร้อยเป็นพรวนนี้เป็น vector ที่เหมือนไม้เสียบลูกชิ้นปิ้ง ไม้เสียบนี้มีเนื้อที่เฉพาะของ tag ทั้งหมดของทุกคนใน GotoKnow เช่น คำว่า KM อาจจับจองตำแหน่งหัวสุดของไม้เสียบ ขณะที่ "การจัดการความรู้" ดันไปอยู่กลาง ๆ ไม้

โดยขนาดลูกชิ้น ก็คือถี่ที่ผ่านการปรับสเกลแล้ว ให้ทุกคนมีผลรวมความถี่หลังปรับสเกลเป็น 1 ทั้งหมด

ถ้าเรานำ 2 blog มาเทียบเคียงกัน ก็เหมือนหยิบ vector ทั้งคู่มาวางเคียงกัน ถ้าเป็นเรื่องคล้ายกัน vector ทั้งคู่จะขนานกัน (นั่นคือ ไม้เสียบทั้งคู่ จะดูคล้ายกันมาก) และหาก cosine ของมุมระหว่าง 2 vector เป็น 1 เมื่อใด แสดงว่าคู่นี้ขนานแน่ (นั่นคือ แสดงว่าทั้ง 2 blog มีเนื้อหาเกี่ยวกันมาก) ซึ่งสูตรคำนวณ ก็หาอ่านได้ตามตำราทั่วไป ซึ่งว่าไปแล้ว ก็คือการหาค่า Pearson's coefficient (r) ของ vector 2 ชุดนั่นเอง

ประเด็นคือ ืทำไมต้อง enrich tag เสียก่อน ?

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

การ enrich ก็คือ การใช้ tag ทั้งหมดที่ GotoKnow รู้จัก มาตรวจดูว่า น่าจะใช้เป็น tag ของคนนั้นได้มั้ย (ดูง่าย ๆ คือมีคำนั้นปรากฎใน blog หรือเปล่า) 

เมื่อ union all tags in GotoKnow แล้วก็ใช้วิธีหยิบ tag ทีละตัวมาตรวจในทุก blog ถ้าพบใน blog ไหน แสดงว่าเป็น tag ของ blog นั้นได้ ก็ยัดเยียดให้ซะเลย 

ถ้าไม่สบายใจว่า tag ยัดเยียด ไม่น่าจะดีเท่า tag ที่เจ้าของตั้งเอง ก็ปรับลดน้ำหนักความสำคัญของ tag ลง เช่น จับหาร 2

ผลคือ vector ลูกชิ้นไม้เสียบของเรา จะไม่โหรงเหรงอีกแล้ว จะมีลูกชิ้นของแถมมาเกาะเต็มไม้ ดูน่ากินยิ่งนัก

คราวนี้เมื่อหาความขนานของเวคเตอร์ ก็น่าจะภูมิใจได้ว่า มีระบบ tag ที่รุ่มรวยใช้งานในมาตรฐานเดียวกัน การหาความคล้าย ก็น่าจะดีขึ้น

หลังจากนั้น ระบบอาจรันใหญ่วันละครั้ง สรุปว่า blog ไหนคล้าย blog ไหน เก็บไว้เป็นตารางอ่านสำหรับใช้อ้างอิงได้ภายหลัง

เมื่อใครโหลด blog ใดขึ้นมาก็ตาม ระบบก็สามารถอ่านว่ามี blog ไหน ที่มีความสนใจคล้าย ๆ กันบ้าง

ระบบนี้ น่าจะทำให้การความหาคนคอเดียวกัน เป็นไปได้ง่ายขึ้นกว่าการใช้ tag ตามปรกติ

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

 

[ดร. จันทวรรณ ปิยะวัฒน์]

ขอบคุณอาจารย์วิบุลมากค่ะสำหรับคำแนะนำดีๆ ซึ่งน่าเป็นแนวทางสำหรับ recommendation system ใน KnowledgeVolution เช่น เพื่อการกรอง related posts, related files ได้อย่างมีประสิทธิภาพค่ะ

วันก่อนที่ทีมงานได้ไปคุยกับทาง NECTEC เราคิดจะนำ ฐานข้อมูล LEXiTRON ซึ่งมี synonym ของคำไทยมาใช้ด้วยค่ะ เช่น ติด tag คำว่า กิน ระบบก็จะแนะนำ บันทึก ไฟล์ คำถาม เว็บอ้างอิง บล็อก ฯลฯ ที่ติด tag ว่า รับประทาน หม่ำ มาได้ค่ะ

คงมีเรื่องให้สนุกกันอีกเยอะนะค่ะ ขอบคุณอาจารย์อีกครั้งค่ะ :)

[เมตตา]

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

[wwibul]

อาจารย์จันทวรรณครับ:

ผมคนดู ยังไงก็สนุกอยู่แล้วครับ เพราะเป็นแค่ไทยมุง   ;)

• ระบบ synonym เป็นระบบที่ดีมากสำหรับการค้นผ่าน tag ครับ (tag-to-tag)โดยเฉพาะเมื่อมีการใช้คลังคำมาตรฐานที่คุณเมตตาได้เสนอไว้
• แต่หากตั้ง tag แบบวลียาว ๆ ระบบ synonym อาจไม่ได้ผล เพราะคงไม่มีข้อมูลครอบคลุมกรณีของวลียาว ๆ ไว้เป็นแน่
• ข้อเสนอข้างต้น ใช้เพื่อค้น blog-to-blog โดยไม่ต้องผ่าน tag ครับ ไว้ใช้ข้ามไปหาคนแนวเดียวกันโดยเฉพาะ
• ทั้งสองระบบ น่าจะใช้เสริมพลังกันได้ครับ

[ดร. ธวัชชัย ปิยะวัฒน์]

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

แต่ LEXiTRON ก็ไม่สามารถครอบคลุมวลีได้อย่างที่อาจารย์ได้กล่าว ผมคิดว่าเราจะทดลอง cosine coefficient อย่างที่อาจารย์แนะนำครับ

[นพ. วัลลภ พรเรืองวงศ์]

ขอขอบคุณอาจารย์ wwibul...

• บันทึกนี้ยกประเด็นที่สำคัญมากขึ้นมา... นั่นคือ blog น่าจะมีเอกลักษณ์ (identity)

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

• ถ้าตอบไม่ได้อาจจะเกิดวิกฤตเอกลักษณ์ (identity crisis) ขนาดย่อม(เล็ก) หรือไม่ย่อม(ใหญ่)ได้

ขอเรียนเสนอว่า

• การจัดหมวดหมู่บล็อกตั้งแต่แรก ซึ่งบล็อกแต่ละบล็อกน่าจะเลือกเข้ากลุ่มได้อย่างน้อย 1 กลุ่มตั้งแต่แรก เช่น
  (1). km / การจัดการความรู้
  (2). คุณอำนวย
  (3). คุณกิจ
  (4). คุณเกื้อ
  (5). ชวนชิม(แนะนำอาหาร) เช่น JJ_tracer ของท่านอาจารย์ JJ
  (6). สัตว์เลี้ยง เช่น บล็อกอะไรจำชื่อไม่ได้ (โคโค่...มิ้งค์... โมโม่ ฯลฯ) ของท่านอาจารย์จันทวรรณ
  (7). IT เช่น บล็อกของอาจารย์ wwibul ฯลฯ
  (8). สุขภาพ เช่น บล็อกอัมพฤกษ์-อัมพาตของท่านอาจารย์จันทวรรณ ฯลฯ
  (9). ข่าวคนทำดี เช่น ที่มีป้าย Goodnews
  (10). อีสาน เช่น อีสานศึกษาของอาจารย์ออต
  (11). นำเที่ยว เช่น บล็อกของท่านอาจารย์วิบูลย์ มน. นำเที่ยวมองโกเลีย ฯลฯ

[ดร. จันทวรรณ ปิยะวัฒน์]

ขอบคุณอาจารย์หมอวัลลภค่ะ อีกหน่อยจะมีให้เลือก tag จาก tag list ได้ค่ะ

[wwibul]

• เห็นด้วยกับที่คุณหมอวัลลภว่าไว้ครับ
•  มีวิธีที่ดีว่านี้มากหลายวิธีครับ แต่วิธีที่ว่ามานี้ น่าจะเป็นวิธีที่เขียนโค้ดง่ายสุด และทำงานได้เร็วพอสมควร ซึ่งจะทำให้สามารถปรับย่อยได้โดยไม่ต้องรอยกเครื่อง version ใหม่หมด ถือเป็นวิธีที่น่าจะเล็กจิ๋วที่สุดในตระกูล
•  ที่ผมกล้าเสนอขึ้นมา เพราะเชื่อว่ามันเล็กจิ๋วที่สุดนี่แหละครับ แม้แต่วิธีนี้ ผมก็ยังเกรงว่าจะทำให้ระบบช้าอืด
•  ในระยะยาว ไม่ว่าจะใช้วิธีไหน คงต้องมี server แยกไปอีกตัวเพื่อคำนวณ
•  ทำไมอืด ? เพราะเวลาที่ใช้คำนวณน่าจะจะแปรผันตรงกับจำนวน blog ยกกำลังสอง
•  สำหรับผู้ไม่มีพื้นฐาน ข้อพิสูจน์ ดูจาก Pseudocode ได้ 

  1. List all tags in GotoKnow universe and save in [A]

 2. For each blog, count frequency of all elements in [A] and normalize to such that the sum of all normalized frequency is 1

 3. Pairing blogs and compute cosine coefficient of both blogs (ตรงนี้ชี้ให้เห็นว่าเป็นปัญหาแบบจำนวน blog ยกกำลังสอง)

•  แต่้เนื่องจากจำนวน blog เองก็โตเป็น exponential function ของเวลา เช่น ถ้าอัตราการเติบโตเป็นร้อยละ k ต่อปี ดังนั้น เวลาที่ใช้ในการคำนวณ socialization ก็จะช้าลง (ใช้เวลามากขึ้น) ด้วยอัตราร้อยละ 2k ต่อปี
•  ดังนั้น ไม่ว่าใช้วิธีไหนที่ตรงไปตรงมา จะคาดการได้ว่า ยิ่งนานไป ระบบจะยิ่งช้าลงเรื่อย ๆ แน่นอน เพราะ blog เพิ่มขึ้นเรื่อย ๆ ทุกวัน
•  เนื่องจาก blog ใน GotoKnow โตประมาณปีละ 8.5 เท่า (ผมประมาณจากหมายเลข blog ที่เขียนปีที่แล้วในช่วงเวลาเดียวกันเป็นฐาน และเทียบกับ blog ล่าสุดว่ามีหมายเลขเท่าไหร่)
•  หรือนั่นคือ GotoKnow โต 18 % ต่อเดือน !
• ตัวเลขนี้น่าตกใจ เพราะ GotoKnow โตด้วยอัตราเร็วที่แซงหน้าการค้นพบทาง biology ที่ถือกันว่าโตเร็วที่สุดในโลกเสียอีก (ซึ่งอยู่ที่ 11 % ต่อเดือนโดยประมาณ)
•  การทำ socialization จึงเป็นงานที่โหดมากในการ optimize code เพราะจะเสี่ยงต่อการที่เวลาใช้เพื่อคำนวณแต่ละรอบ จะโตเร็วเป็นสองเท่า (36 % ต่อเดือน)
•  คงต้องหาทุนตั้ง server รอแล้วกระมังครับ ?