You are 100% correct, and this is the central limitation. An LLM like ChatGPT, trained on general web text, is a terrible movie recommendation engine for exactly the reasons you state. Its knowledge is broad but shallow, skewed toward popular discourse, and it will happily confabulate titles.
Our approach with lumigo.tv is different by necessity, and it's a direct response to the problem you've nailed. We don't use an LLM for knowledge.
Here's the technical split:
The LLM is strictly a query translator. Its only job is to take your messy, natural language prompt ("a gloomy noir set in a rainy city") and convert it into a structured set of searchable tags, genres, and metadata filters. It is forbidden from generating or hallucinating movie titles, actors, or plots.
The recommendations come from a structured database. Those translated filters are executed against a traditional database of movies/shows (we've integrated with TMDB and similar sources). The results are ranked by existing metrics like popularity, rating, and release date. The LLM never invents a result; it can only return what exists in the connected data.
You're right that pure collaborative filtering (like Netflix's) has a massive data advantage for mainstream tastes. Where it falls short is for edge cases and specific intent. If you want "movies like the third act of Parasite," a collaborative filter has no vector for that. Our hypothesis is that a human can describe that intent, an LLM can map it to tags (e.g., "class tension," "thriller," "dark comedy"), and a database can find matches.
So, it's not AI vs. collaborative filtering. It's AI as a natural-language front-end to a traditional database. The AI handles the "what I want" translation; the database handles the "what exists" retrieval. This avoids the hallucination problem but still allows for queries that a "Because you watched..." algorithm could never process.
Does that distinction make sense? It's an attempt to use each tool for what it's best at.
Maybe it's just me, but I find it weird to ask for a movie with very detailed characteristics. What I care above all is watching a good movie rather than wasting my time on a bad movie. I have a long list of movies that I plan to watch because I expect them to be good. My mood decides in which order I watch them, that's all. That's why I prefer collaborative filtering: I want to find movies that I'll like, I don't care if the city is rainy or sunny.
I'm convinced that in the future (5 or 10 years from now) you'll ask the AI precisely what movie you want to watch and it'll generate it on the fly. If you don't like the direction the story takes, you'll ask it to rectify. It'll be the end of the cinema as we know it today. I'm not sure it's a future that excites me :(
Yes, it does make sense, and it's a very interesting approach. So if you ask "a gloomy noir set in a rainy city" it'll translate into TMDB Keywords? I doubt that the TMDB Keywords have that depth (yet a data problem). How do you translate "in a rainy city"?
This is a fantastic point, and you've hit on something fundamental that's been lost in the shift to on-demand: the joy of discovery through serendipity and low commitment.
You're describing the exploration/exploitation trade-off in a very concrete way. Algorithmic recommendations are pure exploitation (based on your known likes). Endless scrolling is a frustrating middle ground. But "channel surfing" or "flipping" was a form of low-stakes exploration. You weren't making a choice to invest 90 minutes; you were dipping in for 30 seconds. If it didn't grab you, there was zero cost to leaving, which is psychologically liberating and led to finding unexpected gems.
Netflix's "Play Something" button and "Shuffle Play" for shows like The Office are direct, if clumsy, acknowledgments of this need. But you're right, why not a live "80s Action" channel or an "A24 Indie" channel? The technical barrier is near-zero.
Our take at lumigo.tv is that the modern equivalent shouldn't be tied to a linear broadcast schedule. The core experience to replicate is the low-friction, zero-commitment sampling.
One experiment we're considering is a "Mood Stream": you pick a vibe ("Cult Classic," "Mind-Bending Sci-Fi," "90s Comfort"), and it starts a never-ending, autoplaying stream of trailers or key 2-minute scenes from films in that category. You lean back and "flip" with a pause button. If a clip hooks you, you click to see the full title and where to stream it. It’s on-demand channel surfing.
The UI challenge is huge—how do you make it feel effortless, not just another menu? But your comment validates that solving this might be more valuable than another slightly-better recommendation algorithm. Thanks for this; it’s a much clearer design goal than “better search.”
Your point is excellent and cuts to the core of what we're trying to explore. You're right, ‘mood' can be a fuzzy, high-friction starting point.
The hypothesis behind the prompt isn't that everyone consciously identifies a mood. It's more that "mood" is a useful shorthand for a complex set of preferences at a given moment. When you think, "I want something mindless and funny after that long meeting," that's a mood proxy. The goal of the open-ended prompt is to capture that full sentence, not just the one-word label.
You've identified the three major discovery engines that dominate today:
Social Proof ("What are folks talking about?")
Direct Recommendation ("What was recommended to me?")
Access & Friction ("What's on my services?").
These are powerful because they require zero cognitive effort from the user. You're reacting to signals. Our experiment is asking: what if you reversed the flow? What if you started with your own internal state—even if vaguely defined as "kinda sad" or "need distraction" and used a model to map that to a title? It's inherently more work, which is its biggest hurdle.
The interesting technical challenge is whether an LLM can act as a translator between your messy, human input ("just finished a complex project, brain fried, want visual spectacle not dialogue") and the structured metadata of a database (genres, pacing, tone, plot keywords). It's not about mood detection; it's about intent parsing.
A future iteration might not ask for a mood at all, but simply: "Tell me about your day." The model's job would then be to infer the desired escapism, catharsis, or reinforcement from the narrative. Would that feel more natural, or just more invasive?
We're early, and you've nailed the key tension. Does discovery work best when it's passive (social/algorithmic feeds) or active (intent-driven search)? The former is easy; the latter might be more satisfying if we can reduce the friction enough. Thanks for giving me a much better way to frame this.
I’ve been testing a platform called Lumigo.tv, and it made me rethink how recommendation systems could work if they started from human emotion instead of metadata.
The core idea is simple: instead of browsing genres or relying on collaborative filtering, you tell the system what kind of feeling you want from a movie or series — “calm but not boring,” “dark but with humor,” “nostalgic in a warm way,” etc. The AI tries to interpret the emotional structure of the request and map it to titles in its catalog. It’s surprisingly different from typing keywords into a traditional recommender; some of the results feel uncannily aligned with the vibe rather than the category.
The platform itself is a mix of a mood-based search engine, a personal tracking tool, and a place to build curated lists. It’s not trying to be a streaming service but more like an interface layer on top of the chaos of modern content libraries. The database seems broad enough to avoid the usual “small pool” problem, and the UI encourages exploration without overwhelming you.
What caught my attention wasn’t the AI gimmick, but the design philosophy behind it. Most discovery tools assume that past behavior predicts future taste. Lumigo leans into something more fluid: people watch according to context, mood, time of day, emotional bandwidth, even weather. Traditional systems don’t capture those signals well, and mood-driven search is an interesting attempt to fill that gap.
There are areas where the cracks show. Mood parsing is not an exact science. Some prompts land perfectly, others feel like they’re interpreted too literally. The quality of recommendations clearly depends on how rich the metadata is behind the scenes, and that’s a massive ongoing effort. It also raises the question of whether mood-labeling at scale becomes noisy or inconsistent over time.
Still, as a product experiment, it’s refreshing. It feels closer to how people actually talk about movies in real life (“I want something cozy tonight”) rather than how platforms expect us to search (“Comedy → Subgenre → Runtime”). Whether systems like this become a serious alternative to more conventional recommenders is unclear, but it’s one of the first attempts I’ve seen that treats discovery as something emotional rather than purely statistical.
If nothing else, it’s an intriguing example of how a simple shift in the input paradigm can completely change the feeling of interacting with a huge content database.
You're absolutely right that existing standards like sitemap.xml + Accept headers could work in theory, but here's why we built this for eCommerce specifically:
The HTML-to-Markdown Problem
Even with Accept: text/markdown, most eCommerce sites will return HTML (then converted server-side). This means:
Scripts/popups in <div> hell ("Subscribe to newsletter!" embedded in product specs)
Ad fragments ("Customers also bought...") polluting context windows
Layout cruft (header/footer markup in every response)
llms.txt files are handcrafted Markdown – no noise, just atomic product data.
Control Over Exposure
Retailers want to:
Expose only approved fields (e.g., hide "Compare at $X" prices)
Come on, this is clearly copy-pasted from chatgpt. You can plainly see where the headings and bullet points were. And it's just rehashing the benefits of markdown, anyway, which isn't relevant. Did you even bother to read this slop?
> Accept: text/markdown, most eCommerce sites will return HTML
Which means the site doesn't have markdown. So, add it? There are plenty of ways to tackle this, even if you can't modify the server code.
> Generating Markdown per-request via Accept headers is expensive
No one's saying the markdown can't be pre-rendered.
> Pre-rendered llms.txt files can be CDN-cached
Every CDN I've used has a way to vary by Accept. You can even have it redirect to a different url, or use a <link> tag that points to a markdown file. Which might even be called "llms.txt", who knows, who cares. That's the beauty of the existing standards: they're flexible.
Good god. I'm not going to debate against an AI, so don't bother generating a reply.
A year ago, I bought a ‘top-rated’ DSLR camera based on Google’s first-page results. It turned out to be a refurbished model sold as new. That frustration led to Lumigo (https://lumigo.ai), an AI search engine that:
Bans all ads/sponsored results
Explains every recommendation (sources: blogs, Reddit, expert reviews)
Flags price gouging with historical data
We’re launching on Product Hunt tomorrow, but HN gets the first look because:
The ranking algorithm is open for critique (hybrid AI)
We need brutal feedback on the ‘why we recommend’ UI
I’ll share failed approaches in the comments (like our disastrous first crawl of Amazon reviews)
Question for HN: What’s your ‘never again’ product search horror story?
BONUS: If you like the product, join the product waiting list to upvote tomorrow
First-page Google results being 80% ads
Amazon reviews gaming the system
No transparency in recommendations
So I built Lumigo Lumigo that:
Only shows merit-based results
Cites all sources (blogs/forums/reviews)
Never takes ad money for products results
Questions for HN:
Would you actually switch from Google for product search?
What killer feature would make it indispensable?
How much do you care about seeing 'why' something is recommended?
Bonus Q: What's your worst product search horror story?
Hi HN,
I’ve been working on Lumigo, an AI-powered search engine designed to fix the mess of online product search. No ads, no fake reviews—just honest, transparent recommendations based on real data.
We’re launching soon on Product Hunt, and I’d love your support! If you’re tired of sponsored results and endless scrolling on google and others search engines, join the waiting list.
Your feedback and support mean a lot. Let’s make product search better, together!
thanks for your pov! The product I'm working on is https://lumigo.ai/ - an AI product search engine that aims to solve the inefficiencies in terms of product search of the search engines currently on the market. Realising that searching for a product on Google (or other competitors) has become tedious due to the uninteresting results and the dozens of sponsored products at the top of the list, we decided to create an AI capable of selecting data from various sources to represent the most suitable products for the prompt entered within seconds.
Well that's nice - a service that can recognise for example that if someone is looking for a brochure or parts list or operators manual for a product, saves the user time, instead of showing the other 100 items that are not wasting the user's time.
I had a look but I can't comment how good it is - which is where launching a site or web service becomes tricky. IMO, the site needs a fall back keyboard key to launch the query to get around a non functional script (for sending off the query.) I am probably the one in a thousand user who has an extensive deny list, which includes a handful of api services. No doubt it works ok for those who have the latest systems and a phone model that's only just been released.
Many years ago there used to be services that offered virtual browser / environments so developers could test as much as they could themselves but with the advent of smart phones made it just a bit too hard offer a comprehensive range.
I'll first point out I'm a one in a thousand user and not a good representative of the users that will frequent your site - I have denied a few (I have deemed dodgy) sites that provide API services.
So for your site, imagine using google search bar, one is able to type in the query but when hitting the spy glass icon nothing happens. Nor does hitting the return key do a thing - but in your instance you have a text box so the return key just enters a new line in that box.
The behaviour of the launch icon [which I gather on your site would be the up arrow in a circular button] not working is not unique to your site, I experience this often enough, and no doubt I have blocked the host of one of the APIs used to build the gui instance to return the query data.
Our approach with lumigo.tv is different by necessity, and it's a direct response to the problem you've nailed. We don't use an LLM for knowledge.
Here's the technical split:
The LLM is strictly a query translator. Its only job is to take your messy, natural language prompt ("a gloomy noir set in a rainy city") and convert it into a structured set of searchable tags, genres, and metadata filters. It is forbidden from generating or hallucinating movie titles, actors, or plots. The recommendations come from a structured database. Those translated filters are executed against a traditional database of movies/shows (we've integrated with TMDB and similar sources). The results are ranked by existing metrics like popularity, rating, and release date. The LLM never invents a result; it can only return what exists in the connected data. You're right that pure collaborative filtering (like Netflix's) has a massive data advantage for mainstream tastes. Where it falls short is for edge cases and specific intent. If you want "movies like the third act of Parasite," a collaborative filter has no vector for that. Our hypothesis is that a human can describe that intent, an LLM can map it to tags (e.g., "class tension," "thriller," "dark comedy"), and a database can find matches.
So, it's not AI vs. collaborative filtering. It's AI as a natural-language front-end to a traditional database. The AI handles the "what I want" translation; the database handles the "what exists" retrieval. This avoids the hallucination problem but still allows for queries that a "Because you watched..." algorithm could never process.
Does that distinction make sense? It's an attempt to use each tool for what it's best at.