Applied AI • Personalization platform
DeepFeed AI
A personalized knowledge-discovery platform combining content discovery, explainable ranking, feedback-driven user modeling, and agentic adaptation — designed to filter information overload into a user-specific feed.
GitHub repository ↗Role
Sole engineer
Stack
FastAPI · pgvector · Celery · Next.js
Observability
OpenTelemetry · Prometheus · Grafana
Status
Active development · CI green
FIG 01 — Discover → rank → interact → adapt
01 — Problem
A feed should optimize for the person, not just the source
Useful information is spread across many sources, but collecting more content does not automatically create more value. The platform needs to decide what is relevant to a specific user, explain why it surfaced an item, and change its behavior as that user's interests evolve.
DeepFeed combines ordinary software-engineering concerns — APIs, persistence, authentication, queues, failure handling, and observability — with recommendation logic and an adaptive agent layer.
02 — Architecture
Modular monolith at the center, asynchronous work around it
The important boundary is not “how many services exist”; it is which layer owns each responsibility and which direction dependencies are allowed to flow.
VIDEO — Architecture walkthrough: layers, boundaries, and how requests flow through the system
01 CLIENT
Next.js frontend
User-facing feed and research experience, kept separate from backend application logic.
02 API
FastAPI application
Health, auth, profile, feed, feedback/admin, agent, statistics, and metrics routes behind audit, rate-limit, and trace middleware.
03 APPLICATION
Use-case services
Coordinate auth, content, discovery, feed generation, feedback, profiles, ranking, and agent-driven adaptation.
04 DOMAIN
Models + interfaces
Business rules separated from database, queue, and external-provider implementations.
05 INFRASTRUCTURE
Persistence, queues, observability
PostgreSQL/pgvector, Redis, RabbitMQ/Celery, logging, metrics, and tracing.
06 AGENTIC ADAPTATION
Model → plan → reflect
Specialized agents update the user model, plan research, evaluate performance, and record AdaptationEvents.
03 — Platform flow
Discovery becomes a feedback-controlled system
User profile & interests
Explicit interests, profile depth, expertise, and later behavioral signals form the personalization context.
Research planning
ResearchPlanningAgent combines explicit interests with learned topic preferences and creates a persisted SearchPlan.
Discovery & processing
Discovery/content services ingest and process information before ranking and feed generation.
Ranking
RankingEngine scores candidate content and persists recommendations with explanation traces.
Feed interaction
Users generate behavioral signals through likes, bookmarks, ignores, dislikes, and reads.
Adaptation
UserModelingAgent and ReflectionAgent turn signals into evolving preferences and the next cycle.
04 — Ranking
Explainable weighted ranking instead of a single opaque score
The RankingEngine scores processed content with five explicit factors. Recommendations are persisted together with RecommendationTrace records containing the score breakdown, matched interests, weights, and explanation.
Formula
score = relevance×0.40 + credibility×0.20 + freshness×0.15 + novelty×0.15 + feedback×0.10
Relevance
40%
Credibility
20%
Freshness
15%
Novelty
15%
Feedback
10%
Freshness is implemented with exponential time decay. Credibility combines global source trust with personal source preference, while relevance considers both explicit interests and learned topic preferences.
05 — Agentic adaptation
Observe → Interpret → Decide → Act → Learn
The adaptation layer is not a generic “AI agent” label — the repository contains explicit UserModelingAgent, ResearchPlanningAgent, ReflectionAgent, and AdaptationEngine responsibilities, with adaptation decisions recorded as AdaptationEvents.
06 — Reliability
AI behavior sits inside ordinary operational controls
Trace IDs
TraceIDMiddleware attaches request-level identity so failures can be correlated across logs and responses.
Rate limiting
RateLimitMiddleware exists in the API middleware stack rather than relying only on deployment infrastructure.
Audit trail
AuditMiddleware records request activity while adaptation decisions are separately persisted as AdaptationEvents.
Global errors
Unhandled exceptions are converted into structured 500 responses containing a trace_id and stable error envelope.
07 — Engineering decisions
Keep the core platform as a modular monolith instead of splitting ordinary business functions into unnecessary microservices.
Move expensive/background work to event-driven processing with RabbitMQ and Celery rather than forcing every operation through synchronous request latency.
Persist recommendation traces so ranking can be explained and inspected rather than returning only a score.
Separate explicit interests from learned behavioral preferences so personalization can adapt without destroying the user-provided model.
Record agent decisions as AdaptationEvents so AI-driven changes have a durable reason, confidence, and before/after context.
Treat tracing, logging, rate limiting, auditability, and error envelopes as application concerns — not something added only after deployment.
05
Ranking factors, each traced
04
Agents in the adaptation loop
06
CI stages before Docker build
01
Dependency direction, enforced