เราใช้คุ๊กกี้บนเว็บไซต์ของเรา กรุณาอ่านและยอมรับ นโยบายความเป็นส่วนตัว เพื่อใช้บริการเว็บไซต์ ไม่ยอมรับ
From Cern(เจิ้น) to CernYanisa Sunthornyotin
Day44: ยูนิคอร์นเจอScope Creep
  • 16 กรกฏาคม

    วันนี้ตอนเช้านั่งเตรียมเนื้อหากับพวกผลลัพท์จากการทำโปรเจคไปพรีเซนต์ให้Supervisorฟังตอนบ่ายค่ะ

    เรียกได้ว่าพอหลังจากจบMeetingนี่คือแทบจะเบรกเอี๊ยดดดดดด ตัวโก่งเลยทีเดียว
    คือในแง่ของตัวFlowนั้นไม่มีปัญหาอะไรค่ะ

    จะมีปัญหาก็แต่ตัวUse caseในการใช้Flow data streamingนี้
    คือมิ่งก็ไม่รู้นะคะ ว่า ณ ตอนนี้ที่CERNมีระบบอะไรที่ทำอยู่หรือทำไปแล้วบ้าง ที่ทำได้ก็คือการรับRequirementมาจากทางSupervisorทั้งสามคน

    ในตอนแรกScopeของProjectที่ได้เขียนไว้ในPaperก็คือการสร้างFlowของData streamingที่ช่วยDetect anomaly ของอีเมลค่ะ อีเมลตัวไหนที่เข้ามามากผิดปกติ หรือน้อยผิดปกติ ควรที่จะส่งAlertไปที่อีเมลอีกด้านนึง คล้ายกับการคัดกรอกเพียงแค่อีเมลที่มีความสำคัญค่ะ
    ตอนแรกDataที่Supervisorให้มา เป็นอีเมลค่ะ แต่ต่อมาก็ได้เปลี่ยนเป็นSystem logด้วยเหตุผลบางประการที่ไม่อาจรู้ได้ ซึ่งไม่มีปัญหามากนักที่จะเปลี่ยน \เขียนมาดีค่ะ ถถถ
    ซื่งส่วนนี้มิ่งทำเสร็จไปหมดแล้ว

    แล้วในPaperก็มีอีกส่วนนึงที่กล่าวถึงการนำMLมาใช้ในการCollect user feedback เพื่อนำมาปรับBenchmarkของการAlertให้ขึ้นกับUser preferenceค่ะ ซึ่งในส่วนของตัวuser feedbackนี้ ทางหน่วยงานยังไม่มีระบบที่จะคอยเก็บข้อมูลกลับมา เลยยังไม่สามารถApply MLเข้ากับข้อมูลส่วนนี้ได้ (ตอนแรกว่าจะช่วยทำให้ แต่ดูเหมือนSupervisorอยากจะให้FocusกับตัวFlow datastreamทางนี้มากกว่า)

    และการทำData visualizeอีกเล็กน้อยซึ่งก็ได้ลงมือPlotไปแล้ว อาจจะมีการเปลี่ยนToolsหรือFrameworkภายหลังตามความต้องการของSupervisorและหน่วยงาน

    ก็จะสังเกตุเห็นได้ว่าระหว่างทางนั้นเกิดการเปลี่ยนแปลงขึ้นมากมาย จนเค้าโครงเดิมของPaperที่กำหนดไว้เกิดความเปลี่ยนแปลงไปหลายส่วน จากที่เคยเป็นEmail ณ ตอนนี้ก็ไม่ใช่ข้อมูลของEmailแล้ว แต่เป็นLogของSystemทั้งหมดแทน

    ทีนี้ พอลองนำgraphที่Plotออกมาให้Supervisorดู อ้าว Anomaly มันดูออกง่ายมากเลยนี่นา แค่ใช้ข้อมูลเทียบกับMean อันไหนต่างกันเยอะผิดปกติก็คืออันนั้นมีสิทธิ์เป็นAnomalyสูง ไม่จำเป็นที่จะต้องใช้MLเพื่อDetectส่วนนี้ก็ได้ 

    อีกอย่างมันก็ไม่ได้ต่างจากระบบที่เค้ามีอยู่เดิมทีนี่นา
    เราก็ อ้าว...แล้วให้ทำทำไมนะคะ5555

    มองมุมนึงก็คือ เรามาImplementบนคนละPlatform และบนPlatformนี้เราอาจจะทำอะไรได้มากขึ้นกว่าแค่การPlot graph\ซึ่งก็ถูก สามารถส่งEmailได้ คำนวนเทียบPeakกับAverageได้ Normalizedให้ทุกSystemมีpeak ratioที่คล้ายกันเพื่อกำหนดBenchmarkอันเดียวได้ และสามารถPredict time-series anomaly detectionได้

    แต่ดูเหมือนว่ายังไม่น่าดึงดูดเพียงพอ และยังไม่ต่างจากระบบเดิมของเค้ามากนัก(นี่ยังไม่ต่างอีกเหรอ มิ่งชักสงสัยแล้วว่าระบบเดิมเค้าทำอะไรได้มั้ง5555)

    ทีนี้Supervisorเลยเสนอuse caseที่apply MLเข้ามา (อีกแล้ว555) คือการรับ user requestและparameterต่างๆเข้าไปtrainในMLเพื่อหาAnomalyที่personalizedมากขึ้นค่ะ
    เช่น ต้องสามารถTracebackถึงต้นตอได้ว่าที่เกิดAnomalyนี้ เพราะเหตุใด หรือเพราะใคร(ซึ่งสามารถทำได้ในBI toolsทั่วไป) มิ่งไม่เข้าใจว่า ทำไมต้อง ML ค่ะ ถถถถ

    ดูแล้วมันก็คือการ CountและGroup dataด้วยParameterที่มากขึ้น ไม่จำเป็นที่จะต้องยัดเข้าไปTrainในMLเลยซักนิด แม้แต่การทำPersonalized สมมติว่า เรารู้ว่าUserคนนี้ไม่ยิงrequestตอนกลางคืนแน่ๆเพราะเค้าหลับอยู่ แล้วจู่ๆมีrequestเด้งขึ้นมา แปลว่าผิดปกติ และการหาความผิดปกตินี้ ก็สามารถทำได้ด้วยเลขและเทียบMeanธรรมดา ไม่จำเป็นต้องใช้ML

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

    ดูท่า มิ่งจะต้องไปขอคำอธิบายเพิ่มเติมจากsupervisorอีกครั้ง เผื่อว่าจะเข้าใจอะไรผิดไป(ซึ่งก็ขอให้ใช่)

    ที่แน่ๆตอนนี้ รู้เพียงว่า Scope project มิ่งก็ได้หลุดขอบโลกไปไกลแล้วค่าาาา

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

    ยิ้มกริ่มระคนอยากปิดโปรเจคไวๆแต่ดันเจอScope creepและการShift directionหักศอก

    ก็ได้แต่ทำใจในเรื่องนี้แล้วก้มหน้าทำงานต่อไปค่ะ










เข้าสู่ระบบเพื่อแสดงความคิดเห็น

Log in