Makine Öğrenimi Olmadan Temel Öneri Motoru Nasıl Oluşturulur

Öneri sistemleri hayatımızın ayrılmaz ve vazgeçilmez bir parçası haline geldi. Bu akıllı algoritmalar, tükettiğimiz içeriği, satın aldığımız ürünleri ve araştırdığımız hizmetleri etkileyerek çevrimiçi deneyimlerimizi şekillendirmede çok önemlidir. Netflix gibi platformlarda içerik akışı yapıyor olsak da, Spotify'da yeni müzikler keşfediyor olsak da ya da çevrimiçi alışveriş yapıyor olsak da, öneri sistemleri etkileşimlerimizi kişiselleştirmek ve geliştirmek için perde arkasında sessizce çalışıyor.

Bu öneri sistemlerinin benzersiz unsuru, geçmiş davranış ve kullanıcı kalıplarına dayalı tercihlerimizi anlama ve tahmin etme yetenekleridir. Bu sistemler geçmiş tercihlerimizi analiz ederek kişiye özel öneriler hazırlayarak zamandan ve emekten tasarruf etmemizi sağlarken ilgi alanlarımıza uygun içerik/ürünlerle bizi tanıştırır. Bu, kullanıcı memnuniyetini artırır ve keşfi teşvik ederek bizi başka türlü karşılaşmayacağımız yeni ve ilgili tekliflerle tanıştırır.

Geliştiriciler yüksek düzeyde, bu algoritmaların makine öğrenimi ve derin öğrenme sistemleri (birbirinin yerine sinir ağları olarak adlandırılır) tarafından desteklendiğini anlıyorlar, ancak size sinir ağlarınızı dağıtma zahmetine girmeden bir öneri motoru oluşturmanın bir yolu olduğunu söylersem ne olur? net mi yoksa makine öğrenimi modeli mi?

Bu soru özellikle erken ve orta aşamadaki girişimler bağlamında önemlidir çünkü modellerini eğitmek için tonlarca yapılandırılmış veriye sahip değillerdir. Zaten bildiğimiz gibi çoğu makine öğrenimi modeli, uygun eğitim verileri olmadan doğru tahminler vermez.

Yakın zamanda bir temel öneri motoru geliştirdim ve uygulamaya koydum. önce ses sosyal ağı Bu da temel ölçümlerimizde %40'lık bir artışa yol açtı. Bu blogun yazıldığı sırada sistem ayda 30 milyondan fazla öneri üretiyor. Bu öneri sistemi bir sosyal ağ için oluşturulmuş olsa da temel mimariyi ürün önerileri, müzik önerileri, metin ve video platformlarındaki içerik önerileri veya başka herhangi bir kullanım durumuna uygulayabilirsiniz. Sorun ifadesini açıklayarak başlayayım.

Mühendislik perspektifinden problem bildirimi

kapsamlı bir deneyimim vardı ürün ihtiyaç belgesi Ve sonraki mühendislik gereksinimleri belgesi Çünkü halihazırda her gün binlerce kullanıcının kullandığı bir ürün için öneri sistemi oluşturuyorduk. Ancak bu blogu kısa ve öz tutmak için yalnızca üst düzey gereksinimleri yazacağım ve ardından bunların çözümünü tartışacağım. Ürününüz için bir öneri sistemi oluşturuyorsanız (basit veya sinir ağı tabanlı) ve bir yerde takılıp kalırsanız lütfen benimle iletişime geçmekten çekinmeyin. heyecan veya LinkedIn ve sorularınızı yanıtlamaktan büyük mutluluk duyacağım.

Yüksek düzeyde, mühendislik açısından aşağıdaki gereksinimlere sahiptik:

1. Sistem, kullanıcının ilgi alanlarını anahtar kelimeler biçiminde yakalayabilmelidir. Sistem ayrıca belirli anahtar kelimelerle kullanıcının ilgi düzeyini de sınıflandırabilmelidir.

   
   

2. Sistem, bir kullanıcının diğer kullanıcılardaki ilgisini çekebilmelidir. Bir kullanıcının başka bir kullanıcı tarafından oluşturulan içeriğe olan ilgi düzeyini sınıflandırabilmelidir.

   
   

3. Sistem, kullanıcının ilgi alanlarına göre yüksek kaliteli öneriler üretebilmelidir.

   
   

4. Sistem, kullanıcı tarafından halihazırda görüntülenen/reddedilen önerilerin X gün boyunca tekrar görünmemesini sağlayabilmelidir.

   
   

5. Sistem, aynı yaratıcıların gönderilerinin aynı sayfada gruplanmamasını sağlayacak bir mantığa sahip olmalıdır . Sistem, bir kullanıcı on gönderi (bizim sayfa boyutumuz) tüketirse, bunların hepsinin farklı yaratıcılardan olmasını sağlamak için elinden geleni yapmalıdır.

   
   

6. Sistem hızlı olmalı. 150 milisaniyeden az P99 gecikmesi.

   
   

7. Yüksek kullanılabilirlik, ölçeklenebilirlik, güvenlik, güvenilirlik, sürdürülebilirlik vb. gibi diğer tüm işlevsel olmayan gereksinimler yerine getirilmelidir.

   
   

Yine, bu oldukça aşırı basitleştirilmiş bir sorun bildirimleri listesidir. Gerçekte belgeler 3000'den fazla kelime uzunluğundaydı, çünkü bu öneri motorunu mevcut sistemlerimize entegre ederken ortaya çıkabilecek birçok uç durumu ve köşe durumu da kapsıyordu. Çözüme geçelim.

Çözüm - Öneri motorunun üst düzey çalışması

Sorunun çözümlerini tek tek ele alıp ardından tüm sistemin genel işleyişini anlatacağım.

İlk sorunumuz kullanıcının ilgi alanlarını yakalamak ve ilgi düzeyini belirli bir ilgi alanıyla tanımlamaktır.

Bunun için adı verilen bir şey yarattık. sosyal grafik . Basitçe ifade etmek gerekirse, bir sosyal grafik, bir sosyal ağdaki farklı varlıklar arasındaki ilişkileri ve bağlantıları saklar. Bu varlıklar farklı kullanıcılar veya belirli bir ilgi alanına sahip kullanıcıların ilişkileri olabilir. Sosyal grafikler, belirli bir sistem içindeki ilişkileri anlamanın ve yapılandırmanın güçlü bir yoludur. Kısa olması adına sosyal grafiği detaylı olarak açıklamayacağım, ancak Google'da aramanızı ve hakkında daha fazla bilgi edinmenizi tavsiye edeceğim. Aşağıda öneri motorumuz için oluşturduğum sosyal grafiğin basitleştirilmiş bir versiyonu bulunmaktadır.

Yukarıdaki görüntüden de görebileceğiniz gibi, etkileşimlerin sayısı (beğeniler, yorumlar, paylaşımlar) ve bu etkileşimlerin güncelliği (en son ne zaman gerçekleştiği) gibi birçok bilgiyi iki kullanıcı arasındaki ilişki verileri olarak saklıyoruz. bir kullanıcı ve ilgi. İki farklı ilgi alanı anahtar kelimesi arasındaki ilişkiyi bile saklıyoruz. kullandım Amazon Neptün Bu sosyal grafiği depolamak için AWS tarafından yönetilen bir grafik veritabanı. Neo4j, JanusGraph, ArrangoDB vb. gibi başka herhangi bir grafik veritabanını kullanabilirsiniz.

Bu ilgi alanı anahtar kelimeleri ağırlıklı olarak isimlerdir. Bir gönderinin içeriğini bu anahtar kelimelere (isimlere) ayıran bir sistem mevcuttur. AWS tarafından desteklenmektedir; metni varlıklara, anahtar ifadelere vb. bölmek için makine öğrenimini kullanan bir doğal dil işleme (NLP) hizmetidir. Aynı işlemi gerçekleştirmek için yine herhangi bir yönetilen NLP hizmetini (birkaç tane mevcuttur) kullanabilirsiniz. Makine öğrenimi modellerinizi öğrenmenize veya dağıtmanıza gerek yok! Makine öğrenimini zaten anlıyorsanız kontrol edebilirsiniz Huggingface'te açık kaynaklı NLP modelleri .

İkinci sorunumuz, kullanıcının ilgisine dayalı yüksek kaliteli öneriler oluşturmaktır

Aşağıdaki diyagram sistemin nasıl çalıştığının basitleştirilmiş üst düzey bir temsilidir.

Yukarıdakiler kolay gibi görünse de, her adımda gerçekleşen çok daha fazlası vardır ve sistemin en iyi şekilde performans göstermesini sağlamak için bunların dikkatlice düşünülmesi ve programlanması gerekir.

Adım adım anlatayım:

Adım 1 - Gönderi içeriğini vektör yerleştirmelerine dönüştürme

Bu önerileri oluşturmak için öncelikle bir gönderinin içeriğini şu şekilde bir şeye dönüştürmeliyiz: Vektör eklemeleri . LLM'lerin markalaşmasındaki son artışla birlikte OpenAI (ChatGPT'nin yaratıcıları) ve Vektör veritabanları , Vektör yerleştirmeleri günlük bir terim haline geliyor. Ne olduklarına ve nasıl çalıştıklarına dair ayrıntılara girmeyeceğim, ancak onlar hakkında daha fazla bilgi okumanızı şiddetle tavsiye ederim. Ancak bir yayın için uygun adaylar oluşturmak aynı zamanda içerik gizliliği ve denetimi (küfürlü kelimelerin, suistimallerin, cinsel içeriklerin, tacizin, engellenen kullanıcıların filtrelenmesi vb. kaldırılması) gibi hususları da hesaba katmalıdır.

Vektör yerleştirmelerini oluşturmak için, kullanım durumunuza bağlı olarak OpenAI yerleştirme modeli , Amazon titan veya herhangi bir açık kaynaklı metin yerleştirme modeli gibi öne çıkan herhangi bir yerleştirme modelini kullanabilirsiniz. Uygun fiyatı, performansı ve operasyonel kolaylığı nedeniyle Amazon Titan'ı tercih ettik.

Adım 2 – Kullanıcının ilgisini sorgulayın

İşte işlerin ilginçleştiği yer burası. Sorguları özel iş ihtiyaçlarınıza göre tasarlamak istersiniz. Örneğin, ilgi alanlarını sorgularken belirli bir anahtar kelime veya kullanıcıyla gerçekleşen etkileşimlerin sayısından ziyade etkileşimin güncelliğine daha fazla ağırlık veriyoruz. Ayrıca kullanıcının farklı ilgi türlerini (anahtar kelime veya diğer kullanıcı) bulmak için birden fazla paralel sorgu çalıştırırız. Tek bir kullanıcı için birden fazla yayın oluşturduğumuzdan, trende göre belirli bir konuyu tanıtan bazı sorgular da çalıştırıyoruz (örneğin, Noel'in yakınında Noel ile ilgili birçok gönderi veya deprem olmuşsa depremle ilgili gönderiler göreceksiniz). Söylemeye gerek yok, bu konu yalnızca kullanıcı yolculuğu sırasında bu konuya biraz ilgi duyduğunda sorgu sonuçlarında ortaya çıkacaktır.

Bu nedenle, iş kullanım durumunuza ve yönlendirmek istediğiniz davranışa uygun mantığı seçin ve tüm kullanıcının ilgi alanlarını içeren yeterince büyük bir liste elde etmek için birden fazla sorgu çalıştırın.

Adım 3 - Bulunan ilgi alanlarına göre bir YSA araması yapın

Vektör veritabanları ağırlıklı olarak belirli bir arama türünü gerçekleştirmek için kullanılır. Yaklaşık en yakın komşu araması (ANN). Yine, çeşitli ilgi alanlarını kategorilere ayırma şekliniz ve büyük bir YSA araması mı yoksa paralel fark aramaları mı yaptığınız tamamen kullanım senaryonuza ve iş gereksinimlerinize bağlı olmalıdır. En iyi son kullanıcı deneyimi için grup bazlı aramalardan daha fazlasını yapmanızı ve ardından sonuçları sıralamanızı (bunu bu blogda daha sonra tartışacağız) öneririm. Bu durumda YSA aramasının yaptığı şey, platformda kullanıcının ilgi alanlarına benzer (daha yakın) diğer gönderileri bulmaktır.

Adım 4 - Sonuçları sipariş vererek bir önbellek veritabanında saklayın.

Veritabanını önbelleğe alın çünkü çözmemiz gereken sorunlardan biri hızdır. Belirli bir kullanıcıya ait gönderilerin benzersiz kimliklerini depolamak için redis sorted setlerini kullandık. Bir kullanıcının akışındaki gönderilerin sırası kritik olduğundan redis sıralı kümeler kullandık. Ayrıca çözmeniz gereken bir diğer sorun da " sistemin, aynı yaratıcıların gönderilerinin aynı sayfada gruplanmamasını sağlayacak bir mantığa sahip olması gerektiğidir ". Aynı yaratıcının içeriğinin tekrarlanmasını önlemek için, belirli bir yaratıcının gönderisinin belirli bir kullanıcının akışında (sıralanmış küme) herhangi bir konuma eklenmesi durumunda, aynı yaratıcıdan başka bir gönderi eklemememizi sağlayan basit bir algoritma yazdık. ardışık on konum için (feed'i son kullanıcıya sunarken sayfa boyutumuz 10'dur, bu nedenle karmaşıklığı önlemek için onu statik tuttuk).

Kullanıcının belirli bir tavsiyesinin sırasına karar vermek için aşağıdakileri dikkate aldık:

1. Bu kullanıcının belirli bir ilgi alanıyla (veya başka bir kullanıcıyla) ilişkisinin gücü : Sosyal grafikten çeşitli veri noktalarını alan aritmetik bir formülle belirlenir. Bunların hepsi, oluşturulan son beğenilerin zaman damgası, oluşturulan beğenilerin sayısı, son yorum vb. etkileşim verileridir. Kullanıcı etkileşim davranışı, onların bir şeye olan ilgisinin göstergesidir.

   
   

2. Gönderinin platformdaki popülerliği: Bunu belirlemek için etkileşim, etkileşim-gösterim oranları, etkileşime giren benzersiz kullanıcı sayısı vb. gibi çeşitli faktörleri alarak bunun etkileşim puanını oluşturan bir algoritma oluşturduk. platform düzeyinde yayınlayın.

   
   

Bazı yayınlarda popülerliğe öncelik veriyoruz; diğerlerinde sosyal grafiğe öncelik veriyoruz. Ancak çoğunlukla hepsi bu ikisinin sağlıklı bir karışımıdır.

Sistem Nasıl Çalışır?

Yukarıdaki diyagramdan da görebileceğiniz gibi sistem bilinçli olarak çok basit tutulmuştur. Sistemin nasıl çalıştığı aşağıda açıklanmıştır -

1. A kullanıcısı bir gönderi oluşturduğunda, gönderi hizmeti, bu gönderiyi kaydettikten sonra aday oluşturmaya yönelik bir arka plan hizmeti tarafından alınan sıraya yönelik bir pub/sub etkinliğini tetikler. Kullanırız Google Pub/Sub pub/sub işlevi için.

   
   

2. Bu arka plan hizmeti bunu eşzamansız olarak alır ve daha önce tartışılan işlevleri (Gizlilik kontrolleri, denetleme kontrolleri ve anahtar kelime oluşturma) gerçekleştirir ve ardından vektör yerleştirmelerini oluşturur ve bunları vektör veritabanında saklar. Kullanıyoruz Vektör veritabanımız olarak AstraDB (Sonra tartışılacak).

   
   

3. Bir kullanıcı ana NoSQL veritabanımızı güncelledikten sonra etkileşimde bulunduğunda (beğen/yorum yap/paylaş vb.), hizmet sonrası, öneri motoru hizmetine bir pub/sub olayı tetikler.

   
   

4. Bu öneri motoru hizmeti, grafik veritabanını günceller ve ardından YSA araması gerçekleştirip Redis veritabanını güncelleyerek kullanıcının önerilen akışını neredeyse gerçek zamanlı olarak günceller. Yani, kullanıcılar ne kadar çok etkileşimde bulunursa yayın da o kadar iyi hale gelir. Önerilerin belirli bir anahtar kelime listesine yönelik önyargılı olmadığından emin olmak için kontroller vardır . Bu kontroller Graph veritabanını sorgularken gerçekleştirilir. Bu hizmet aynı zamanda etkileşim puanını eşzamansız olarak günceller. Gönderiyi görüntüleyen kullanıcıların etkileşim puanları da yeniden hesaplanır.

   
   

5. Yukarıdaki adımların tümü perde arkasında eşzamansız olarak gerçekleştirildiğinden, bu hesaplamaların son kullanıcı deneyimi üzerinde hiçbir etkisi yoktur.

   
   

6. Özet akışı son olarak bir özet akışı hizmeti aracılığıyla son kullanıcıya sunulur. Bu hizmet yalnızca redis ve ana NoSQL veritabanımızda arama yaptığından ( DyanmoDB ), P99 gecikmesi 110 milisaniyeden azdır. Bu veritabanlarının her ikisi de ölçeğe bakılmaksızın sorgu sonuçlarını milisaniyelik tek haneli gecikmeyle döndürür.

Kullanılan araçlar ve teknolojiler

1. Bazı hizmetler şu şekilde yazılmıştır: Programlama diline git , diğerleri yazılırken DüğümJS (daktilo ile).

   
   

2. Kullanıyoruz Datastax'tan AstraDB vektör veritabanımız olarak. Bu karara çam kozalağı, milvus ve dokuma gibi diğer birçok veri tabanını değerlendirdikten sonra ulaştık. Vektör ve diğer veri türlerinde mükemmel sorgulama ve indeksleme yeteneklerinin yanı sıra, cep dostu sunucusuz fiyatlandırma planı sunar. Platformumuzdaki diğer birçok özellikte veritabanı olarak kullandığımız Cassandra motorunun üzerinde çalışır ve geliştirici dostu olan bir CQL sorgu arayüzü sunar. Vektör kullanım durumlarınız için denemenizi şiddetle tavsiye ederim.

   
   

3. Kullanırız Google pub/sub Asenkron iletişimimiz için, çünkü mevcut ölçeğimizde (toplamda birkaç lakh kullanıcı, günlük birkaç bin aktif kullanıcı) oldukça uygun maliyetli. Saniyede binlerce olayla birkaç yüz bin kullanıcı ölçeğinde çalıştırdım. İyi çalışıyor ve kullanımı ve genişletilmesi zahmetsiz.

   
   

4. Redis - Hız, basitlik ve güçlü veri yapısı. 2024'te neden redis olduğunu tartışmama gerek yok sanırım.

   
   

5. DinamoDB - Yine son derece ölçeklenebilir ve kullanımı kolaydır ve dakika başına yüzbinlerce sorguya rağmen toplam faturamızın oldukça düşük olduğu sunucusuz modda çalıştırıyoruz. Ayrıca çok güçlü indeksleme yetenekleri ve okuma ve yazma işlemlerinde milisaniyelik tek haneli gecikme süresi sunar.

Gelecekte çözülmesi gereken sorunlar

Tahmin edebileceğiniz gibi, aynı kurulum herhangi bir kullanım durumu için temel bir öneri motoru oluşturmak üzere değiştirilebilir. Ancak bizimki bir sosyal ağ olduğundan, bu sistemi daha verimli hale getirmek için bazı değişiklikler yapmamız gerekecek.

1. Kullanıcıyla en alakalı anahtar kelimeleri ve kullanıcıları tahmin etmek için sosyal grafik düzeyinde makine öğrenimi/Derin öğrenme algoritmalarına ihtiyaç duyulacaktır. Şu anda veri seti çok yeni bir ürün olduğu için herhangi bir şeyi doğru bir şekilde tahmin etmek için çok küçük. Ancak veriler büyüdükçe mevcut basit sorguları ve formülleri makine öğrenmesi algoritmalarının çıktılarıyla değiştirmemiz gerekecek.

   
   

2. Çeşitli anahtar kelimeler ve kullanıcılar arasındaki ilişkilere ince ayar yapılmalı ve daha ayrıntılı hale getirilmelidir. Şu anda çok yüksek bir seviyedeler. Ancak daha derin olmaları gerekecek. Önce önerileri hassaslaştırmak için grafiğimizdeki ikinci ve üçüncü derece ilişkileri keşfetmemiz gerekecek.

   
   

3. Şu anda gömme modellerimizde herhangi bir ince ayar yapmıyoruz. Yakın gelecekte bunu yapmamız gerekecek.

Notu sonlandır

Umarım bu blogu faydalı bulmuşsunuzdur. Herhangi bir sorunuz, şüpheniz veya öneriniz varsa lütfen benimle iletişime geçmekten çekinmeyin. heyecan , LinkedIn veya instagram . Bu makaleyi arkadaşlarınızla ve iş arkadaşlarınızla paylaşın.