CoolFace
Apppublic

kchen707/wedding-bundle-builder

sourceHugging Facemitupdated 5mo agoView on Hugging Face
0likes
App README

San Diego Wedding Bundle Builder

An AI-integrated wedding planning platform built around a 1,100+ vendor proprietary dataset for the San Diego market. Given a couple's profile (categories, vibe, budget, guest count, optional inspiration images, optional wedding date), the system returns a personalized bundle of top-pick + runner-up vendors per category, with evidence-grounded match explanations and a wedding-date-aware booking timeline.

This Space is the working prototype for our final project in the Spring 2026 AI in Business course.

Team: Kelsey Chen, Evan Dodes, Jose Visintini

How to use the demo

  1. 1.Get an OpenRouter API key. Free at openrouter.ai/keys. The key stays in your browser session and is never logged or stored server-side.
  2. 2.Paste it into the field at the top of the matcher tab. Optionally click "Test key" to verify it works.
  3. 3.Fill out your profile: vendor categories, free-text vibe description, optional inspiration images, budget range, guest count, optional wedding date.
  4. 4.Click "Build my wedding bundle." A progress bar tracks the pipeline through preference extraction, retrieval, reranking, and explanation generation. Total run time is roughly 30 to 90 seconds depending on the number of categories.
  5. 5.Switch to "Your Timeline" to see a personalized booking schedule and milestone-grouped checklist tied to your wedding date.

A typical run costs the user well under one cent in OpenRouter credits.

What the system does under the hood

The matcher implements a hybrid retrieval pipeline as defined in our F3 Technical Requirements document:

  1. 1.Conversational preference extraction. A vibe textbox is parsed into structured preferences via a constrained-output LLM call.
  2. 2.Vision-based style extraction. If the user uploads inspiration images, a vision model returns structured style descriptors (palette, setting, floral style) that merge into the search profile.
  3. 3.Hard constraint filtering. Budget, category, capacity, indoor/outdoor are deterministic filters applied before any semantic search.
  4. 4.Multi-query dense retrieval with RRF fusion. Three diverse query reformulations are embedded and fused via Reciprocal Rank Fusion against the vendor embedding store.
  5. 5.LLM cross-encoder reranking. The top fifteen candidates per category are scored 0 to 10 by an LLM rubric.
  6. 6.Match explanation generation. Each top pick gets a rubric-aligned explanation that must cite specific vendor attributes, with an automatic retry under a stricter prompt if the first attempt is too generic.
  7. 7.Wedding-date-aware timeline. Per-category lead-time math against the wedding date produces a booking schedule, plus template-based and LLM-personalized planning tasks.

Project files

  • —app.py is the Gradio interface and orchestrator
  • —matching.py is the RAG pipeline (preference extraction, hard filters, retrieval, reranking, explanations)
  • —style_extraction.py is the vision pipeline for inspiration images
  • —timeline.py is the booking timeline math, loading phrases, short-notice bias, and task generation
  • —data_loader.py loads the xlsx and the cached embeddings
  • —clients.py is the BYO-key client factory used by every LLM call
  • —config.py holds the model slugs and matching parameters
  • —data/ contains the vendor xlsx and the precomputed embedding cache
  • —scripts/build_embeddings.py is the one-time local script that generated the cache

Running locally

bash
git clone <this-space-url>
cd sd-wedding-bundle-builder
pip install -r requirements.txt
python app.py

The app launches at http://localhost:7860. You'll need to paste an OpenRouter key into the UI before clicking the build button.

Rebuilding the embedding cache

If the vendor dataset changes, the embedding cache needs to be regenerated. This is a one-time local script that costs roughly $0.06 per run:

bash
export OPENROUTER_API_KEY=sk-or-v1-...
python scripts/build_embeddings.py

The script writes to data/vendor_embeddings_<fingerprint>.pkl which then gets committed to the Space repo. The deployed app loads it at startup so users only pay for query embeddings and chat completions, never for vendor embedding.

Models used

All models are accessed through OpenRouter:

  • —Embeddings: openai/text-embedding-3-large (3072-dim)
  • —Chat / extraction / reranking: google/gemini-3.1-flash-lite-preview
  • —Explanation generation: anthropic/claude-sonnet-4-5 with fallback to the chat model
  • —Vision-based style extraction: google/gemini-3-flash

Course context and deliverables

This Space accompanies the full project submission package:

  • —F1 Project Proposal (revised)
  • —F2 Business Plan (revised)
  • —F3 Technical Requirements and Evaluation Plan (revised)
  • —F4 Video Presentation
  • —This working prototype

Privacy and cost notes

  • —API keys are read from the active Gradio session and held in thread-local storage. They are never written to disk or logged.
  • —Inspiration images are sent to the OpenRouter vision endpoint per the user's pasted key. They are not stored after the matcher run.
  • —The vendor dataset (SD_Wedding_Vendors_Combined.xlsx) was built using the Google Places API plus AI-powered enrichment and is checked into the repo for reproducibility.

Known limitations

  • —Free Spaces sleep after inactivity, so the first request after a quiet period may take roughly 30 to 60 seconds to wake the container before the matcher itself runs.
  • —The matcher makes 15 to 30 LLM calls per submission, depending on selected categories. Total wall time is dominated by the cross-encoder reranking step.
  • —The vendor dataset is current as of March 2026 and will grow stale over time. A freshness pipeline is part of the production roadmap, not the prototype.