A city-scale list is not enough
The starting point is a messy list of restaurants and bars. The product idea is to turn that into a way to choose a night by intent instead of reading hundreds of lists.
671seed + saved rows
Active build / Tokyo
Tokyo Venue Vibe Planner
A working experiment for finding Tokyo restaurants and bars by intent: start from a messy list, enrich it, test embedding/clustering, then build a planner that can recommend one place or a route.
Model path
How I Iterated the Model.
This started as a simple idea: use a list of Tokyo restaurants and bars to recommend better nights out. The early clustering runs were useful, but they showed the wrong product shape. The current version keeps the useful part of the embedding work and moves the planner toward gates, profile dimensions, and feedback.
The first model shape was too blunt
Clustering helped show where venues were similar, but it mostly rediscovered obvious categories. The overlap mattered more than the cluster names.
10broad clusters
The planner has to separate rules from taste
A closed restaurant, wrong cuisine, or wrong venue type should not be rescued by a vibe score. The current version gates first and ranks second.
36profile dimensions
The next version needs feedback and better retrieval
The better long-term shape is retrieval, ranking, and feedback loops: find candidates, rerank them, collect labels, and improve the model only after enough repeated evidence.
10QA labels so far
Current model
Information About the Current Model.
What kind of model is this?
Right now it is a retrieval and ranking system. Embeddings create venue profile features, hard rules remove impossible matches, and a transparent ranker orders the survivors.
What it is not
It is not linear regression, logistic regression, K-means, or a live-learning model. There are no fitted coefficients yet. The current weights are product rules that we can audit.
What changed in this reset
Type, cuisine, and drink are now gates. Price is a soft fit. Data confidence is shown separately and is not added to the score. Open hours are not scored until real hours are loaded.
One example
How a request becomes a ranked recommendation
Request: Shibuya, route planning, French or bistro first stop, cocktail-focused second stop, quiet vinyl / old wood / low light.
The model first asks whether a venue is eligible, then asks how well it fits. Type, cuisine, drink intent, time of day, location, price, quality, walk-in likelihood, and the requested atmosphere all matter, but the first few are rules while the rest are evidence.
Dependencies
What information the ranker uses
Each venue record carries its location, place identity, price, cuisine and drink signals, walk-in estimate, and experience-dimension scores.
The planner applies the preferences a person selects in the browser, then explains why a result survived the filters.
Map links open the specific place when identity data is available and otherwise use the closest safe location.
Walkthrough
What happens in order
1. Gate: remove venues with the wrong role. For a route, the first stop cannot be bar-like and the second stop must be bar-like.
2. Gate: apply cuisine and drink intent. French applies to the first stop; cocktail focus applies to the second stop.
3. Rank: convert words like quiet, vinyl, old wood, and low light into atmosphere descriptors, then compare those descriptors against venue dimension scores.
4. Rank: add location, price fit, quality, and walk-in scores as soft evidence. Data confidence is shown separately so weak data does not secretly inflate the recommendation.
About the Data.
About the Data.
Prep
- seed candidates342
- saved Tokyo places329
- likely seed matches266
- likely saved matches130
- discovery holdouts83
- modeling venues471
Kitchen pass
Normalize → gate → rank1621 source signals, with evidence kept separate from preference scoring.Service
Ranked venue or two-stop routeEach result explains fit, score parts, confidence, and its Maps link.Data visualization
Clustering showed overlap; the planner now uses dimensions.
Japanese counter signal / Counter interaction / Reservation heavyCocktail craft / cocktail bar / After-dinner anchorNatural wine signal / French bistro signal / Coffee daytimecocktail bar / wine bar / italianCoffee daytime / Dessert or cafe stop / cafe coffeeizakaya / Japanese counter signal / japanese counterRamen or quick meal / Reservation heavy / Low-friction first stopGroup friendly / Reservation heavy / wine barCoffee daytime / cafe coffee / Reservation heavyCocktail craft / Reservation heavy / cocktail bar
The moving 3D view is a diagnostic projection, not the recommender. The important lesson is overlap: a good bar can be part listening room, part hidden entrance, part cocktail craft. That is why the planner uses multiple profile scores instead of one hard cluster.
Current planner
The current tool is intentionally smaller and stricter.
Planning tool / reset build
Hard gates first. Vibes only rank what survives.
This is not linear regression. It is a retrieval ranker: filters remove invalid venues, then a transparent scoring function ranks the remaining candidates.
Model typeRules + embedding-derived features + rankingConfidence is data quality, not an error term. Open hours will become a hard 0/1 gate when real hours are loaded.
01 / where
Map selection is paused until it is a real basemap, not a dot field.
03 / optional atmosphere
Leaving this blank means no vibe bias. These are loose atmosphere handles, not formal categories the user needs to understand.
eligible results after gates
atmosphere descriptors
top ranked match
data confidence only
Single-place results
Deathmatch in Hell75.1%
Shinjuku Golden Gai / bar / $
ranked without atmosphere biasExact Google place linkOpen in Google Mapsenne daikanyama74.6%
Shibuya / cafe / unknown
ranked without atmosphere biasExact Google place linkOpen in Google MapsFuglen Hanegi Kōen73.9%
Umegaoka / cafe_bar / $$
ranked without atmosphere biasExact Google place linkOpen in Google MapsAcid Coffee Tokyo73.7%
Tokyo / cafe / unknown
ranked without atmosphere biasExact Google place linkOpen in Google MapsSwig73.7%
Tokyo / bar / unknown
ranked without atmosphere biasExact Google place linkOpen in Google MapsSarutahiko Coffee Ebisu73.2%
Ebisu / cafe / $
ranked without atmosphere biasExact Google place linkOpen in Google MapsTIGHT73.1%
Tokyo / bar / PRICE_LEVEL_MODERATE
ranked without atmosphere biasExact Google place linkOpen in Google MapsSingle O Hamacho72.6%
Chuo / cafe / unknown
ranked without atmosphere biasExact Google place linkOpen in Google MapsTop result audit
What affected the rank
quality81%
walk-in66%
data confidence55%
Plain-English model
What kind of model is this?
It is a recommendation ranker, not a trained regression model. The embedding work creates venue profile features. The UI filters act as gates. The ranker then scores only the venues that survive.
type = hard gatecuisine = hard gatedrink = hard gateprice = soft fithours = future 0/1 gate
Descriptor bridge
How sensory words connect
No descriptors selected, so atmosphere is not part of the score.
Map feedback
How I Plan to Implement This Into the Tokyo Map After Getting Feedback From User Suggestions.
Two-stage recommender
Use embeddings to retrieve a candidate set, then use gates and feature scores to rank the shortlist. This is the direction that matches how recommendation systems are usually structured.
Query-to-venue embedding
Embed the user's plain-English request and compare it against venue profile documents. This should eventually replace hand-mapped atmosphere words.
Real availability gate
Google opening-hour periods should become a 0/1 eligibility check. If it is closed at the requested time, it should not be ranked.
Feedback dataset
Firebase should store accept/reject labels, selected reasons, venue ids, route ids, model version, and score parts so future training has clean examples.
Future iterations
Issues With the Model and Potential Solutions.
Incomplete operating data
Opening hours, reservations, and real-time availability are still uneven, so the system should continue withholding uncertain places instead of pretending they are ready.
Thin feedback history
A few reactions do not prove a preference. The next useful threshold is repeated accept or reject feedback across similar requests.
Language can be too broad
Words like quiet or lively can mean different things to different people. The model needs more examples tied to a specific plan, place, and outcome.
Map experience is separate today
The planner should eventually hand a reviewed shortlist into the Tokyo map, where people can inspect location, context, and alternatives before acting.
Experiment journal
Running log of model decisions.
Iteration 01
Gates before ranking
The planner stopped letting soft scores override hard user intent. Wrong type, wrong cuisine, or wrong route role now removes a place before taste enters the score.
Iteration 02
Fixed exact Maps export and model walkthrough
I carried Google place ids into the planner output and rewired the export links so a selected recommendation opens the actual place when Google data is available. I also added a short model walkthrough that shows one request moving through gates, ranking, confidence, and Maps export.
Iteration 03
Reframed the planner as a model exploration
I reorganized the page so the first section shows the path from source list to clustering failure to gated ranking. I also grouped small neighborhoods into broader Tokyo areas, expanded cuisine filters from the dataset, added exploration mode, and added a plain-English prompt bridge for atmosphere words.
Iteration 04
Reset planner scoring around hard gates
I paused the fake map picker and rebuilt the planner logic so type, cuisine, and drink act as hard eligibility gates before any atmosphere scoring happens. The page now explains the model as a retrieval and ranking system, not regression or clustering.
System map
How the APIs, database, local models, and Gemini runs connect.
Google Places
Venue identity, coordinates, types, ratings, price, reviews, and eventually opening-hour periods.
Local build scripts
Clean the source lists, merge likely matches, derive cuisine signals, tokenize review language, and generate planner JSON.
Gemini embeddings
Create venue profile vectors and later support plain-English query matching against those profiles.
Browser planner
Runs hard gates and transparent ranking locally in the page so the current result can be audited.
Firebase
Persists QA feedback over time. It should not change weights until enough repeated labels exist.
Google Maps export
Final action layer: open one place or export a route with multiple stops.