irhshafkat

Just a wrapper around the ChatGPT API that allows Q/A over arXiv preprints by retrieving passages + inserting them into the context window.

Author here, felt it might be of interest to the folks on here!

Author here, would love to get other people's thoughts on this.

Wrote this a few days back, would appreciate hearing other people's take on this

If there is more information in the embedding than the baseline Generator is extracting, then adding in Convolutions between the Transpose Convolution blocks will certainly add more parameters the model could use to learn that.

Since the question is about training speed though, in general, larger models require more data which requires more time to train, so you'd actually increase both your data requirements, and time required to train.

Thanks, glad to hear you enjoyed the article!

I'm currently working on applications in road safety, and have also recently taken up an interest in learning about interpretability and fairness in machine learning models (for instance, I really loved this paper: https://arxiv.org/abs/1711.11279 and am working on making an easily accessible implementation of it).

Another thing that caught my attention is how deep learning is being used to build new developer tools, such as models that read code and automatically generate comments.

There's just so much ground to cover, simply because deep learning is such a versatile, universally applicable method.

A good practice is, unless necessary (or intentional), your API shouldn't send back raw outputs from your model. i.e. if you're running a classifier, return back only top 5 predictions, if you're running face recognition, directly send back names.

All deep learning model outputs are by design differentiable, and anyone with access to the full output of your model can potentially reverse engineer it using model distillation.

If you're running a cloud service, it's pretty easy, just make sure your API sends back processed inputs.

If it's on device, things become a bit more involved, but ideally, the embeddings should be stored as encrypted files (and not directly loadable matrices), and only readable by a small part of your overall program, which sends back the name of the person after performing similarity match, to other parts of the program. Your entire program should not have access to the embedding.

1. While it's certainly hard to describe all security systems in general, a general rule of thumb is that any system performing similarity matching is going to be considerably more involved than an exact match.

If you want an exact match, like in storing passwords, all you need is to store a hash and throw the original away (and there's certainly more nuances to this, like salting, but the rough idea is this). When a user enters a password, run it through a hash function and see if the hashes match.

This isn't the case for similarity matching, which most face recognition systems use. You need to store the actual embedding, and not the hash, because two face embeddings of even the same person are unlikely to ever be exactly the same, just "close". If you hash even two nearby inputs, any standard hash function will map them as far apart as possible, destroying any sense of distance you'd have to compute the similarity between the stored embedding and the query embedding.

This extends to any method whose internal representations are designed to function based on similarity matches; you need to store the original.

2. Last time I checked, yeah :)

Author here, would love to answer any questions you might have about the article/methods used/deep learning in general