Excellent product, congrats on the launch guys!
HN user
yoavz
http://yoavz.com
Correct, it's the inverse that requires disclosure by Youtube.
Still, I find it interesting. If you can't synthetically alter someone's performance to be "worse", is it OK that the NFL synthetically altered Alicia Key's performance to be "better"?
For a more consequential example, imagine Biden's marketing team "cleaning up" his speech after he has mumbled or trailed off a word, misleading the US public during an election year. Should that be disclosed?
I am not envious of the policy folks at Youtube who will have to parse out all the edge cases over the next few years. They are up against a nearly impossible task.
Most interesting example to me: "Digitally altering audio to make it sound as if a popular singer missed a note in their live performance".
This seems oddly specific to the inverse of what happened recently with Alicia Keys from the recent Superbowl. As Robert Komaniecki pointed out on X [1], Alicia Keys hit a "sour note" which was silently edited by the NFL to fix it.
[1] https://twitter.com/Komaniecki_R/status/1757074365102084464
This looks excellent.
In my opinion, these kinds of apps are the future of data science / data analyst work. Forget no-code, just enable these professionals to work in a single programming language that they're familar with and give them visualization superpowers. The Python ecosystem has https://www.streamlit.io/ and https://gradio.app/ now. R has https://shiny.rstudio.com/. I think we'll see more.
I love that fuzzy date search use-case, will try testing that out.
Pretty cool. The embedding similarity approach makes a lot of sense. I actually this project by experimenting with computing cosine similarities of sentence embeddings [1]. But I wasn't very impressed with out-of-the-box results, and I found it difficult to set a similarity threshold for a match. QA was the second try, and the pretrained models worked better out of the box. I'm wondering if I should revisit the embedding approach now...
Yep -- no calls to any API backend.
The extension feeds it context data in chunks (e.g. only one <p> element at a time). I could see TensorFlowJS BERT struggling with a single sequence of 87 KB -- have you tried breaking them up?
Thanks, really nice to hear :)
I just got access to GPT3! Have only played around with it for a few hours so far, but haven't gotten it to reliably summarize.
Nope, I've developed and hosted my own summarization API here. It does heavily rely on open-source machine learning libraries and research / datasets released by Facebook AI [1]
[1] https://ai.facebook.com/research/publications/bart-denoising...
https://readable.com/ is an interesting tool I came across in my research you might be interested in. It relies on the Flesch–Kincaid readability tests [1] and has found sustained usage.
Actually, now that I think about it... this might be a good source for bootstrapping further training data.
[1] https://en.wikipedia.org/wiki/Flesch%E2%80%93Kincaid_readabi...
Interesting take because there is a school of thought that comes to the opposite conclusion: emails should be more like text messages: http://five.sentenc.es/.
I think the most interesting part of this problem is the ambiguity in desired result. Emails are inherently unstructured text data, which results in conflict about how people want them to look like.
Yes, you are correct -- I linked to this research on the frontpage as a citation.
The original inspiration and example featured on the website was from a blog post on cold "welcome" email copy: https://www.gkogan.co/blog/increase-reply-rates/.
I'd love to test it on more marketing emails, or content marketing -- these seem to be the two applications with the most direct ROI.
Good looking out! Will fix that.
When I was researching this product area, I found a bunch of similar tools that summarized on the inbound side. I thought it would be more interesting to experiment on the outbound side as the main initial focus, which I haven't seen.
I do have a generic popup that you can to summarize any passage, so you could copy-paste some long passage (email, article) to piggy back on the functionality. But it isn't tightly integrated into the Gmail UI as of now.
Interesting. I have a different experience than you -- I often find myself writing an email that's way too long and trimming it down later.
For the design of this tool, it was important for me to "not get in the way" if you're already writing a short email. That's why I designed the widget so that it will only appear in your gmail window if you go over 100 words. It can serve solely as a "reminder" for the rare cases you might go over... almost like a training to help you form short email habits over time.
Author here.
If you're talking about https://www.gkogan.co/blog/increase-reply-rates/, this was a primary inspiration for this project -- I even stole the name ;)
Woops! Yep, Model Zoo is somewhat of an overloaded name.
Hey Dmitry!
Good to meet you -- I'm a big fan of DVC. In our implementation, we've taken the approach of conforming to the standards (typically open-source) set by the frameworks for serialization (for example https://www.tensorflow.org/guide/saved_model). In our API design, it was important to integrate at the framework level (e.g. a tf.keras.models.Model object) for our client libraries. If you're using one of the widely available frameworks that we support, this results in a simple API where the serialization / deserialization is more of an implementation detail. If you're using a custom or rarer ML framework with an unstandardized serialization format, an open-source approach might work better.
Hope that was helpful!
Yes, model metrics are monitored when deployed -- performance metrics are enabled by default, and feature / prediction monitoring depends on the framework you're using. You can take a look at an example here: https://app.modelzoo.dev/models/gpt2-twitter-vc?tab=metrics.
We do support deploying to a private AWS cloud in our private beta that we can help get you set up with. Azure is not yet supported for private deployments.
Thanks for taking a look.
1) GPU acceleration and AWS VPC deployments are only available in the private beta (free tier is hosted on our private infrastructure). Apply here and we can set up a meeting with you asap: https://modelzoo.typeform.com/to/Y8U9Lw.
2) We've started with TensorFlow and Hugging Face Transformers. We're currently working on scikit-learn and PyTorch support (via https://github.com/PyTorchLightning/pytorch-lightning). What kind of frameworks do you use?
Hey HN! Builder of Model Zoo here.
I've worked as a software engineer in machine learning for a few years, bringing models to production in a variety of areas. Although there exists an open-source ecosystem for deploying ML models, most of these tools are targeted towards infrastructure engineers -- Kubernetes, Docker, and web server frameworks. As a result, there exists a gap today between some of the data scientists and machine learning engineers that develop these models and the skills required to deploy them.
I built Model Zoo to address that gap. Deploy your model to an HTTP endpoint with a single line of code, from any Python environment. Plus, you get all the features you'll need from a production ML system for free (monitoring features / predictions, autoscaling, web interface for documentation).
Test it out with one of our quickstarts here for free. You can experiment with it in-browser via Google Colaboratory or in your own Python environment:
https://docs.modelzoo.dev/quickstart/tensorflow.html or https://docs.modelzoo.dev/quickstart/transformers.html
Does the price point of $2 for 30 minutes seem a little high to anyone? Ofo is 4x cheaper at $1/hour [1] in Seattle... even when taking into account the high COL in SF and the extra benefit of electric bike, this seems excessive. A uber pool with the express option can be $3-4 for a short bikeable ride, I think I'd rather default to that in a majority of cases.
[1] https://seattle.curbed.com/2017/8/15/16153622/ofo-bike-share...
OP here, you bring up some fair points and I wanted to respond.
Definitely agree with you that the result of these experiments and others similar to it so far have produced unstructured and unenjoyable music, when compared to human-level compositions. I also agree that you could achieve similar results by some rule-based system involving random walks through a musical scale, common chord progressions, etc.
However, to me what's exciting about this and similar projects is that the network is learning these rules on it's own. The whole point of machine learning is that we don't have to explicitly state or even understand the underlying structure or music theory, because the algorithm figures it out on it's own. And sure, right now, it is only learning structure that we can codify manually in rules. But who's to say that as neural network techniques become more advanced, they won't be able to learn more abstract concepts such as the overarching dramatic structure of a musical piece?
If a problem is NP-Hard, it does not mean it cannot be solved. Rather, it means it cannot be solved efficiently (in polynomial time). Most NPH problems, now including Mario and 3SAT, can be solved given the time and compute resources to do so.
It unbelievable to think about how much synchronization must have gone into this project for all the pieces to come together successfully. Just some more evidence that goes to show facebook has some of the best engineering teams in the world.