# 口試逐字稿 ###### tags: `口試` ## 楊沛霖 (苡丞紀錄) 潘: QRcode的內容只有email? A: 他適用QRcode來做使用者區別 潘: 大問題，蒐集資料只能用電腦，看可不可以用app，抓手機上的資訊，因為大部分的人聽歌都是用手機 潘: 推薦系統驗證是否是使用者真的喜歡 蔡: 會不會推薦歌曲都只有那首 A: 使用者加入後會有所變化， 蘇A: 他目前只有在做殼，推薦系統是由下一件，他目前是將蒐集資料跟播放裝置實作 潘: 可以考慮box的運作環境，如:pub，餐廳等 蘇A: 目前題目不是強調推薦，而是實做 潘: 所以這算是一個framework? A: 對 蔡: youtube有一些推建，為何不直接用推薦結果 蔡: 有沒有發現youtube推薦有甚麼問題，所以才發展出這個研究，為何不直接用youtube的堆荐就好 蘇A: youtube沒有針對group的推薦，只有針對個人的做推薦 蔡: youtube有出youtube music，為何不利用那個，可以利用那個來做分別 A: 可以試著用那個來做音樂的分別 蔡: 圖表很多，但結論沒有利用那些結果做出一個統整，應該在裡面做出一些統整，想想之後發展甚麼該做甚麼不該做 解: 因為他是個產品，第一，用MUTUBE的用意，跟直接給使用者一個板子的差別 A: 沒辦法和youtube一樣直覺，安裝擴充套件就可以直接蒐集 解: 為何要做MUBOX，因為可以用那個跟商場之類的喇發來配對比較方便? 解: 如果沒有用QRCODE，是直接用Popularity，還是有考慮其他在場的使用者 解: 在設計系統上，需要考慮不同場合，可能他在pub就是想聽一些嗨歌 解: related work的貢獻是系統還是演算法 解: 以後街的學弟妹可能要更多的注重演算法 解: 我覺得還是要設計一些使用者回饋，讓使用者做背書，雖然電資學院可能不常用 解: 我喜歡你的統計，但還是希望等資料蒐集多一點再看看資料的趨勢 李: 你最困難的部分，還有程式的行數，有一萬行嗎 李: 實作做了很多貢獻，找工作很方便，但對老師比較不有理，沒辦法發論文 李: 你的decision making要寫清楚一點，很多演算法也要寫清楚一點，如咖啡廳選人之類的問題，並沒有寫清楚 李: 你的weight有沒有bias的問題，如果有特定的user要攻擊你的系統，像選很多奇怪的歌 李: 有沒有資安問題，有沒有侵犯隱私 A: 我們有再下載說明的時候有寫好安裝會蒐集的內容 ## 楊沛霖 (仕翰紀錄) 潘 : 你的 qrcode 的內容只有email? 楊 : 他是利用 email 去做每一個使用者不一樣 潘 : 有一個比較大的問題是只能在電腦上用，有一個建議是去抓使用者手機上的 app 向台北大家坐捷運都是用手機看youtube 潘 : 另外一個問題是要怎麼驗證你的推薦是使用者喜歡的 楊 : 這邊我是用使用者收聽次數最多的 蔡 : 那你最後面是不是都會是那幾首 楊 : 目前我們是選比較多首歌再用 random 的方式選幾首 蘇 : 我補充一下他只是先做一個架構，推薦是下一屆會繼續做 潘 : 如果你要繼續做，地點也可以做為考量 (pub etc.)，但目前看起來是沒有推薦 蘇 : 他比較偏實作，論文沒有著重在推薦 潘 : 所以這算是一個 framework 蔡 : 我有點好奇 YT也有一些推薦的功能，妳怎麼不直接用結果 我想要除了他的結果再給使用者不一樣的結果 蔡 : 我覺得你要有更強烈的動機，例如現有的推薦系統有什麼樣的問題，但是你們有這樣的 motivation 嗎 蘇 : YT 是 for 一個 user 但我們的系統是針對 Group，這個 YT 應該是沒有辦法做到，針對在場有哪些人 蔡 : YT 不是有推出 TY Music 那你要不要考慮直接用這個，他可能功能還沒有那麼完整，但還是可以試試看 蔡 : 結論沒有基於前面的分析，有點可惜，那麼多圖表有點浪費，可以找出一些給學弟妹的建議 解:第一個我有點好奇，你用 YT的用意跟我給使用者一個 ipad 寫好一個程式給他使用的差異在哪裡 楊 : 我覺得協議個程式沒有辦法像YT那麼直覺 解 : 啊我可能講錯了，我是說 MuTube，為甚麼不用 ipad 就好 楊 : 這個部分我們是覺得比較方便跟喇叭之類的配合 解 : 我還是不太知道你們的使用情境，假設是一個公共場合，那前面那些 dominant 可以使用的地方在哪裡 解 : 還有一個議題要提醒一下，我去 pub 就是想聽很 high 的音樂，而不是在家裡常聽的歌 解 : 另外我想要請問你提的 related 也是 framework 還是演算法 解 : 你現在提出的是一個平台，但我覺得要找一些使用者回饋，讓他們幫你背書，哪裡好用哪裡可以再改進，比較可以說服人家 解 : 會建議 Data 多一點相信 distribution 會不一樣 李 : 我想一下你現在做這些東西困難的點在哪裡，code 會很多嗎 李 : decision making 要更清楚一點，另外你有很多圖再討論切割，可是我不知道演算法是什麼，我不知道這些東西是怎麼做的 楊 : 這些東西是使用者在YT上面聽的資料 李 : 你會不會有 bias 的問題，有使用者故意要擾亂你的系統，你有沒有考慮過這些的影響，最後就是資安的問題，有沒有侵犯隱私的問題 楊 : 刻意要破壞的部分這部分是沒有處理 楊 : 資安主要就是蒐集使用者 YT 的資料，這邊我都有先寫出來 ## 吳汶峻（芯瑋紀錄） 蔡：beacon 少，效果也會越好嗎？ 吳：free walk 的情況下，2 beacon 效果是差不多的 蘇：之前有討論過一個狀況，2 beacon 代表實驗室沒辦法佈很多beacon，如果兩支手機定位效果不差，再整合將資訊起來。 忠憲：現在基本上是做很多實作，這部分方長肯定。現在發 beacon 是用樹梅派做的，和一般 wifi 訊號還是有差距，有和其他室內定位作品做比較嗎？ 忠憲：這樣做訊號會比較穩定，但會不會假設太強烈，因為塑造一個對演算法有利的環境來做實作。 忠憲：現在兩支手機比一支手機有好處，但有沒有壞處？不然三支四支不是更好嗎？是不是有些條件需要列出。 圖做的很多但需要解釋，真的做那麼多圖都要放進去嗎？放太多圖資訊卻不多，不是一件好事情。 李：在說明一下選擇 KNN 和 particular filter 這個組合的原因，同類型的演算法很多，為什麼選擇這兩個？是不是之前學長姊大多用這兩個演算法？ 李：放很多圖，但資訊量沒有很多，報告方向是看要報什麼，再選三到五張圖放進去。前面有滿多圖都是重複的，但適當的 CDF 可以留。 李：loosly 是兩個 reference position 應該要比較好，因為參考點比較多，但為什麼在實驗中看不到這個結果，可以思考一下。在結論沒有一個 dominate 的方法有點怪，應該要有一個趨勢。 李：（P25）做完 iteration 的結果後可以調整格子的大小，才可以越來越準。 淑茵：stationary 的定位應該要非常精準才對。 李：loosly 和 tightly 都沒有發揮它們應該要有的效果。 李：為什麼不用兩支手機和一隻 device 會比較真實？ 蔡：(P25)這些區塊建議名字要再清楚一點，prediction 和 location 有什麼不一樣？ 蔡：（P34）1.7m 是什麼地方要標，不然以為實驗室的人身高都 170。 蔡：（P36）這裡的線上面的字有點怪怪的，出來兩個人名的 loss rate 是多少？同樣兩支手機為什麼可以變成兩個人？可以在去想怎麼表達。 蔡：每張圖都要得到一個結論，這個系統可以怎麼運作？可以放在什麼地方用？要怎麼用？論文是萃取過有意義的東西才會放在論文上。 蔡：lossly 和 tightly 本質上非常像，只有 90000 多筆資訊還看不出來差異，應該用幾個有明顯差異的方法來比較。 losssly 和 tightly 選一個，再和沒有 particular filter的方法做比較，畫在圖上做比較。 潘：related work 沒有再多看點論文，室內定位的論文其實很多，或是報告沒有把特色報告出來。 潘：現在是用兩隻手機，情境需要再討論，兩個 user 要投稿會被說使用者數量不多，可能要 10 個 user 混合去定位來看效果。 手機擺在 sensor 的位子有沒有差異？也有可能被 challange 說手機擺放方式（口袋裡、包包裡）對訊號有有影響，如果有影響要如何解決？ 潘：error 的量測要交代清楚，看不出來是怎麼量的，要把量測方法交代清楚 潘：如果之後要投稿，還是要解釋自己和別人的差異在哪裡。數據要再好好整理，整理好才能走。 ## 吳汶峻(廷瑋紀錄) 李忠憲 : Related work盡量不要IEEE Access，名聲不好 李忠憲 : beacon數量對Error的影響大家都知道，不用講 蔡 : 在2 beacon跟3 beacon的趨勢好像都一樣，如果沒有不一樣的地方可以帶過 李 : 是不是beacon數越少tightly couple會比較好 ? A : beacon 少的話會需要整合多支手機的資訊一起做定位 蘇 : 沒有得出beacon數與T/L關係的結論，可能要補。 李忠憲 : 我肯定你做了很多事情，beacon是用樹梅派做的，跟實際還是有點距離，有沒有跟其他方法做比較？ A : 有跟單支手機做比較 李忠憲 : 現在的實驗環境是不是對你的演算法比較有利？ 李忠憲 : 兩支手機目前只有好處，有沒有壞處？是不是裝置越多越好，有沒有條件？ 李忠憲 : 論文的圖非常多，需要更深入的探討，大部分結論都蠻直觀的，可以討論一下不要每張都放。 李 : 你選擇KNN & PF的原因？ A : 要分配2支手機的比重所以選KNN 李 : 同類型的演算法很多，為何要選這2種方法？如果寫論文的話要講清楚選這個方法的理由。 李 : 放很多圖，但資訊少，不要全部實驗結果都丟進去，整理一下結果，有很多圖都蠻像的 李 : 我覺得loosely應該會比較好，為甚麼在你的實驗看不到這結果，T是L的簡化版本，應該不會比較好，看看是有什麼問題？ 李 : PF的weight可以不要用uniform，可以用其他方法讓他越來越準 蘇 : 訝異靜止的情況沒有很精準 李 : 演算法沒有設計得很好，沒有發揮它們的極限 李 : 為甚麼不是手機+其他裝置讓情境更加真實，不是related work有multi device的情形嗎 A : 那是同一支手機多個sensor的情形，用雙手機是因為code比較好寫 蔡 : p.34 1.7m是指甚麼 A : 離地面高度 蔡 : p.36 移動頻率那部分容易混淆，可以再清楚一點，底下2組手機怎麼會變成2個人 論文應該要放萃取過有意義的圖 T/L的結果非常接近，9萬多筆資料無法看出優劣，T/L方法也類似 應該使用幾個差異明顯的情況來比較，例如沒有PF的情況，要讓差異大一點 潘 : 多看一點論文，報告沒有清楚，看不到特點 User只有2個，會被挑戰使用者不夠多 做實驗時使用者手機位置對訊號的影響沒有去探討，沒有考慮使用者拿手機的各種情形。 Error量測方法要交代清楚 要考慮跟別人的差異在哪裡，而且不能只是一篇，數據要在好好地整理一下 蘇 : 實驗做很多，抓不到那個點。 潘 : 要把點講出來 蘇 : 花了很多時間在KNN上，PF沒有發揮他的長處，因為PF會長期紀錄，所以應該會越來越準 靜止的情況沒有很精準，往前走的情形也很好猜 ## 蔡榮漾 (仕翰紀錄) 潘 : 看一下38頁，你這個a值是固定的嗎?那你怎麼去訂他的值 蘇 : 我補充一下他是一個 range 不是一個固定的值，但range 是固定的 潘 : 為甚麼要固定? complexity 多高?這個是不是有更好的演算法可以套用? 我印象中我大學有修過，我覺得你可以找一個既有的演算法去套用，訊號處理的 correlation etc. 文 : 我覺得要看訊號特性，其實兩個方法都可以 蘇 : 可以試試看一開始 range 大一點，之後根據前面的結果微調就好 李 : 28 頁有三個 sniffer 這些 sniffer 有協同工作嗎? 潘 : 我有想到一個你可以降低複雜度，有一些 group 的距離很近可以算重心，再跟其他 group 計算是不是 follower，可以算得很快，這樣論文也是滿有趣的 蔡 : 首先你的題目 proximity ... 但是你的內容是分析其他三種，我會建議這個字投稿的時候可以改一下，然後你的投影片從第二頁開始，建議你們印給口委跟報告的是兩個版本，再來我還是要譴責一下你們這樣太浪費紙了 (ex p16)，這種單一行的完全沒有幫助，主題式的也不要放 (比例太高盡量避免)，別人審你的論文會印彩色的，所以要讓你的圖黑白也可以看出來，46頁像你這個演算法我看半天看不懂，i沒有變很奇怪，顯然有問題，再來 48 頁我不懂你的 social relationship 你的 friend 是怎麼訂的，因為我直接看會以為 near 就是 firend，再來你的 companion 要怎麼 define 漾 : ....... 蔡 : 我沒有看到 definition，再來你的 delta kl，我會建議不要用這個字，我會建議用比較簡單的字，k跟l我看不出來是甚麼，然後我不知道 CDF 要幹嘛，我覺得很直覺，這個觀察有甚麼結論? 漾 : ....... 蔡 : 這個圖你說可以區分我覺得怪怪的 蘇 : 我覺得蔡老師看不懂是因為這邊不是結果，比較像你過程分析的東西，你可能將結果的時候應該要用 confusion matrix，這邊比較像你收 data 的結果 蔡 : Delta 有定義數學式嗎? 漾 : 沒有放上來 蘇 : 我不是有給你嗎！！！ 漾 : 那個好像不一樣 蔡 : 你後面 71 頁後面我跟不上，這些光碟片我看不懂是甚麼 漾 : ...... 蘇 : 我是覺得這邊應該要改成 table 會比較明確一點，我是把他看成甜甜圈 (大笑) 潘 : 用 table 也會太多，你要想一下甚麼表述比較好 蔡 : 80 頁，前面沒有說突然跑出來我看不懂是甚麼，我覺得應該要放在 future works 比較好 (蘇老師表示同意)，要顧慮有沒有資安問題 潘 : 你需要安裝 app 嗎? 漾 : 不用，wifi, bluetooth 訊號就可以了 李 : 講到 app 我先問，台灣有一個社交距離 app，我覺得最重要的問題就是資安的問題，我覺得你的 related 一定要提到這樣的問題，wifi 太遠會侵犯別人的隱私，所以用 bluetooth，而且要用 hash 不能有個人資訊，而且要是自願的，資料要在手機上，兩支手機遇到才會交換，資料不能放在 central office，14天後要刪掉，你要做這個就要去看別人的work 研究看看，講到 human 的東西隱私很重要，我是覺得至少要討論一下 文 : 我覺得你可以討論一下怎麼樣算 companion，另外因為你是 supervised learning ，training 時間, complex 等等都要討論 文 : 是不是給原始 data 會更準，我覺得 trade-off 可以討論一下，我會想到放兩個 f 跟一個 c 反而模糊掉你的相關性，可能 train 的時間變長，效果會變好