Launch HN: Metal (YC W23) – Embeddings as a Service
If you’re unfamiliar with embeddings, they are representations of real world data expressed as a vector, where the position of the vector can be compared to other vectors – thereby deriving meaning from the data. They can be used to create things like semantic search, recommender systems, clustering analysis, classification, and more.
Working at companies like Datadog, Meta, and Spotify, we found it frustrating to build ML apps. Lack of tooling, infrastructure, and proper abstraction made working with ML tedious and slow. To get features out the door we’ve had to build data ingestion pipelines from scratch, manually maintain live customer datasets, build observability to measure drift, manage no-downtime deployments, and the list goes on. It took months to get simple features in front of users and the developer experience was terrible.
OpenAI, Hugging Face and others have brought models to the masses, but the developer experience still needs to be improved. To actually use embeddings, hitting APIs like OpenAI is just one piece of the puzzle. You also need to figure out storage, create indexes, maintain data quality through fine-tuning, manage versions, code operations on top of your data, and create APIs to consume it. All of this friction makes it a pain to ship live applications.
Metal solves these problems by providing an end-to-end platform for embeddings. Here’s how it works:
Data In: You send data to our system via our SDK or API. Data can be text, images, PDFs, or raw embeddings. When data hits our pipeline we preprocess by extracting the text from documents and chunking when necessary. We then generate embeddings using the selected model. If the index has fine-tuning transformation, we transform the embedding into the new vector space so it matches the target data. We then store the embeddings in cold storage for any needed async jobs.
From there we index the embeddings for querying. We use HSNW right now, but are planning to support FLAT indexes as well. We currently index in Redis, but plan to make this configurable and provide more options for datastores.
Data Out: We provide querying endpoints to hit the indexes, finding the ANN. For fine-tuned indexes, we generate embeddings from the base model used and then transform the embedding into the new vector space during the pre-query phase.
Additionally, we provide methods to run clustering jobs on the stored embeddings and visualizations in the UI. We are experimenting with zero-shot classification, by embedding the classes and matching to each embedding in the closest class, allowing us to provide a “classify” method in our SDK. We would love feedback on what other async job types would be useful!
Examples of what users have built so far include embedding product catalogs for improved similarity search, personalized in-app messaging with user behavior clusters, and similarity search on images for content creators.
Metal has a free tier that anyone can use, a developer tier for $20/month, and an enterprise tier with custom pricing. We’re currently building an open source product that will be released soon.
Most importantly, we’re sharing Metal with the HN community because we want to build the best developer experience possible, and the only metric we care about is live apps on prod. We’d love to hear your feedback, experiences with embeddings, and your ideas for how we can improve the product. Looking forward to your comments, thank you!
100 comments
[ 13.3 ms ] story [ 2984 ms ] threadI'm curious, does Metal's version support do anything to solve the problem of "I originally embedded with model A, but now I'd like to take my same data and re-embed with a new model B"? I've heard from others this is a pain point and I've experienced it myself - it feels like there would be some value in storing the embeddings' source data in the cloud to one-click re-embed as well.
How many of these new AI companies will stick?
Just took a look at your docs and product page as well. Keep up the great work!
Metal looks awesome. I've been comparing vector db solutions so your simple/abstracted sdk looks awesome. One thing I'd mention is with a solution like this that could be so critical to an apps functionality (and therefore so integrated into various parts of the app) I'd love to see that your team is vowing to give some sort of opensource self-hosted option. I want to root for any startup that is letting devs move faster in this area but there's a fear of committing to a solution that may pivot or be acquired/discontinued. Maybe even vowing a "safe-exit" for customers like I think rethinkdb did.
Good luck, looks awesome!
https://lucene.apache.org/core/9_4_2/demo/index.html
Do you have this product A and what the price?
which means need to get the latest price and quantity_available field.
Is this possible to do with Metal?
I'd hoped that proper product naming, and avoiding such minefields, be one of the things someone from YC or YC network would help/advise or at least give input on.
However, in some cases it can indeed be an issue when there is potential conflict with some very litigious companies.
Edit: I have no idea if it will be an issue in this case or not, but given Apple and similar domain (AI/ML), it may be an issue.
I forget the details so I can’t Google it, but twenty years ago there was a case where a Mac developer had a name collision with an Apple product, emailed Steve Jobs, and he replied with “No big deal, change the name.” — the little guy was expected to bear the burden of coming up with a new brand, but Jobs was (in his own view) kind enough not to sue.
I use code names for projects like that but I would never name a company something I couldn’t get the the domain for without some prefix attached.
https://huggingface.co/spaces/mteb/leaderboard
I get the benefit over Pinecone (which wasn't built with LLMs, etc in mind)
How does this compare to Chroma? Feels like it has most of what you're talking about, and already has an open source product live.
https://www.trychroma.com/
It's easy enough to define a docker compose file, and deploy it to my environments.
You can run it on your laptop and it's free.
What do you mean?
Pinecone was specifically made to be used alongside LLMs and other embedding models. That’s how anyone uses Pinecone.
Thanks!
I am yet to completely explore your website, but do you by any chance let me export the generated embeddings to manage them using say Pinecone?
Also, any chance you guys plan to integrate OCR tools in your pipeline? Say I have images of text, which I know is text and don’t want to use a inage model for generating embeddings.
Clustering with sci kit-learn is… easy. Indexing in FAISS is… easy. Maybe it’s hard if you use Rust and it was hard to do this in Pythoh 5 years ago. Dilbert’s Boss probably thinks it is hard but he got fired…
and its a >$100mm/yr business :) things always get messy when you scale things up beyond a demo on one laptop
Few questions/thoughts: - What kind of overheads do you have right now with calling this API?
- What scales have you pressure-tested this with? Demo seems to show few 100s of embeddings. Selfishly, I'd like to see a demo of handling 10M+ vectors to be reasonably certain that any company can truly build infrastructure in this context. I guess I'm more interested in the out-of-core applications where I can really shove all my data in here, and see if the system can handle it.
- (dovetails with the previous one): What kind of access patterns are you seeing today, more indie developers pushing few 1000s of vectors into a DB or some heavy users pushing 100K-1M+ vectors.
- Less of a question, but one thought would be to partner with labeling companies to automatically fine-tune embeddings as part of a single embeddings-management platform.
- Would you eventually look to build your own vector DB + metadata / features stores as part of the long-term strategy or try to integrate with existing ones?
- As a managed service there are some overheads. We need to auth, validate and parse the inputs, fetch the index that is getting queried as we then need to use the index’s model to generate the embeddings. Then if the index is fine tuned/customized, we need to transform the embedding to the new vector space, to then call our vector index. We then fetch the metadata of the results from the db and parse the response to send it back.
- We’ve only tested upwards of 1M vectors ~ 1500 dimensions. But, more formal testing is required here and we plan to do so. I’m particularly curious about pg_vector and how it stacks up with other players as keeping the data central is a significant upside. We started with these lower vector indices to get something out there and iterate as a startup. But, scalability is part of what we want long term.
- We see both; we’ve had to turn down a very early lead with 100M+ vectors because it would derail other engineering efforts while we were starting. We’re now much better positioned to tackle that challenge as we have all the foundations.
- We haven’t considered this, but it’s an excellent idea. We’re currently discussing this with the team.
We would love to chat more; we appreciate your questions and feedback. Always happy to riff with someone who has seen issues around these use cases, like yourself. Feel free to reach us at founders@getmetal.io !
- I have a good sense of the overheads - I was more curious about the latencies (ms) you are observing with the system today.
- Out of curiosity, why did you pick Redis? Is it mostly due to familiarity and experience with it in the past? I'm curious if you foresee any challenges scaling to larger datasets due to the in-memory limitations.
- I'm assuming you're going with a usage-based model for large volumes of data managed? Do you support spinning down the service (moving things to cold-storage), and auto-scaling things back up when users actually search for things. Wondering how you're thinking about this especially if customers don't use the APIs daily.
- For the 100M+ vectors, what type of data were they dealing with, documents, images or something else?
Thanks!