Introversion tendency เพิ่มน้ำหนักเพื่อนกลุ่มเดิมและกิจกรรมกลุ่มย่อยเพียงเล็กน้อย
RESEARCH DATA FOUNDATION · NO MODEL
เริ่มจากข้อมูลที่
เจ้าของควบคุมได้
แบบสอบถามต้นแบบที่ใช้ DuckDB runtime เดิมของ warin.me เก็บเท่าที่จำเป็น แยกความยินยอมเพื่อให้บริการออกจากการวิจัย และเปิดให้ดู แก้ ส่งออก ถอน หรือลบข้อมูลได้
QUESTIONNAIRE
ข้อมูลพื้นฐานและความสนใจ
DATA SUBJECT RIGHTS
ข้อมูลของฉัน
กรอกรหัสทั้งสองค่าที่ได้รับหลังบันทึก ระบบไม่เก็บ access token ไว้ในฐานข้อมูลโดยตรงและไม่สามารถกู้คืนให้ได้
ยังไม่ได้เรียกดูข้อมูล
SIMULATION CONTRACT
สมมุติฐานก่อนสร้างข้อมูล
สมมุติฐานเชิงความน่าจะเป็นสำหรับ synthetic benchmark ไม่ใช่ข้อสรุปเกี่ยวกับนักศึกษา มจธ. จริง ทุกข้อมี noise และทำ ablation ได้
Extroversion tendency เพิ่มโอกาสกิจกรรมข้ามคณะและการพบกลุ่มใหม่
IT/วิศวกรรมอาจสนใจการเงิน ธุรกิจ และการสื่อสาร ส่วนศิลปศาสตร์อาจสำรวจเทคโนโลยี
ปีต้นเน้น exploration และเพื่อน ปีปลายเน้นอาชีพ ตาราง และ workload fit
Project, discussion, lecture และ mixed preference มีผลระดับปานกลาง
วิชาต้องเปิด ตารางไม่ชน มีที่นั่ง และผ่านเงื่อนไขก่อนเกิดการเลือก
แบ่งผู้เรียนเป็น interest-, social-, workload-, popularity- และ exploration-driven
MBTI มีน้ำหนักต่ำกว่าความสนใจ ไม่ตัดสินความสามารถ และต้องทดสอบแบบไม่มี MBTI
SYNTHETIC DATASET
สร้างและสุ่มดูข้อมูลจำลอง
ยังไม่มีข้อมูลจำลอง
| ID | คณะ | ปี | GPA | MBTI | ความสนใจ | Archetype | Same/Cross |
|---|---|---|---|---|---|---|---|
| Generate dataset เพื่อเริ่มต้น | |||||||
EXPLORATORY DATA ANALYSIS
EDA เชิงสถิติ
ADVANCED DIAGNOSTICS
ตรวจความสมจริงและโครงสร้างกลุ่ม
ผลต่อไปนี้เป็น diagnostic ของ synthetic data ไม่ใช่ข้อสรุปเกี่ยวกับนักศึกษา มจธ. จริง
Correlation matrix (Pearson บนตัวแปรต่อเนื่องที่จำลอง)
Hypothesis checks
Intended segment profiles
K selection · 2–8
Silhouette และ Calinski–Harabasz ยิ่งสูงยิ่งดี; Davies–Bouldin และ SSE ยิ่งต่ำยิ่งดี
INTERPRETABLE LATENT MAP
แผนที่พฤติกรรมสองแกน
Baseline ที่ตีความได้ก่อนใช้ clustering: ไม่ใช้ archetype สร้าง segment จุดเล็กคือรายบุคคล จุดใหญ่พร้อมวงแหวนคือค่าเฉลี่ย แกน Y ใช้ latent curiosity เพื่อวินิจฉัย simulation เท่านั้น และจะไม่นำค่านี้เข้าโมเดล recommender
CURRENT BASELINE · PROFILE-BASED
สูตรที่กราฟนี้ใช้อยู่
ขณะนี้ยังไม่มี course catalog หรือประวัติลงทะเบียน จึงคำนวณจากโปรไฟล์จำลอง ไม่ได้คำนวณจากรายวิชา
X = cross_faculty_affinity − same_group_affinityY = 0.65 × (curiosity × 2 − 1)
+ 0.35 × (complementary_interest_ratio × 2 − 1)complementary_interest_ratio = จำนวนความสนใจเสริมนอกฐานคณะ ÷ ความสนใจทั้งหมด 3 อันดับ ค่า X และ Y ถูกจำกัดไว้ในช่วง −1 ถึง 1
SEGMENT RULE
กติกาแบ่งสี่กลุ่ม
| Segment | X เทียบ median | Y เทียบ median |
|---|---|---|
| Focused familiar | ต่ำกว่า | ต่ำกว่า |
| Independent cross-learner | ต่ำกว่า | ตั้งแต่ median ขึ้นไป |
| Social explorer | ตั้งแต่ median ขึ้นไป | ต่ำกว่า |
| Social cross-learner | ตั้งแต่ median ขึ้นไป | ตั้งแต่ median ขึ้นไป |
นี่คือ median-quadrant baseline เพื่ออธิบายง่าย ยังไม่ใช่ผลจาก clustering
NEXT PHASE · COURSE-BASED
เมื่อมีข้อมูลรายวิชา จะคำนวณอย่างไร
กำหนด vector ของแต่ละวิชาจาก syllabus และ rubric เช่น topic 8 หมวด, discussion, project, workload และ cross-faculty exposure โดยแต่ละค่าอยู่ระหว่าง 0–1
view = 0.1 · save = 0.3 · plan = 0.6
enroll = 1.0 · complete = 1.2 · withdraw = −0.5student_course_vector = Σ(course_vector × interaction_weight) ÷ Σ|interaction_weight|Xcourse = weighted mean(cross_faculty_exposure, discussion_intensity)
Ycourse = weighted distance(course_topic_vector, faculty_baseline_vector)ค่า course feature ต้องมาจาก syllabus, learning outcomes, รูปแบบประเมิน และสถิติผู้ลงทะเบียน พร้อม human review ไม่กำหนดค่าเพื่อบังคับให้เกิด segment
DISCOVERED VS INTENDED
K-means เทียบ intended segment
ใช้เฉพาะพิกัด X–Y, k=4 และ Euclidean distance จากนั้นจับคู่ cluster กับ intended segment แบบ one-to-one โดยเลือก mapping ที่มี overlap รวมสูงสุด วงรัศมีแสดงระยะ P90 จาก centroid จึงครอบคลุมสมาชิกประมาณ 90%
PURE SQL RECOMMENDATION
แนะนำรายวิชาแบบตรวจสอบคะแนนได้
รวมเจ็ดวิธีจาก Pure SQL Recommender เพื่อเปรียบเทียบ candidate ranking บนข้อมูลชุดเดียวกัน รายวิชาและชื่อมาจาก GenEd KMUTT ส่วน course feature และ interaction เป็น synthetic teaching evidence ที่ตรวจสอบ SQL ย้อนกลับได้
หรือกรอก Feature เอง · Cold-start profile
ข้อมูลนี้ใช้คำนวณใน request ปัจจุบันและไม่บันทึกลง DuckDB เลือก Content/Hybrid เพื่อใช้ interests อย่างเดียว หรือ Profile kNN เพื่อใช้ observable features ทั้งชุด
STUDENT FEATURE INSPECTOR
กำลังโหลดโปรไฟล์…
ความสนใจที่ใช้กับ Content/Hybrid
Interaction ที่ใช้กับ CF
Feature policy ของแต่ละวิธี
กำลังเตรียมรายการแนะนำ…
ดู SQL ที่ใช้จัดอันดับ
ยังไม่ได้คำนวณ
ไม่ใช้ intended segment, generator latent truth หรือ MBTI เป็นคำตอบโดยตรง ค่า CF ในหน้านี้เรียนจาก synthetic interaction table และต้องประเมินใหม่ด้วย temporal holdout เมื่อเปลี่ยนเป็นข้อมูลจริง
OFFLINE EVALUATION
Train / Test แบบ Temporal Holdout
แบ่งผู้เรียนแบบ deterministic เป็น development 750 คนและ test 250 คน สำหรับ test user แต่ละคนเก็บ interaction ล่าสุดเป็นคำตอบหนึ่งรายการ ส่วน interaction ก่อนหน้ายังคงเป็น context วิธีนี้ป้องกันการนำ future interaction ไปสร้าง recommender
750 development users+250 test users→hold out latest 1→Top-5 rankingกดครั้งเดียวเพื่อประเมิน SQL recommenders และ Biased SVD จาก test set เดียวกัน
ทำไมแต่ละวิธีเร็ว–ช้า · คณิตศาสตร์ของเวลา Recommend
เวลาที่ตารางวัดคือ inference: เริ่มเมื่อต้องสร้างคะแนนรายวิชาให้ผู้ใช้หนึ่งคน จนจัดอันดับ Top-5 เสร็จ ไม่รวมการอ่าน DuckDB, network, การวาดหน้าเว็บ และการเตรียมโมเดลล่วงหน้า จึงใช้เปรียบเทียบแกนคำนวณของ algorithm ไม่ใช่เวลา response ที่ผู้ใช้เห็นทั้ง request
U ผู้ใช้ใน train · I รายวิชา · R interactions · H ประวัติของผู้ใช้ · F course features · K neighbors · f latent factors · E training epochs
sᵢ = (Σrᵢ + mμ) / (nᵢ + m)คะแนนถูกสรุปไว้ระดับรายวิชาแล้ว ตอน recommend เหลือกรองวิชาที่เคยเรียนและ sort เท่านั้น
Inference: O(I log I) · Preparation: O(R)sᵢ = Σ r·2−age/h / Σ2−age/hเหมือน Popularity แต่ให้น้ำหนัก interaction ล่าสุดมากกว่า เมื่อ aggregate ล่วงหน้าแล้วต้นทุน online ต่ำมาก
Inference: O(I log I) · Preparation: O(R)cos(pᵤ,cᵢ) = pᵤ·cᵢ / (‖pᵤ‖‖cᵢ‖)คูณเวกเตอร์ความสนใจกับ feature ของทุกวิชา ไม่ต้องค้นหาผู้ใช้คนอื่น จึงโตตามจำนวนวิชาและ features
Inference: O(I·F + I log I)s(u,j) = Σi∈Hᵤ count(i,j) / support(i)เดินตาม edge จากวิชาที่ผู้ใช้ชอบไปยังวิชาที่มักเกิดร่วมกัน ความเร็วขึ้นกับประวัติและจำนวนเพื่อนบ้านของแต่ละวิชา
Inference: O(H·d + I log I)r̂ᵤⱼ = Σ sim(i,j)rᵤᵢ / Σ|sim(i,j)|เปรียบเทียบวิชาเป้าหมายกับวิชาในประวัติ หากคำนวณ item similarity ล่วงหน้าแล้วจะไม่โตตามจำนวนผู้ใช้
Inference: O(H·I + I log I)r̂ᵤⱼ = μᵤ + Σ sim(u,v)(rᵥⱼ−μᵥ) / Σ|sim(u,v)|ต้องเปรียบเทียบผู้ใช้เป้าหมายกับผู้ใช้ train จำนวนมากก่อนเลือก K คน จึงช้าลงโดยตรงเมื่อ U เพิ่ม
Inference: O(U·H + U log K + K·I)r̂ᵤᵢ = μ + bᵤ + bᵢ + pᵤᵀqᵢหลังเรียน latent vectors แล้ว การ recommend เป็นเพียง dot product ขนาดเล็กกับทุกวิชา แต่การฝึกทำหลายรอบผ่าน ratings
Inference: O(I·f + I log I) · Training: O(E·R·f)s = 0.65·rank(content) + 0.35·rank(popularity)รวมความเร็วของ Content กับ Popularity และเพิ่มการแปลงคะแนนเป็น percentile rank เพื่อให้คนละสเกลรวมกันได้
Inference: O(I·F + I log I)การอ่านค่า: ที่ catalog มีเพียง 18 วิชา เวลาระดับเศษมิลลิวินาทีอาจแกว่งจาก timer และภาระของ container จึงควรดูทั้งแนวโน้มเชิง complexity และทดสอบซ้ำหลายรอบเมื่อทำ benchmark ขนาดใหญ่ ตัวเลขเวลาจาก PHP prototype นี้ยังไม่ควรใช้เทียบกับงานที่ใช้ภาษา เครื่อง หรือ hardware ต่างกัน
Precision@5 · Recall@5 · HitRate@5 · MRR@5 · NDCG@5 · Catalog Coverage@5RMSE แสดงเฉพาะ Popularity, Item-CF, User-CF และ Time-decay เพราะคะแนนอยู่บน rating scale; Content, Co-occurrence และ Hybrid เป็น ranking score คนละสเกลจึงไม่ควรนำ RMSE มาเปรียบเทียบตรง ๆ
ข้อควรระวัง: interaction จำลองถูกสร้างจาก interest–course affinity ชุดเดียวกับที่ Content-based ใช้ จึงทำให้ผล Content และ Hybrid สูงกว่าสถานการณ์จริง ผลชุดนี้ใช้ตรวจ pipeline และ metric เท่านั้น ไม่ใช่ประมาณการประสิทธิภาพเมื่อ deploy
Feature ablation + learning curve
เทียบ kNN Observable, Psychographic และ Oracle โดยเพิ่ม reference users จาก 100 → 250 → 500 → 750 แต่คง test users 250 คนเดิม
ผลจะแสดงพร้อมการประเมินทั้งหมด
DATABASE DESIGN
Entity Relationship Diagram
ใช้ DuckDB CLI ที่มีอยู่แล้วใน warin_web และไฟล์ nextgened.duckdb แยกจากฐานข้อมูลของ Data Systems Lab จึงไม่ต้องสร้างหรือ rebuild container เพิ่ม
PARTICIPANTS
PK idUK public_idaccess_token_hashfaculty · study_yearoptional profile fieldsstatus · timestampsPARTICIPANT_INTERESTS
PK,FK participant_idPK priorityinterest_codeCONSENT_EVENTS
PK idFK participant_idFK notice_idpurpose_code · actionoccurred_atPRIVACY_NOTICES
PK idUK versiontitle · notice_texteffective_at · is_active