Launch HN: Pyq (YC W23) – Simple APIs to Popular AI Models
We built Pyq because it took too long to build features that were powered by AI at our previous jobs. A lot of people want to get started using AI, but struggle because of the difficulties involved in managing infrastructure, finding the right model and learning how to call it. There are many interesting and useful models in places like Github or Hugging Face, as well as specific applications of popular models like OpenAI’s GPT, but they require a decent amount of work/knowledge to get working in your app.
The first issue is determining if and how your problem can be solved with AI. This generally involves experimenting with different models and (more recently) prompts, followed by potentially fine-tuning your model, at which point you’ll have to repeat this process with datasets. Then you move onto the set of challenges posed by getting that model deployed in production, including messing around with Docker, cloud infrastructure etc. This process can take weeks or even months. We aim to make it easy to match a problem to an AI solution and get it working in your application quickly.
Aman was leading a product team at a startup and was told that an already-built AI model would take an additional 3 weeks to bring to production. The only solution was to hire an engineer to do this and potentially pay for an enterprise MLOps platform on top of that. Simultaneously, Emily at Microsoft found herself asking the Azure team directly for help to hook up a model into the HoloLens application she was working on. The ensuing frustration resulted in our first principle: bringing an AI model to production should take minutes, not weeks!
Infrastructure is only one part of the problem. With all of the new possibilities afforded by modern AI models, it can be difficult to understand what business applications they can be used for. We decided to apply our knowledge of building AI-powered products to finding practical use cases that are easy for any developer to understand, even if they don’t have any AI knowledge.
We identify use cases of various AI models and provide straightforward APIs tailored to those use cases. We use both open-source models and popular providers such as OpenAI. This allows for easy and fast integration into apps. Rather than starting with the model, experimenting to see if it can actually do what you want it to, learning about deployment and serving, developers can just make a POST call to start using AI.
We serve our models with FastAPI, containerize them, and then deploy them to our GKE clusters. Depending on the model, we choose different machines - some require GPUs, most are decent on CPU. We take models up or down based on usage, so we have cold starts unless otherwise specified by customers. We expose access to the model via a POST call through our cloud app. We track inputs and outputs, as we expect that people will become interested in fine tuning models based on their past usage.
Pyq is not meant for AI experts or specialists, but for people who are building features which are powered by AI. We have a curated list of models that are good at specific tasks and are inexpensive to use. Some have been used thousands of times already!
Deploying your own model with us is also a very straightforward process and can usually be done within an hour. For those requiring low latency and high volume, we also offer a high performance API at additional cost.
Shortly after the launch of Chat GPT, we created a GPT Detector (https://www.gpt-detector.com, also available via API through our website) in collaboration with another YC company. This got a surprising amount o...
26 comments
[ 50.4 ms ] story [ 1050 ms ] threadWe're all still discovering use cases for these really popular models, so as a potential user the attention to detail on the discovery and try-out experience matters a lot to me.
It's also just plain fun!
I can see the nocode angle though.
We use GPT under the hood for our website summarizer for example, which involved connecting the OpenAI API to a web scraper and then handling cases where the website had more text than GPT can handle. Finally we also experimented with a bunch of prompts to make sure that it responds based on the user's needs.
For many non-straightforward tasks, a dev doubts somebody else handles these problems with care. Who can guarantee that a general-purpose handling of these could be better than the specific team that aims to solve the problem?
Finite context windows are, for many complex tasks, are still a problem unsolved, only heuristics applied. You basically manage injection of cues when you hit that finite context limit. However it's not guaranteed that you'll select good cues.
Handling prompts with a vector db is still not the same thing for serving long contexts. Details of how that vector db is built in the first place can also be critical to the solution.
for the text tagging example, is the underlying approach same or different to elasticsearch term analyzing and scoring?
can anyone help with pros and cons?
context: given a customer chat for returning a product, the text scores terms like "return", "refund", "exhange" for relevance. also makes think how to handle synonyms?
The synonyms question is a good one - so far, we've found that adding them here isn't really necessary as they'll all present similar scores.
your value prop is a nice hedge in that i can try it out and play with results without much any investment, thanks!
(long winded added context: im interested in classifying recipes into useful taxonomies. ex: "sweet potato" -> vegetables, root-vegetables, potato family, flavor: sweet, etc. still exploring, my goal is to recommend ingredient substitutions in an intuitive way. like "other potatoes" yes, but it's because it's starchy with a particular flavor profile etc.)
That's a super interesting use case. I'm curious to see if the model can achieve that out of the box or if it'll need to be fine tuned. Please keep us updated!
For a recent enterprise client, developers deploying models is just a non-starter. My advice is to talk to as many customers as you can, hone in on businesses where rapid model deployment is an absolute necessity and double down on them.
Good luck!
Can you explain more of what you mean by this? Were developers sufficiently comfortable they completely brushed off the suggestion of needing a tool or did the enterprise already have tooling in place?
That said we've seen people have success with the ones I mentioned working out of the box, and I know of two folks who've fine-tuned a model to do what they need.
btw - It's great to see the use of various 3rd tools to launch an API business:
- auth0-hosted page for login
- stripe-hosted checkout page for billing
- metabase for user dashboard (e.g., api usage stats)
- gitbook for api docs
We used to build these things from ground up ourselves [1] :)
[1] https://www.listennotes.com/blog/how-i-accidentally-built-a-...