---
# System prepended metadata

title: 口試逐字稿
tags: [口試]

---

# 口試逐字稿

###### 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 的時間變長，效果會變好

