眼下分詞效能比較差，僅僅有1.65m/s,同事在沒有改變主要演算法的情況下做了一點優化調整，到3.52m/s。但對效能的提公升仍然不夠明顯。我感覺亟須解決幾個問題:
1.search時keyword分詞也按多種粒度進行，然後分別sloppyphrase,最後or起來,因為大粒度分的詞詞頻低，因此idf大。它們在排序時優先順序更高，符合期望。如今僅僅做乙個粒度的切法，又要求在索引裡面都能找到，感覺不太現實。修改之後的做法對索引時分詞沒有苛求。相對來說新增的開銷也不會非常大，可能就三個粒度的分詞，僅僅是假設排序沒有考慮的話須要更高一些排序的做法。查全率、召回率都會更高。這樣索引分詞就專注在按不同粒度切好詞就可以，不用在切完之後再考慮合併之類複雜奇怪的邏輯，能夠追求更高的效能。
2.統一使用trie樹(或fst)做檢索,trie樹也能夠定時更新，杜絕用hash做字首查詢,trie樹相當於狀態機效能更好。
3.建立效能、準確率、召回率的指標，眼下演算法比較複雜，假設有其它演算法綜合起來更優，能夠替換。
4.眼下increment gap沒有考慮，不夠嚴謹，可能會出錯。
關於創業的想法
想創業，不要總想著做出什麼驚天地的尖端產品，首先要看誰有困難需要你利用技術手段來幫助他克服，然後是利用最低端的技術去解決他們的困難從而保證你的產品質量，盡量讓人家 少付出代價 這樣搞你才有 白手起家 的可能，否則你就去找 賺 第一桶風險金，再努力撐到出產品，再撐到找著客戶，然後拼命留住回頭客再爭到新...
關於封裝的想法
從自己做自己的開發架構以來，逐漸理解封裝的含義和帶來的好處。1 三年來，自己的架構從滿足簡單的查詢列表配置，到現在複雜的列表 詳述 列印以及複雜的編輯頁面的配置，始終堅持框架的無業務性，框架就是提供業務應用的架構。2 封裝的另乙個對自己覺得最大的好處是修改和擴充套件，只需要在該修改和擴充套件的地方修...
關於封裝的想法
從自己做自己的開發架構以來，逐漸理解封裝的含義和帶來的好處。1 三年來，自己的架構從滿足簡單的查詢列表配置，到現在複雜的列表 詳述 列印以及複雜的編輯頁面的配置，始終堅持框架的無業務性，框架就是提供業務應用的架構。2 封裝的另乙個對自己覺得最大的好處是修改和擴充套件，只需要在該修改和擴充套件的地方修...