[HN Gopher] Launch HN: Pyq (YC W23) - Simple APIs to Popular AI ...
___________________________________________________________________
Launch HN: Pyq (YC W23) - Simple APIs to Popular AI Models
Hello HN! We're Emily and Aman, the cofounders of Pyq
(https://www.pyqai.com). We make it easy for developers to build
features powered by AI. We do this by identifying specific tasks
that AI can solve well and providing simple APIs that any developer
can start using straight from our website. 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 of traction due to the virality of ChatGPT
itself. Building the entire website took less than a day - we fine-
tuned an existing text classification model, deployed it on Pyq and
our partner integrated it with their front-end. It has been used
10,000+ times since then, and has been quite performant and
inexpensive. We have seen several other applications created in a
similar way using Pyq. These include document OCR apps, chatbots,
stock image generators and more. We have a prepaid, usage-based
pricing model. Every model has a "spot price" - the cost of 1
second of compute. This is available on each model's page in our
'Zoo.' If you deploy your own model, we will give you your initial
price manually and adjust it up or down over time depending on your
needs. We also provide $10 of free computing credit upon signup.
This is enough to experiment with all of our models and, for some
of them, enough to run a few hundred or even a thousand inferences.
We add more credits on an ad-hoc basis, so feel free to email us at
team[at]pyqai.com describing what you're working on and we'll do
our best to accommodate you! We are so excited to show this
product. Our hope is that it helps you bring a project to life,
finish that feature you've been working on, or just gives you ideas
for what to build next. Please weigh in and tell us what you think!
Author : araghuvanshi
Score : 65 points
Date : 2023-02-28 17:14 UTC (5 hours ago)
| ensemblehq wrote:
| Best of luck! This feels very much like Algorithmia and a
| previous startup that I built a few years back. The challenge I
| experienced is the model productionization process and
| accountabilities as opposed to the infrastructure. No amount of
| tech I built mattered even if models could be deployed in
| seconds. Mind you - I was focused on enterprise. The hard part
| with startups for me was finding technical folks who already
| "know" how to deploy a model and don't want to admit they needed
| a tool.
|
| 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!
| araghuvanshi wrote:
| Thank you! Totally hear you on the part about convincing people
| who know how to do it to use a tool. We've found that those
| folks respond well to the counterargument that they shouldn't
| have to do it, even if they know how to, unless it's mission
| critical for their application. And thank you for the advice
| and good wishes!
| justasking7000 wrote:
| OpenAI API is pretty easy to use. Where is the value add? Is this
| for developers? If so it's really not that difficult to use
| OpenAI and its increasingly getting easier as the models get
| better. I feel like you may be overstating the problem here.
|
| I can see the nocode angle though.
| emilypyqai wrote:
| Agreed that the OpenAI API is pretty easy to use. But to have a
| model perform a specific task involves more than just calling
| the API - you have to manage prompts, finite context windows,
| and integrations with other APIs.
|
| 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.
| code51 wrote:
| > you have to manage prompts, finite context windows, and
| integrations with other APIs.
|
| 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.
| emilypyqai wrote:
| Yeah super fair, agreed that general-purpose handling will
| rarely (if ever) beat a specifically dedicated team -
| anything specific and critical will still require custom
| work. That being said, we think that there are some
| straightforward applications that can be annoying to solve
| and are reasonably generalizable.
| wenbin wrote:
| Congrats on the launch!
|
| 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-...
| emilypyqai wrote:
| we are HUGELY grateful for those companies - would've taken us
| so much longer to get off the ground without them
| emilypyqai wrote:
| (great article too btw)
| nylonstrung wrote:
| How is this different from Eden ai
| alexandraj777 wrote:
| tbh, and this might seem like a minor detail, but I would point
| out that the new user flow to get started and try out models on
| pyq is very different from Eden AI. With Eden, I had to go
| through an entire sign-up flow and questionnaire, but with pyq
| I just go directly to one of the model pages like
| https://www.pyqai.com/zoo/models/14 and can try things out
| immediately.
|
| We'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!
| [deleted]
| emilypyqai wrote:
| We are fairly similar, but we provide model hosting, and also
| are focused on a more narrow band of AI tasks, including image
| generation for blogs, stock photos, and events.
| zainhoda wrote:
| Nice! One thing that would be a great add is a how to do "X" in
| library "Y" where Y is a post-2021 library that OpenAI doesn't
| know about yet. I'd love to be able to send my Python library
| code/documentation to it and have it generate code examples for
| specific use cases.
| emilypyqai wrote:
| Ooh yes that would be really cool - we experimented a bit with
| code generation, but found that it was a bit unreliable and
| fiddly since it required such precise prompting. Certainly
| something we'd like to expand into in the future, though
| apsurd wrote:
| related question from someone technical but not in ML:
|
| 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?
| araghuvanshi wrote:
| So I will admit that I don't know a lot about how elastic
| search works under the hood, but I can describe how ours does.
| Under the hood we use a large language model called BART which
| has 2 key benefits: 1. It has more "general knowledge", so it
| doesn't just search for semantic similarity between the text
| and tags you provide. This makes the tagging more accurate. 2.
| This model can be fine-tuned fairly easily for specific use-
| cases or on more recent datasets. For example, if you have your
| own taxonomy that you'd like to categorize certain text by -
| this is popular amongst advertisers who need to place ads on
| specific types of content, and e-commerce companies that need
| to categorize products on their site in an easily separable way
| - it's pretty straightforward to teach this model.
|
| 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.
| apsurd wrote:
| thanks, i've been conflicted between "go with what you know"
| and investing time to keep up with tech.
|
| 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.)
| araghuvanshi wrote:
| Of course, we're happy to help :) The pace of change,
| especially in AI right now, is pretty dizzying so I can
| certainly relate.
|
| 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!
| santiagobasulto wrote:
| Congrats on the launch! I'm glad you mentioned OCR. Why is it so
| hard to find accurate ML-powered OCR models? The only good one
| that I know is Google's Vision API.
| araghuvanshi wrote:
| Thank you! We've wondered the same. There are a few useful
| open-source models out there (doctr, TrOCR to name a couple)
| but our best guess is that it comes down to the relatively
| lower availability of good, public OCR datasets, especially for
| PDFs. A quick and dirty search on paperswithcode.com shows that
| there are 33 OCR datasets available, out of ~7800.
|
| 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.
| [deleted]
___________________________________________________________________
(page generated 2023-02-28 23:00 UTC)