SocialAI

The brief

Generative image models are great at “a photo of a person” and bad at “a photo of this person, dressed this way, in this style, for the 200th time this month.” Creators and D2C brands need consistency more than novelty.

SocialAI is the consistency layer.

How it’s built

• FastAPI + SQLModel for the API, async all the way down via asyncpg
• pgvector for face embeddings and style embeddings — co-located with the relational data, so queries like “give me the closest 5 outputs that match this face and this style” are one SQL statement
• Inngest (Python) for long-running generation jobs, retries, and cancellation
• HuggingFace + Lightning + Kaggle notebooks in a huggingface/, lightning/, kaggle/ layout — used for fine-tuning and offline experimentation, not at request time
• Next.js frontend for the creator dashboard, with streaming previews

Why pgvector instead of Qdrant or Pinecone

Two reasons. First, the relational + vector queries are tightly coupled here — every output has metadata, ownership, billing tier, and a face embedding, and we filter on all of them together. Joining a separate vector DB to Postgres on every query was untenable. Second, pgvector is genuinely good enough for this scale; we’re nowhere near the regime where a dedicated vector DB earns its operational complexity.

What I learned

• Identity consistency is a retrieval problem first, a generation problem second. Most of the quality improvement came from better embedding choices and reranking, not from better generators.
• Notebook-to-prod is a real pipeline, not an export. I treat the kaggle/ and lightning/ folders as the experimentation surface, with a clean handoff into the FastAPI service via SQLModel-backed checkpoints. Notebooks that “work” in isolation almost never work in production without that translation.

Private repo. Architecture and pipeline available for review under NDA.