this post was submitted on 31 Oct 2023
1 points (100.0% liked)
Machine Learning
1 readers
1 users here now
Community Rules:
- Be nice. No offensive behavior, insults or attacks: we encourage a diverse community in which members feel safe and have a voice.
- Make your post clear and comprehensive: posts that lack insight or effort will be removed. (ex: questions which are easily googled)
- Beginner or career related questions go elsewhere. This community is focused in discussion of research and new projects that advance the state-of-the-art.
- Limit self-promotion. Comments and posts should be first and foremost about topics of interest to ML observers and practitioners. Limited self-promotion is tolerated, but the sub is not here as merely a source for free advertisement. Such posts will be removed at the discretion of the mods.
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
You can do this pretty seamlessly with hybrid versions of opensearch, combining traditional search queries with vector based embeddings. Vectorize your item descriptions and then turn your free form user queries into hybrid queries that you feed to open search. It’s possible to feed complex natural language queries like “find me some cheap crocs or sandals listed in the last 12 days” and ask an LLM to transform that into a JSON format valid opensearch query. Gpt4 can do this flawlessly if you also provide a JSON Schema that matches your open search index.
I did something very similar recently and I also wasted an enormous amount of time screwing around with haystack, llama index, langchain and the like. I highly recommend avoiding these things if you are trying to build anything custom or that needs to scale or that needs to go onsite.
These frameworks all provide a few nice basic app ideas, and then wrap a laundry list of dedicated vectordbs that I predict will disappear within 2 years. Beyond that they have huge Java like OOP implementation styles that make it a huge pain to hack around or prototype without providing the scalability you’d typically like to trade for that bloat. Plus since they try to treat all the backends the same and this ends up giving more powerful multimodal data stores like Postgres and opensearch short Schrift by not supporting their more useful and sophisticated hybrid search features.
I finally discarded all of it and just started over with an api backend implemented with fastapi and opensearch and oss embeddings.
I’m also wary of OpenAI - gpt4 is great but for this use case it’s best to treat it as a prototyping mechanism and then fine tune a llama2 variant to do the query wrangling. Otherwise it’s too slow, to unreliable (service wise) and way too expensive. There’s no advantage to using OpenAI embeddings.
My 2c. Sounds like a super fun project (at least if it goes like mine has).
thanks for sharing! good thing you found success with an API backend implemented with fastapi and opensearch. I'm also impressed by how well you handled the hybrid versions of opensearch but tbh, am curious what challenges did you encounter while integrating the hybrid versions of opensearch?🤔