ChefsStack
Vektör tabanlı öneri motoruna sahip tarif platformu
- Rol
- Backend ve öneri motoru
- Dönem
- 2025 — 2026
- Durum
- Canlı
- Bağlantılar
- Siteye git ↗
Rakamlarla
<50ms<50ms - benzerlik sorgusu
1,000+1,000+ - etkileşim olayı işlendi
00 - elle yazılmış öneri kuralı
Genel bakış
Tarif ve öneri platformu. Öneriler elle yazılmış kurallara değil, vektör benzerliğine dayanıyor; kullanıcı etkileşimleri Kafka ve Redis üzerinden kişisel akışlara dönüşüyor.
- FastAPI + pgvector ile benzerlik sorguları 50ms'nin altında yanıtlanıyor.
- 1.000+ kullanıcı etkileşimi Kafka ve Redis üzerinden akıp kişisel akışlara ve canlı trend listelerine dönüşüyor.
- Veri alımı ve servis katmanı ayrık; yavaş bir model okumaları asla bekletmiyor.
01
Problem
Kural tabanlı öneri ('aynı kategoriden 5 tarif göster') hızla sıkıcılaşır ve her yeni kategori için yeni kural ister. Hedef, tariflerin anlamsal yakınlığına göre öneri yapan ve kullanıcı davranışıyla kendini güncelleyen bir motor kurmaktı.
02
Yaklaşım
Tarifler embedding'e dönüştürülüp PostgreSQL'de pgvector ile saklanıyor; benzerlik sorguları FastAPI üzerinden 50ms'nin altında dönüyor. Ayrı bir vektör veritabanı yerine pgvector seçtim: tek veritabanı, tek yedekleme, tek transaction sınırı.
Kullanıcı etkileşimleri (görüntüleme, kaydetme, pişirme) Kafka'ya olay olarak düşüyor. Bir tüketici bunları işleyip Redis'te kişisel akışları ve canlı trend listelerini güncelliyor.
Veri alımı ve servis katmanı tamamen ayrık: embedding üretimi yavaşlasa bile okuma yolu Redis ve pgvector'dan beslenmeye devam ediyor.
03
Mimari
- İstemci
- Web uygulaması
- API
- FastAPI
- Öneri servisi
- Olay akışı
- Kafka
- Etkileşim tüketicisi
- Veri
- PostgreSQL + pgvector
- Redis (akış · trend)
- Embedding işi
04
Kilit kararlar
- 01
Ayrı vektör veritabanı yerine pgvector
Bu ölçekte ayrı bir vektör deposu operasyonel yük getiriyor. pgvector ilişkisel veriyle aynı yerde duruyor; JOIN'ler ve transaction'lar doğal kalıyor.
- 02
Trend listelerini Redis'te önceden hesaplamak
Trendi her istekte hesaplamak yerine Kafka tüketicisi listeyi sürekli güncel tutuyor. Okuma tarafı sadece Redis'ten bir liste çekiyor.
Sonuç
Platform canlıda. 1.000'den fazla etkileşim olayı boru hattından geçti; öneriler kullanıcı davranışına göre anlık güncelleniyor.
Ne öğrendim
“Önerileri ve trend listelerini önceden hesaplayıp Redis'te tutmak, okuma yolunu basit ve hızlı tuttu. Gerçek zamanlı hissettiren sistemlerin büyük kısmı bu yaklaşıma dayanıyor.”
Benzer projeler
- Yapay zekâ / MLAçık kaynak
Mobile Price Classification
Donanım özelliklerinden telefon fiyat segmenti sınıflandırması
RAM, pil, ekran ve kamera gibi donanım özelliklerinden telefonun fiyat segmentini tahmin eden sınıflandırma çalışması; veri toplama betiği, Jupyter analizi ve konteynerize edilmiş tahmin servisi.
- Python
- Pandas
- Scikit-Learn
- Jupyter
- Docker
İncele - Yapay zekâ / MLAçık kaynak
Traffic Accident Severity Prediction
100.000+ kaza kaydıyla eğitilmiş rota riski tahmini
100.000+ geçmiş kaza kaydıyla eğitilmiş rota riski tahmini; %85+ doğrulukla gerçek zamanlı uyarı üretiyor. OpenRouteService ve hava durumu API'leriyle çalışıyor.
- 100K+
- kaza kaydı
- 85%+
- doğruluk
- Python
- Scikit-Learn
- XGBoost
- Pandas
- Flask
- React
İncele - Yapay zekâ / MLAçık kaynak
Appliances Energy Prediction
Akıllı ev enerji tüketimi için regresyon modelleri karşılaştırması
UCI veri setindeki 19.735 adet 10 dakikalık ölçümle ev aletlerinin enerji tüketimini tahmin eden çalışma. Random Forest, XGBoost, LightGBM ve doğrusal regresyon karşılaştırıldı; LightGBM R² ≈ 0.76 ile öne çıktı.
- 19.735
- ölçüm satırı
- 0.76
- R² (LightGBM)
- Python
- Pandas
- Scikit-Learn
- LightGBM
- XGBoost
- Jupyter
İncele