協同過濾演算法java

1. 協同過濾演算法

用戶行為數據在網站上最簡單的存在形式就是日誌，比如用戶在電子商務網站中的網頁瀏覽、購買、點擊、評分和評論等活動。 用戶行為在個性化推薦系統中一般分兩種——顯性反饋行為(explicit feedback)和隱性反饋 行為(implicit feedback)。顯性反饋行為包括用戶明確表示對物品喜好的行為。網站中收集顯性反饋的主要方式就是評分和喜歡/不喜歡。隱性反饋行為指的是那些不能明確反應用戶喜好 的行為。最具代表性的隱性反饋行為就是頁面瀏覽行為。 按照反饋的明確性分，用戶行為數據可以分為顯性反饋和隱性反饋，但按照反饋的方向分， 又可以分為正反饋和負反饋。正反饋指用戶的行為傾向於指用戶喜歡該物品，而負反饋指用戶的 行為傾向於指用戶不喜歡該物品。在顯性反饋中，很容易區分一個用戶行為是正反饋還是負反饋， 而在隱性反饋行為中，就相對比較難以確定。

在利用用戶行為數據設計推薦演算法之前，研究人員首先需要對用戶行為數據進行分析，了解 數據中蘊含的一般規律，這樣才能對演算法的設計起到指導作用。

(1) 用戶活躍度和物品流行度

(2) 用戶活躍度和物品流行度的關系

一般認為，新用戶傾向於瀏覽熱門的物品，因為他 們對網站還不熟悉，只能點擊首頁的熱門物品，而老用戶會逐漸開始瀏覽冷門的物品。如果用橫坐標表示用戶活躍度，縱坐標表示具有某個活躍度的所有用戶評過分的物品的平均流行度。圖中曲線呈明顯下 降的趨勢，這表明用戶越活躍，越傾向於瀏覽冷門的物品。

僅僅基於用戶行為數據設計的推薦演算法一般稱為協同過濾演算法。學術界對協同過濾演算法進行了深入研究，提出了很多方法，比如基於鄰域的方法(neighborhood-based)、隱語義模型 (latent factor model)、基於圖的隨機遊走演算法(random walk on graph)等。在這些方法中， 最著名的、在業界得到最廣泛應用的演算法是基於鄰域的方法，而基於鄰域的方法主要包含下面兩種演算法。

基於用戶的協同過濾演算法 ：這種演算法給用戶推薦和他興趣相似的其他用戶喜歡的物品

基於物品的協同過濾演算法： 這種演算法給用戶推薦和他之前喜歡的物品相似的物品

基於鄰域的演算法是推薦系統中最基本的演算法，該演算法不僅在學術界得到了深入研究，而且在 業界得到了廣泛應用。基於鄰域的演算法分為兩大類，一類是基於用戶的協同過濾演算法，另一類是 基於物品的協同過濾演算法。現在我們所說的協同過濾，基本上就就是指基於用戶或者是基於物品的協同過濾演算法，因此，我們可以說基於鄰域的演算法即是我們常說的協同過濾演算法

(1) 基於用戶的協同過濾演算法（UserCF）

基於用戶的協同過濾演算法的基本思想是：在一個在線個性化推薦系統中，當一個用戶A需要個性化推薦 時，可以先找到和他有相似興趣的其他用戶，然後把那些用戶喜歡的、而用戶A沒有聽說過的物品推薦給A。

Ø 從上面的描述中可以看到，基於用戶的協同過濾演算法主要包括兩個步驟。 第一步：找到和目標用戶興趣相似的用戶集合。 第二步： 找到這個集合中的用戶喜歡的，且目標用戶沒有聽說過的物品推薦給目標用戶。

這里，步驟1的關鍵是計算兩個用戶的興趣相似度，協同過濾演算法主要利用行為的相似度計算興趣的相似度。給定用戶u和用戶v，令N(u)表示用戶u曾經有過正反饋的物品集合，令N(v) 為用戶v曾經有過正反饋的物品集合。那麼我們可以通過以下方法計算用戶的相似度：

基於餘弦相似度

(2) 基於物品的協同過濾演算法（itemCF）
與UserCF同理
(3) UserCF和itemCF的比 較

首先我們提出一個問題，為什麼新聞網站一般使用UserCF，而圖書、電商網站一般使用ItemCF呢？ 首先回顧一下UserCF演算法和ItemCF演算法的推薦原理。UserCF給用戶推薦那些和他有共同興 趣愛好的用戶喜歡的物品，而ItemCF給用戶推薦那些和他之前喜歡的物品類似的物品。從這個算 法的原理可以看到，UserCF的推薦結果著重於反映和用戶興趣相似的小群體的熱點，而ItemCF 的推薦結果著重於維系用戶的歷史興趣。換句話說，UserCF的推薦更社會化，反映了用戶所在的小型興趣群體中物品的熱門程度，而ItemCF的推薦更加個性化，反映了用戶自己的興趣傳承。 在新聞網站中，用戶的興趣不是特別細化，絕大多數用戶都喜歡看熱門的新聞。個性化新聞推薦更加強調抓住 新聞熱點，熱門程度和時效性是個性化新聞推薦的重點，而個性化相對於這兩點略顯次要。因 此，UserCF可以給用戶推薦和他有相似愛好的一群其他用戶今天都在看的新聞，這樣在抓住熱 點和時效性的同時，保證了一定程度的個性化。同時，在新聞網站中，物品的更新速度遠遠快於新用戶的加入速度，而且 對於新用戶，完全可以給他推薦最熱門的新聞，因此UserCF顯然是利大於弊。

但是，在圖書、電子商務和電影網站，比如亞馬遜、豆瓣、Netflix中，ItemCF則能極大地發 揮優勢。首先，在這些網站中，用戶的興趣是比較固定和持久的。一個技術人員可能都是在購買 技術方面的書，而且他們對書的熱門程度並不是那麼敏感，事實上越是資深的技術人員，他們看 的書就越可能不熱門。此外，這些系統中的用戶大都不太需要流行度來輔助他們判斷一個物品的 好壞，而是可以通過自己熟悉領域的知識自己判斷物品的質量。因此，這些網站中個性化推薦的 任務是幫助用戶發現和他研究領域相關的物品。因此，ItemCF演算法成為了這些網站的首選演算法。 此外，這些網站的物品更新速度不會特別快，一天一次更新物品相似度矩陣對它們來說不會造成 太大的損失，是可以接受的。同時，從技術上考慮，UserCF需要維護一個用戶相似度的矩陣，而ItemCF需要維護一個物品 相似度矩陣。從存儲的角度說，如果用戶很多，那麼維護用戶興趣相似度矩陣需要很大的空間， 同理，如果物品很多，那麼維護物品相似度矩陣代價較大

下表是對二者的一個全面的表較：

2. 我想用協同過濾的演算法寫了一個java語言的圖書推薦系統.能跟我講一下大概要怎麼做嗎.有點沒頭緒

針對完全沒有編程經驗的初學者，java入門沒什麼特別好的書，找點視頻看看吧，跟著視頻敲代碼，慢慢就能看懂書了。

----------------------如果堅持要看書的話可以考慮以下----------------------
1. head first java
通俗易懂，重點突出的書，比較薄，適合初學者快速入門，缺點是編輯自以為幽默的加了很多不相乾的段子在裡面，廢話太多。

2. Java A beginner's guide by Herbert Schildt
相比head first java，沒有廢話，語言精煉。

3. 官方的tutorial
免費的，在線閱讀的，也不錯。

4. 瘋狂java講義
如果英文不夠好的話，可以考慮用這本書入門，中文世界裡寫的比較好的

5. Introction to java programming by Y. Daniel Liang
梁勇這本書比較厚，講演算法比較多，如果你時間充足的話可以用這本書入門。

----------------------！！一定要避開這兩個大坑！！----------------------
很多人推薦的core java 和 Thinking in java 其實並不適合初學者(沒有編程經驗的)。
1. core java內容太多太雜，沒有突出重點，並且結構組織的像本字典，適合入門了以後用來系統復習。
2. Thinking in java 沒有編程經驗根本看不懂，過幾年再看吧，不看也沒關系。

3. 關於java新聞網站的演算法

（一）演算法倫理的研究

1.演算法內涵界定。演算法源於數學，但現代演算法又遠遠不止於傳統數學的計算范疇。演算法多被理解為是計算機用於解決問題的程序或步驟，是現代人工智慧系統的運行支柱。《計算主義：一種新的世界觀》(李建會等，2012)中將演算法定義為能行的方法，在外界的常識性理解中所謂演算法就是能感受到的一套運算規則，這個規則的特點在於運算時間的有限性、計算步驟的有窮性、輸入結果的確切性,它是機械步驟或能行可算計程序。該定義點明了演算法應具備的兩個基本屬性—或侍李—有限性與有窮性。《用計算的觀點看世界》(酈全民，2016)則從信息傳播的角度解讀演算法，認為演算法實質上是信息處理方法。

2.演算法倫理研究

倫理關乎道德價值真理及其判斷。存在於自然界、社會中的人，其行為應遵循一定的倫理道德規范。倫理的效應要導向善。倫理道德關注對個體存在的尊重、個體的自由、公平正義以及組織團體的延續與發展等問題。在一定程度上可以說，當今的人類社會已經不能脫離智能演算法系統而運行了。

演算法無時無處不在對世界產生影響，因而演算法也會必然的觸碰到倫理道德。和鴻鵬（2017）已指出，演算法系統在人類社會生活中的廣泛應用，會陷入諸多如人類面臨且無法迴避的倫理兩難選擇困境之中。而當演算法與倫理發生關聯時，學界一般認為會引出職業倫理和技術倫理兩種倫理問題。

職業倫理主要與演算法系統的開發者有關，指開發者是帶有個性價值觀、倫理道德觀去研發演算法系統的行為體，因而演算法系統一開始便會摻雜著設計人主觀性的倫理道德觀。設計者出於何種目的開發某演算法系統、面對不同問題設計者持有的倫理道德態度，這些衫遲都會在演算法系統的運行中得到體現。

技術倫理是演算法系統在一定意義上可稱之為一種科學技術，這種技術自身及其運作結果都會負載著倫理價值。其實在一些情況下，職業倫理與技術倫理之間並沒有很明確的界別，關於這一點，劉則淵跟王國豫已做過論述。

本文將主要從技術倫理的角度對演算法關涉倫理這一問題嘗試做深入研究。

（二）網路新聞傳播的演算法倫理研究

演算法與技術的融合不斷英語於網路新聞傳播領域中，從數據新聞到機器寫作，從演算法推送到輿情到分析，國內新聞傳媒領域的機器新聞和相關研究逐漸發展，金兼斌在《機器新聞寫作:一場正在發生的革命》(2014)，作者較早的將眼光聚焦於基於演算法的新聞內容生產和編輯。認為在自動化新聞生產大發展的前提下，諸如新聞生產或分發中勞動密集型的基礎性工作與環節都將被技術取代。張超、鍾新在《從比特到人工智慧:數字新聞生產的演算法轉向》(2017)認為演算法正在從比特形式走向人工智慧階段，這種轉向使得數字新聞與傳統新聞的邊界進一步明晰，促使數字新聞生產也產生了變革。胡萬鵬在《智能演算法推薦的倫理風險及防範策略》中總結了從演算法推送方面：針對新聞的價值觀所受到的負面影響；以及新聞的公共性、客觀性和真實性受到的削弱進行分析；從受眾方面：將具體對信息繭房現象以及受眾的知情權和被遺忘權展開探討；從社會影響方面,則針對社會群體、社會公共領域和社會文化所受到的消極影響展開論述。

根據以上文獻的梳理可以看出，國內目前對網路新聞傳播的演算法倫理研究主要集中在新聞業態演算法倫理失范的相關問題，因為與其他失范問題相比，這是比較容易發現的。但目前關於網路新聞傳播的演算法倫理的國內研究還存在不足：國內算談棚法倫理和網路新聞傳播演算法倫理的研究還是在起步階段，比較成熟的系統性研究還未出現；關於演算法開發人員和平台的責任機制的研究都比較薄弱，總上所述，演算法推送新聞的倫理問題研究是有必要繼續加強的。

2.新聞推薦演算法的興起、發展與原理

2.1新聞推薦演算法的興起

隨著計算機技術的信息處理的維度越來越高，信息處理的能力不斷提升，演算法技術可以從大數據中篩選出用戶最關心最感興趣的信息，改變了原有的新聞信息傳播方式，重塑了新的媒介生態和傳播格局。

但反過來看，在人人都能生產信息的背景下，信息的生產、傳播和反饋的速度都是呈幾何倍數增長，用戶面對的信息越來越多。由於設備的局限性和信息海量，用戶無法集中注意力看自己感興趣的內容，也無法及時抓取對自己有用的信息，於是出現了「注意力經濟」。美國經濟學家邁克爾·戈德海伯（1997）認為，當今社會是一個信息極大豐富甚至泛濫的社會，而互聯網的出現，加快了這一進程，信息非但不是稀缺資源，相反是過剩的。相對於過剩的信息，只有一種資源是稀缺的，那就是人們的注意力。換句話說，信息不能夠一味追求量，還要有價值，價值就在於用戶對信息的注意力，誰獲得了用戶的注意力就可以有市場的發展空間，通過「販賣」用戶的注意力能夠使新媒體聚合平台獲得利潤，維持發展。再加上現在生活節奏越來越快，人們對信息獲取的量和效率要求提高，不想把時間浪費在自己不感興趣的信息，從而用戶獲取信息的「個性化」特徵變得明顯起來。

基於此背景下，演算法推送新聞的傳播機制應運而生，用戶不需要特意搜索自己需要的信息，而是海量的信息會自行「找到」用戶，為用戶節省搜索時間之餘，又能做到真正為用戶提供有用的信息。

2.2新聞推薦演算法的發展現狀

演算法推薦是依據用戶數據為用戶推薦特定領域的信息，根據受眾使用反饋不斷修正並完善推薦方案。目前主要有兩類新聞機構使用演算法推送，其一是新型的互聯網新聞聚合類平台，國內主要是以今日頭條和一點資訊等演算法類平台為代表，在我國新聞客戶端市場上擁有極高的佔有率。張一鳴創建今日頭條是依靠大數據和演算法為用戶推薦信息，提供連接人與信息的服務，演算法會以關鍵詞等元素判斷用戶的興趣愛好，從全網抓取內容實現個性化推薦。國外則是以Facebook、Instagram等平台為代表，這些APP都是通過演算法挖掘用戶的數據，以用戶個性化需求為導向對用戶進行新聞推送。另一種則是專業新聞生產的傳統媒體，為積極應對新聞市場的競爭和提高技術水平而轉型到新聞全媒體平台，如國內的「人民日報」等，國外利用演算法推送向用戶推送新聞的傳統媒體則有美國的美聯社、華盛頓郵報和英國的BBC等,他們利用演算法監督受眾的數量還有閱讀行為，使他們的新聞報道能夠更加受受眾的喜歡，增加用戶的粘性。

2.2新聞推薦演算法的原理

2.2.1新聞推薦演算法的基本要素

演算法推送有三個基本要素，分別是用戶、內容和演算法。用戶是演算法推送系統的服務對象，對用戶的理解和認知越是透徹，內容分法的准確性和有效性就越准確。內容是演算法推送系統的基本生產資料，對多種形式內通的分析、組織、儲存和分發都需要科學的手段與方法。演算法是演算法推送技術上的支持，也是最核心的。系統中大量用戶與海量的信息是無法自行匹配的，需要推送演算法把用戶和內容連接起來，在用戶和內容之間發揮橋梁作用，高效把合適的內容推薦給合適的用戶。

2.2.2新聞推薦演算法的基本原理

演算法推送的出現需要具備兩個條件：足夠的信息源和精確的演算法框架。其中，演算法的內容生產源與信息分發最終效果密切相關：是否有足夠多的信息可供抓取與信息是否有足夠的品質令用戶滿意都將對信息的傳播效果產生影響。與此同時，分發環節也在向前追溯，改變著整個傳播的生態。目前，國內新聞傳播領域所使用的演算法推送主要有三大類——協同過濾推送、基於內容推送和關聯規則推送。

協同過濾推送分為基於用戶的協同過濾和基於模型的協同過濾。前者主要考慮的是用戶和用戶之間的相似度，只要找出相似用戶喜歡的新聞文章類別，並預測目標用戶對該文章的喜歡程度，就可以將其他文章推薦給用戶；後者和前者是類似的，區別在此時轉向找到文章和文章之間的相似度，只有找到了目標用戶對某類文章的喜愛程度，那麼我們就可以對相似度高的類似文章進行預測，將喜愛程度相當的相似文章推薦給用戶。因此，前者利用用戶歷史數據在整個用戶資料庫中尋找相似的推送文章進行推薦，後者通過用戶歷史數據構造預測模型，再通過模型進行預測並推送。

基於內容的推送即根據用戶歷史進行文本信息特徵抽取、過濾，生成模型，向用戶推薦與歷史項目內容相似的信息。它的優點之一就是解決了協同過濾中數據稀少時無法准確判斷分發的問題。但如果長期只根據用戶歷史數據推薦信息，會造成過度個性化，容易形成「信息繭房」。

關聯規則推送就是基於用戶歷史數據挖掘用戶數據背後的關聯，以分析用戶的潛在需求，向用戶推薦其可能感興趣的信息。基於該演算法的信息推薦流程主要分為兩個步驟，第一步是根據當前用戶閱讀過的感興趣的內容，通過規則推導出用戶還沒有閱讀過的可能感興趣的內容；第二是根據規則的重要程度，對內容排序並展現給用戶。關聯規則推送的效果依賴規則的數量和質量，但隨著規則數量的增多，對系統的要求也會提高。

2.2.3演算法推送的實現流程

在信息過載的時代，同一個新聞選題有很多同質化的報道，因此分發前需要對新聞內容進行消重，消重後的新聞內容便等待推送，此時的推送有三個類別：啟動推送、擴大推送和限制推送。

3.「今日頭條」新聞推薦演算法分析

「今日頭條」是國內一款資訊類的媒體聚合平台，每天有超過1.2億人使用。從「你關心的，才是頭條！」到如今的「信息創造價值！」，產品slogan的變化也意味著今日頭條正逐漸擺脫以往單一、粗暴的流量思維，而開始注重人與信息的連接，在促進信息高效、精準傳播的同時注重正確的價值引導。

在2018年初，「今日頭條」的資深演算法架構師曹歡歡博士在一場分享交流會上公開了其演算法運行原理。在他的敘述中，非常詳細地介紹了「今日頭條」的演算法推薦系統概述以及演算法推薦系統的操作原理。

3.1.1-1曹歡歡博士的今日頭條演算法建模

上圖用數學形式化的方法去描述「今日頭條」的演算法推送，實際上就是一個能夠得出用戶對內容滿意程度的函數：即y為用戶對內容的滿意度，Xi,Xc,Xu分別是今日頭條公開的演算法推送的三個維度：Xi是用戶，包括用戶的性別、年齡、職業和興趣標簽，還有其他演算法模型刻畫的隱形用戶偏好等；Xc是環境，這也是移動互聯網時代新聞推送的特點，由於用戶隨時隨地在不停移動，移動終端也在移動，用戶在不同的工作場合、旅行等場景信息推送偏好也會不同；Xu是內容，今日頭條本身就是信息聚合類平台，平台上涵蓋各種不同形式的內容。本章將以該函數為基礎，逐一分析今日頭條的推薦演算法。

3.1推薦維度之一：內容分析

內容分析原指第二次世界大戰期間，傳播學家拉斯韋爾等研究學家組織了「戰士通訊研究」的工作，以德國公開出版的戰時報紙為分析研究對象，弄清報紙內容本質性的事實和趨勢，揭示隱含的隱性情報內容，獲取了許多軍情機密情報並且對事態發展作出情報預測。在「今日頭條」中，內容分析則是對文章、視頻內容提取關鍵要素，通過對文本、視頻標題關鍵字進行語義識別，給內容進行分類。「今日頭條」的推送系統是典型的層次化文本分類演算法，來幫助每篇新聞找到合適的分類，比如：第一大分類是政治、科技、財經、娛樂、體育等，體育類可以下分籃球、足球、網球等，足球又可以下分中國足球和國際足球，中國足球最後下分為甲、中超、國家隊等。這一步是對文章進行對這個工作主要目的是對文章進行分類，方便以後對客戶推薦。

想要內容分析實現效果，則需要海量的內容信息給演算法系統提供有效的篩選和分類。「今日頭條」既然是依賴於演算法推送新聞，那它背後的資料庫必然是強大的，「網頁蜘蛛」和「頭條號」就是支撐今日頭條平台消息來源的重要渠道，其消息來源極其豐富，何時何地有何新鮮事，都能高效率抓取信息。

第一個消息來源的渠道是「網頁蜘蛛」，「網頁蜘蛛」又叫網頁爬蟲，頭條使用的就是搜索引擎爬蟲叫「Bytespider」。它能按照一定的規則，自動爬行抓取互聯網的信息或腳本，就像蜘蛛通過蛛網進行捕食，當發現新的信息資源，蜘蛛會立刻出動抓取信息內容並將其收入自己的資料庫中。和微信的垂直搜索不同，Bytespider是能夠抓取全網內容的全新搜索引擎，因此「今日頭條」的搜索引擎功能很全面，搜索的資源很廣，資源包容性極高。

Bytespider信息抓取的基本流程如下：首先是網頁抓取。Bytespider順著網頁中的超鏈接，從這個網站爬到另一個網站，通過超鏈接分析連續訪問抓取更多網頁。被抓取的網頁被稱之為網頁快照。由於互聯網中超鏈接的應用很普遍，理論上，從一定范圍的網頁出發，就能搜集到絕大多數的網頁。第二步是處理網頁。搜索引擎抓到網頁後，還要做大量的預處理工作，才能提供檢索服務。其中，最重要的就是提取關鍵詞，建立索引庫和索引。其他還包括消除重復網頁、判斷網頁類型、分析超鏈接、計算網頁的重要度、豐富度等。第三步提供檢索服務。用戶輸入關鍵詞進行檢索，搜索引擎從索引資料庫中找到匹配該關鍵詞的網頁，為了用戶便於判斷，除了網頁標題和URL外，還會提供一段來自網頁的摘要以及其他信息。

3.2推薦維度之二：用戶分析

用戶分析通過提取用戶的有效數據，如用戶經常瀏覽的文字類型、經常搜索的關鍵字、注冊時登記信息的內容等，演算法系統可以將每個用戶的瀏覽記錄、瀏覽時間、留言、評論和轉發等行為進行關鍵字提取，最終形成用戶畫像，以便之後對用戶進行文章和視頻的精準推送。舉個例子，給喜歡閱讀「體育」的用戶標上「體育」標簽；給喜歡「娛樂」的用戶標上「娛樂」的標簽，這一步的作用是給用戶的興趣進行建模，包括用戶對文章和視頻的全局熱度、分類熱度，主題熱度，以及關鍵詞熱度等。熱度信息在大的推薦系統能夠解決新聞冷啟動問題，幫助新聞實現推送。

用戶分析還具有協同特徵，它可以在部分程度上幫助解決所謂演算法越推越窄的問題。協同特徵也就是「聯想式」的推送方法，並非只考慮用戶已有歷史，而是通過用戶行為分析不同用戶間相似性，比如點擊相似、興趣分類相似、主題相似、興趣詞相似，甚至向量相似，從而擴展模型的探索能力。根據用戶之間計算數據的相似程度，把用戶細化分類成為不同的目標群體，再向目標群體集中的推送其感興趣的新聞內容

內容分析和用戶分析是相輔相成的，如果沒有分析的文本標簽，無法得到用戶興趣標簽，沒有用戶的興趣標簽就無法給用戶定位實現精準推送。

3.3推薦維度之三：環境分析

環境分析就是根據文章的時效性和接近性推送給相應的用戶，比如獲取用戶當前所在位置是否在旅遊區，這個可以通過獲取用戶的實時位置來實現。還會不斷與用戶之前經常出現的所在地進行對比等方式確認當前狀態，分析出用戶是在常住地區還是在旅行。這時若系統檢測到用戶正在泰山及周邊遊玩，則可能會相應推送泰山的相關文章、周邊的交通新聞和天氣信息等等。

通過上面三個推薦維度可以作為數據基礎，分析當前用戶處於什麼環境，結合用戶畫像以及文章的內容分類來推薦，盡量做到推送的內容都是用戶所感興趣的。演算法系統還會通過內容分類、分析抽取，把文本相似度高的文章，包括新聞主題、內容相似的文章進行消重，解決推送重復的問題，進一步對目標用戶進行精確且不重復的內容推薦。最後過濾質量低俗色情的內容，以免造成平台會有負面傾向。

3.4「今日頭條」新聞推薦演算法的價值取向

3.4.1「用戶為上」

「今日頭條」的演算法推送是站在用戶的立場上的，以滿足用戶個性化和推送的精準性，「今日頭條」也重新衡量了新聞價值標准：以用戶為上，用戶對新聞內容和閱讀方式的滿意度便是平台推送新聞的價值宗旨。傳統媒體時代，只有報紙和電視，有什麼受眾就得看什麼，而如今「今日頭條」根據用戶興趣去進行推送。演算法推送平台用戶范圍廣，很多用戶熱衷關注負面，也有許多用戶都有窺視欲和好奇心，喜歡無聊八卦和無聊新聞，而且在好奇心作用下用戶都有從眾心理。這使得生產者過度去迎合受眾，只要是用戶喜歡看就可以發表在「今日頭條」上。

3.4.2「演算法主導」

「今日頭條」更注重技術分發，生產者是用戶，受眾者也是用戶，這樣一來內容監管和分發就很困難。演算法推送機制根據用戶愛好進行推送，這樣生產的內容快、也無疑會加速內容配送效率。在演算法推送模型中，用戶點擊頻率、閱讀時間、點贊評論以及轉發在演算法時代都是可以進行量化的目標。在這樣情況下生產的內容，想要獲得較大點擊率和推送率，需要標題才能吸引用戶，因為用戶在平台一眼能看到的就是標題和配圖。標題和配圖決定用戶是否會打開你的內容，這導致許多內容生產者在編輯新聞標題時陷入標題黨的怪圈，還有導致低俗內容的呈現，以製造沖突製造懸念貼標簽等方式引用戶點擊，意圖把自己的文章做成爆文。對於海量的信息內容，即使今日頭條數據和智能推薦做的再好，目前來說也難以抵擋海量的垃圾信息。

4.演算法推送新聞引發的倫理問題

在如今網路時代的傳播思維中，「用戶為上」、「演算法主導」的新聞價值取向已經在演算法聚合類平台成為了普遍，演算法推送技術作為吸引用戶的手段，搭建起一個充滿誘導的媒介環境，以此增加用戶對平台的粘性。演算法推送技術在獲取信息、傳播速度等方面與以往相比有著跨時代的進步，但與此同時，由於演算法推送技術的加入，衍生出新的倫理問題，並且日漸復雜化。

4.1演算法推送引發的倫理問題

4.1.1演算法推送過於機械化，沒有思考能力

單向的演算法推薦對用戶來說經常會帶來內容雜亂無章、信息量過大、信息價值低等問題。從邏輯講，演算法只是從關鍵字的檢索匹配來完成統計推薦，但對新聞報道或文學作品具有藝術性、專業性的內容來說，是不能保證推送的質量的。演算法方面，目前主要基於匹配檢索與統計，大部分都是個人關注的信息類型和標簽，難以達到較好的推送效果。一千個人眼裡有一千個哈姆雷特，但是計算機只有隻有一個。演算法技術過於注重機械化的統計，只根據關鍵詞來推薦用戶，對我們中國具有博大精深的中國文字文化底蘊，推薦演算法是遠遠不夠的。整個新聞客戶端顯得像是一個菜市場，沒有態度、沒有風格，閱讀感受單一化，呈現了碎片化的特點。新聞不只是讓用戶能夠了解身邊發生的新鮮事，還有宣傳正面思想和傳播正能量的作用，新聞應該還要給人們帶來新的思考。讓機器做出正確判斷很簡單，但是讓機器綜合心理學、社會學、乃至某細分領域內的規則做出判斷還要正確地引導受眾則很難，正如現在演算法技術還不能完成一篇富有人文性、文學性和批判性的深度報道，它止步在了碎片式的、表層的傳播范疇。

4.1.2容易引起「信息繭房」效應

「信息繭房」這一概念是凱斯.桑斯坦在《信息烏托邦》一書中提出的。意指受眾在過度的信息自我選擇之中，這樣會降低接觸外界其他信息的可能，從而將自己的生活桎梏於蠶繭一般的「蠶房」中的現象。人們的信息領域會習慣性被自己的興趣引導，信息窄化帶來了受眾對信息接收的單一性，這種單一性的可能會使受眾陷入循環，加重受眾信息同質化。

4.1.3演算法推送的「偽中立性」

客觀和全面是新聞倫理的基本要求，新聞從業者必須從可好信息源來獲取真實的信息，以客觀的態度反應現實。我們慣常認為,互聯網技術服務商是技術中立者,不需要承擔約束大眾媒體的社會責任，然而當信息把關人又新聞編輯轉變為演算法工程師，傳統的媒介倫理似乎已經失效。演算法具有商業傾向性，「中立性」是演算法平台用以逃避媒體責任的理由，給大眾媒介造成傳播亂象，如此一來更像是一場演算法平台「肆意妄為又不想負責」的詭辯。

演算法平台的信息源是經過選擇和過濾的，「頭條號」的內容占「今日頭條」整個信息系統的絕大部分，然而在「人人都可以做新聞人」的時代，頭條號平台是一個開放的網路媒介環境，存在大量的偏見和錯誤的認知。無論是「今日頭條」平台設立的演算法規則，還是其他爬蟲的抓取的關鍵詞，演算法系統的信息源很多是具有目的性的、有偏見和非客觀的信息，所以信息源不能直接作用於用戶。因此，篩選演算法系統的信息源與傳統的人工編輯相比較，范圍極廣且很難把關，若演算法被惡意利用，那麼使整個傳播系統將會被輕易控制。

4.1.4演算法推送里的「議程設置」

原議程設置功能揭示的重要內涵是：「受眾對新聞的看法雖然被大眾媒體議程設置功能所主導，但其更深刻的是議程設置給大眾媒體新聞帶來放大與延伸，從而使受眾對新聞選擇做出能動性修正，讓受眾在滿足需求和媒介依賴中逐漸培養出的潛在認同感」。

推送演算法技術在互聯網平台的運用，使原來傳統媒體主導的議程設置過程發生了變化，伴隨著傳播權的轉移、公眾參與度的提高和信息量劇增等原因導致議程設置功逐漸能減弱。過往傳統新聞的內容是由編輯有選擇地進行報道後再呈現在受眾面前的，而個性化新聞推送是用戶自己來選擇看哪一方面的內容，而這一環節中，天然的技術賦權將傳播權從傳統媒體下放至平台的用戶，使得受眾和社會的連接無需依賴傳統媒介，新聞媒體作為把關人的作用和議程設置功能都在減弱。

4.2演算法新聞治理缺陷下的演算法權利異化

演算法作為人工智慧的基石之一，是「一種有限、確定、有效並適合用計算機程序來實現的解決問題的方法,是計算機科學的基礎」。近年來,伴隨人工智慧深度學習演算法取得的重大突破和大數據時代的到來,人工智慧的應用場景不斷拓展，人工智慧時代正逐漸從想像成為現實。藉助於海量的大數據和具備強大計算能力的硬體設備,擁有深度學習演算法的人工智慧機器可以通過自主學習和強化訓練來不斷提升自身的能力,解決很多人類難以有效應對的治理難題。伴隨人工能演算法在國家和社會治理中重要性的日漸凸顯,國家和社會對於演算法的依賴也逐漸加深,一種新型的權力形態——演算法權力也隨之出現。

可以把演算法權利分為四種：數據主權、演算法設計權、研發的資本權和演算法控制權。由於前三種權利都是單向的、演算法開發者賦予演算法的權利，是屬於演算法開發者的，與演算法分發平台呈現的效果沒有直接的影響，所以本文將著重論述演算法控制權。

演算法控制權是雙向的，用戶是演算法技術數據行為的提供者，同時又是被演算法技術控制的受害者。例如我們看到「今日頭條」會通過推送演算法來監管用戶的發布和瀏覽行為，同時平台會通過演算法決策系統來實現內容的發布去引導用戶。演算法控制權當然是一種天然技術賦予的權利，但演算法控制權是在用戶提供數據行為的情況下才得以實現的，因此演算法控制權既存在內容生產權，同時有要尊重和保護演算法相對人的義務。

正因為如此，演算法技術被認為是一種雙刃劍，一方面演算法能夠做出精準的行為預測，可以為管理者提供非常好的循環干預機制；對於公共行為主體來說，可以通過對大數據的應用來解決社會治理問題，對於私人主體來說可以藉助數據來提供個性化和定製化的服務；另一方面，演算法技術存在著諸如利益和風險不對稱等問題，而且由於演算法技術發展的超前性，新科技的創造者具備不對稱的信息和技術優勢，能夠按照自身利益的需求來塑造在平台上的演算法推送邏輯和社會系統，這帶來了監管的不確定性。人們要通過集體行為去承擔社會責任，通過這樣的方式規制演算法權利，可以讓我們能夠對演算法分發系統的意義和價值得到更深刻的思考。

4. 協同過濾java用什麼實現

眾所周知，java在處理數據量比較大的時候，載入到內存必然會導致內存溢出，而在一些數據處理中我們不得不去處理海量數據，在做數據處理中，我們常見的手段是分解，壓縮，並行，臨時文件等方法;例如，我們要將資料庫(不論是什麼資料庫)的數據導出到一個文件，一般是Excel或文本格式的CSV;對於Excel來講，對於POI和JXL的介面，你很多時候沒有法去控制內存什麼時候向磁碟寫入，很惡心，而且這些API在內存構造的對象大小將比數據原有的大小要大很多倍數，所以你不得不去拆分Excel，還好，POI開始意識到這個問題，在3.8.4的版本後，開始提供cache的行數，提供了SXSSFWorkbook的介面，可以設置在內存中的行數，不過可惜的是，他當你超過這個行數，每添加一行，它就將相對行數前面的一行寫入磁碟(如你設置2000行的話，當你寫第20001行的時候，他會將第一行寫入磁碟)，其實這個時候他些的臨時文件，以至於不消耗內存，不過這樣你會發現，刷磁碟的頻率會非常高，我們的確不想這樣，因為我們想讓他達到一個范圍一次性將數據刷如磁碟，比如一次刷1M之類的做法，可惜現在還沒有這種API，很痛苦，我自己做過測試，通過寫小的Excel比使用目前提供刷磁碟的API來寫大文件，效率要高一些，而且這樣如果訪問的人稍微多一些磁碟IO可能會扛不住，因為IO資源是非常有限的，所以還是拆文件才是上策;而當我們寫CSV，也就是文本類型的文件，我們很多時候是可以自己控制的，不過你不要用CSV自己提供的API，也是不太可控的，CSV本身就是文本文件，你按照文本格式寫入即可被CSV識別出來;如何寫入呢？下面來說說。。。在處理數據層面，如從資料庫中讀取數據，生成本地文件，寫代碼為了方便，我們未必要1M怎麼來處理，這個交給底層的驅動程序去拆分，對於我們的程序來講我們認為它是連續寫即可;我們比如想將一個1000W數據的資料庫表，導出到文件;此時，你要麼進行分頁，oracle當然用三層包裝即可，mysql用limit，不過分頁每次都會新的查詢，而且隨著翻頁，會越來越慢，其實我們想拿到一個句柄，然後向下游動，編譯一部分數據(如10000行)將寫文件一次(寫文件細節不多說了，這個是最基本的)，需要注意的時候每次buffer的數據，在用outputstream寫入的時候，最好flush一下，將緩沖區清空下;接下來，執行一個沒有where條件的SQL，會不會將內存撐爆？是的，這個問題我們值得去思考下，通過API發現可以對SQL進行一些操作，例如，通過：PreparedStatementstatement=connection.prepareStatement(sql)，這是默認得到的預編譯，還可以通過設置：PreparedStatementstatement=connection.prepareStatement(sql，ResultSet.TYPE_FORWARD_ONLY，ResultSet.CONCUR_READ_ONLY);來設置游標的方式，以至於游標不是將數據直接cache到本地內存，然後通過設置statement.setFetchSize(200);設置游標每次遍歷的大小;OK，這個其實我用過，oracle用了和沒用沒區別，因為oracle的jdbcAPI默認就是不會將數據cache到java的內存中的，而mysql里頭設置根本無效，我上面說了一堆廢話，呵呵，我只是想說，java提供的標准API也未必有效，很多時候要看廠商的實現機制，還有這個設置是很多網上說有效的，但是這純屬抄襲;對於oracle上面說了不用關心，他本身就不是cache到內存，所以java內存不會導致什麼問題，如果是mysql，首先必須使用5以上的版本，然後在連接參數上加上useCursorFetch=true這個參數，至於游標大小可以通過連接參數上加上：defaultFetchSize=1000來設置，例如：jdbc：mysql：//xxx.xxx.xxx.xxx：3306/abc？zeroDateTimeconvertToNull&useCursorFetch=true&defaultFetchSize=1000上次被這個問題糾結了很久(mysql的數據老導致程序內存膨脹，並行2個直接系統就宕了)，還去看了很多源碼才發現奇跡竟然在這里，最後經過mysql文檔的確認，然後進行測試，並行多個，而且數據量都是500W以上的，都不會導致內存膨脹，GC一切正常，這個問題終於完結了。我們再聊聊其他的，數據拆分和合並，當數據文件多的時候我們想合並，當文件太大想要拆分，合並和拆分的過程也會遇到類似的問題，還好，這個在我們可控制的范圍內，如果文件中的數據最終是可以組織的，那麼在拆分和合並的時候，此時就不要按照數據邏輯行數來做了，因為行數最終你需要解釋數據本身來判定，但是只是做拆分是沒有必要的，你需要的是做二進制處理，在這個二進制處理過程，你要注意了，和平時read文件不要使用一樣的方式，平時大多對一個文件讀取只是用一次read操作，如果對於大文件內存肯定直接掛掉了，不用多說，你此時因該每次讀取一個可控范圍的數據，read方法提供了重載的offset和length的范圍，這個在循環過程中自己可以計算出來，寫入大文件和上面一樣，不要讀取到一定程序就要通過寫入流flush到磁碟;其實對於小數據量的處理在現代的NIO技術的中也有用到，例如多個終端同時請求一個大文件下載，例如視頻下載吧，在常規的情況下，如果用java的容器來處理，一般會發生兩種情況：其一為內存溢出，因為每個請求都要載入一個文件大小的內存甚至於，因為java包裝的時候會產生很多其他的內存開銷，如果使用二進制會產生得少一些，而且在經過輸入輸出流的過程中還會經歷幾次內存拷貝，當然如果有你類似nginx之類的中間件，那麼你可以通過send_file模式發送出去，但是如果你要用程序來處理的時候，內存除非你足夠大，但是java內存再大也會有GC的時候，如果你內存真的很大，GC的時候死定了，當然這個地方也可以考慮自己通過直接內存的調用和釋放來實現，不過要求剩餘的物理內存也足夠大才行，那麼足夠大是多大呢？這個不好說，要看文件本身的大小和訪問的頻率;其二為假如內存足夠大，無限制大，那麼此時的限制就是線程，傳統的IO模型是線程是一個請求一個線程，這個線程從主線程從線程池中分配後，就開始工作，經過你的Context包裝、Filter、攔截器、業務代碼各個層次和業務邏輯、訪問資料庫、訪問文件、渲染結果等等，其實整個過程線程都是被掛住的，所以這部分資源非常有限，而且如果是大文件操作是屬於IO密集型的操作，大量的CPU時間是空餘的，方法最直接當然是增加線程數來控制，當然內存足夠大也有足夠的空間來申請線程池，不過一般來講一個進程的線程池一般會受到限制也不建議太多的，而在有限的系統資源下，要提高性能，我們開始有了newIO技術，也就是NIO技術，新版的裡面又有了AIO技術，NIO只能算是非同步IO，但是在中間讀寫過程仍然是阻塞的(也就是在真正的讀寫過程，但是不會去關心中途的響應)，還未做到真正的非同步IO，在監聽connect的時候他是不需要很多線程參與的，有單獨的線程去處理，連接也又傳統的socket變成了selector，對於不需要進行數據處理的是無需分配線程處理的;而AIO通過了一種所謂的回調注冊來完成，當然還需要OS的支持，當會掉的時候會去分配線程，目前還不是很成熟，性能最多和NIO吃平，不過隨著技術發展，AIO必然會超越NIO，目前谷歌V8虛擬機引擎所驅動的node.js就是類似的模式，有關這種技術不是本文的說明重點;將上面兩者結合起來就是要解決大文件，還要並行度，最土的方法是將文件每次請求的大小降低到一定程度，如8K(這個大小是經過測試後網路傳輸較為適宜的大小，本地讀取文件並不需要這么小)，如果再做深入一些，可以做一定程度的cache，將多個請求的一樣的文件，cache在內存或分布式緩存中，你不用將整個文件cache在內存中，將近期使用的cache幾秒左右即可，或你可以採用一些熱點的演算法來配合;類似迅雷下載的斷點傳送中(不過迅雷的網路協議不太一樣)，它在處理下載數據的時候未必是連續的，只要最終能合並即可，在伺服器端可以反過來，誰正好需要這塊的數據，就給它就可以;才用NIO後，可以支持很大的連接和並發，本地通過NIO做socket連接測試，100個終端同時請求一個線程的伺服器，正常的WEB應用是第一個文件沒有發送完成，第二個請求要麼等待，要麼超時，要麼直接拒絕得不到連接，改成NIO後此時100個請求都能連接上伺服器端，服務端只需要1個線程來處理數據就可以，將很多數據傳遞給這些連接請求資源，每次讀取一部分數據傳遞出去，不過可以計算的是，在總體長連接傳輸過程中總體效率並不會提升，只是相對相應和所開銷的內存得到量化控制，這就是技術的魅力，也許不要太多的演算法，不過你得懂他。類似的數據處理還有很多，有些時候還會將就效率問題，比如在HBase的文件拆分和合並過程中，要不影響線上業務是比較難的事情，很多問題值得我們去研究場景，因為不同的場景有不同的方法去解決，但是大同小異，明白思想和方法，明白內存和體系架構，明白你所面臨的是沈陽的場景，只是細節上改變可以帶來驚人的效果。

5. 推薦系統（一）：基於物品的協同過濾演算法

協同過濾(collaborative filtering)演算法是最經典、最常用的推薦演算法。其基本思想是收集用戶偏好，找到相似的用戶或物品，然後計算並推薦。
基於物品的協同過濾演算法的核心思想就是：給用戶推薦那些和他們之前喜歡的物品相似的物品。主要可分為兩步：
(1) 計算物品之間的相似度，建立相似度矩陣。
(2) 根據物品的相似度和用戶的歷史行為給用戶生成推薦列表。

相似度的定義有多種方式，下面簡要介紹其中幾種：

其中，分母 是喜歡物品 的用戶數，而分子 是同時喜歡物品 和物品 的用戶數。因此，上述公式可以理解為喜歡物品 的用戶中有多少比例的用戶也喜歡物品 。
上述公式存在一個問題。如果物品 很熱門， 就會很大，接近1。因此，該公式會造成任何物品都會和熱門的物品有很大的相似度，為了避免推薦出熱門的物品，可以用下面的公式：

這個公式懲罰了物品 的權重，因此減輕了熱門物品會和很多物品相似的可能性。
另外為減小活躍用戶對結果的影響，考慮IUF(nverse User Frequence) ，即用戶活躍度對數的倒數的參數，認為活躍用戶對物品相似度的貢獻應該小於不活躍的用戶。

為便於計算，還需要進一步將相似度矩陣歸一化 。

其中 表示用戶 對物品 的評分。 在區間 內，越接近1表示相似度越高。

表示空間中的兩個點，則其歐幾里得距離為：

當 時，即為平面上兩個點的距離，當表示相似度時，可採用下式轉換：

距離越小，相似度越大。

一般表示兩個定距變數間聯系的緊密程度，取值范圍為[-1,1]

其中 是 和 的樣品標准差

將用戶行為數據按照均勻分布隨機劃分為M份，挑選一份作為測試集，將剩下的M-1份作為訓練集。為防止評測指標不是過擬合的結果，共進行M次實驗，每次都使用不同的測試集。然後將M次實驗測出的評測指標的平均值作為最終的評測指標。

對用戶u推薦N個物品(記為 )，令用戶u在測試集上喜歡的物品集合為 ，召回率描述有多少比例的用戶-物品評分記錄包含在最終的推薦列表中。

准確率描述最終的推薦列表中有多少比例是發生過的用戶-物品評分記錄。

覆蓋率反映了推薦演算法發掘長尾的能力，覆蓋率越高，說明推薦演算法越能夠將長尾中的物品推薦給用戶。分子部分表示實驗中所有被推薦給用戶的物品數目(集合去重)，分母表示數據集中所有物品的數目。

採用GroupLens提供的MovieLens數據集， http://www.grouplens.org/node/73 。本章使用中等大小的數據集，包含6000多用戶對4000多部電影的100萬條評分。該數據集是一個評分數據集，用戶可以給電影評1-5分5個不同的等級。本文著重研究隱反饋數據集中TopN推薦問題，因此忽略了數據集中的評分記錄。

該部分定義了所需要的主要變數，集合採用字典形式的數據結構。

讀取原始CSV文件，並劃分訓練集和測試集，訓練集佔比87.5%，同時建立訓練集和測試集的用戶字典，記錄每個用戶對電影評分的字典。

第一步循環讀取每個用戶及其看過的電影，並統計每部電影被看過的次數，以及電影總數；第二步計算矩陣C，C[i][j]表示同時喜歡電影i和j的用戶數，並考慮對活躍用戶的懲罰；第三步根據式\ref{similarity}計算電影間的相似性；第四步進行歸一化處理。

針對目標用戶U，找到K部相似的電影，並推薦其N部電影，如果用戶已經看過該電影則不推薦。

產生推薦並通過准確率、召回率和覆蓋率進行評估。

結果如下所示，由於數據量較大，相似度矩陣為 維，計算速度較慢，耐心等待即可。

[1]. https://blog.csdn.net/m0_37917271/article/details/82656158
[2]. 推薦系統與深度學習. 黃昕等. 清華大學出版社. 2019.
[3]. 推薦系統演算法實踐. 黃美靈. 電子工業出版社. 2019.
[4]. 推薦系統演算法. 項亮. 人民郵電出版社. 2012.
[5]. 美團機器學習實踐. 美團演算法團隊. 人民郵電出版社. 2018.

6. Spark 推薦演算法-協同過濾-java的語句意思

協同過濾(Collaborative Filtering)的基本概念就是把這種方式變成自動化的流程

協同過濾主要是以屬性或興趣相近的用戶經驗與建議作為提供個性化的基礎。透過協同過濾，有助於搜集具有類似偏好或屬性的用戶，並將其意見提供給同一集群中的用戶作為參考，以滿足人們通常在決策之前參考他人意見的心態。

本人認為，協同過濾技術應包括如下幾方面:(1)一種比對和搜集每個用戶興趣偏好的過程;(2)它需要許多用戶的信息去預測個人的興趣偏好;(3)通過對用戶之間興趣偏好相關程度的統計去發展建議那些有相同興趣偏好的用戶。

7. 協同過濾的演算法簡介

電子商務推薦系統的一種主要演算法。
協同過濾推薦（Collaborative Filtering recommendation）是在信息過濾和信息系統中正迅速成為一項很受歡迎的技術。與傳統的基於內容過濾直接分析內容進行推薦不同，協同過濾分析用戶興趣，在用戶群中找到指定用戶的相似（興趣）用戶，綜合這些相似用戶對某一信息的評價，形成系統對該指定用戶對此信息的喜好程度預測。
與傳統文本過濾相比，協同過濾有下列優點:
（1）能夠過濾難以進行機器自動基於內容分析的信息。如藝術品、音樂;
（2）能夠基於一些復雜的，難以表達的概念（信息質量、品位)進行過濾;
（3）推薦的新穎性。
正因為如此，協同過濾在商業應用上也取得了不錯的成績。Amazon，CDNow，MovieFinder，都採用了協同過濾的技術來提高服務質量。
缺點是:
（1）用戶對商品的評價非常稀疏，這樣基於用戶的評價所得到的用戶間的相似性可能不準確（即稀疏性問題）;
（2）隨著用戶和商品的增多，系統的性能會越來越低;
（3）如果從來沒有用戶對某一商品加以評價，則這個商品就不可能被推薦（即最初評價問題）。
因此，現在的電子商務推薦系統都採用了幾種技術相結合的推薦技術。
案例: AMAZON個性化推薦系統先驅 (基於協同過濾)
AMAZON是一個虛擬的網上書店，它沒有自己的店面，而是在網上進行在線銷售。它提供了高質量的綜合節目資料庫和檢索系統，用戶可以在網上查詢有關圖書的信息。如果用戶需要購買的話，可以把選擇的書放在虛擬購書籃中，最後查看購書籃中的商品，選擇合適的服務方式並且提交訂單，這樣讀者所選購的書在幾天後就可以送到家。
AMAZON書店還提供先進的個性化推薦功能，能為不同興趣偏好的用戶自動推薦盡量符合其興趣需要的書籍。 AMAZON使用推薦軟體對讀者曾經購買過的書以及該讀者對其他書的評價進行分析後，將向讀者推薦他可能喜歡的新書，只要滑鼠點一下，就可以買到該書；AMAZON能對顧客購買過的東西進行自動分析，然後因人而異的提出合適的建議。讀者的信息將被再次保存，這樣顧客下次來時就能更容易的買到想要的書。此外，完善的售後服務也是AMAZON的優勢，讀者可以在拿到書籍的30天內，將完好無損的書和音樂光碟退回AMAZON，AMAZON將原價退款。當然AMAZON的成功還不止於此，如果一位顧客在AMAZON購買一本書，下次他再次訪問時，映入眼簾的首先是這位顧客的名字和歡迎的字樣。