No-code workflows for vector search

Re:No-code workflows for vector search by FridgeSeal on Wednesday January 19, 2022 @05:43PM (#30001500)

Not specific to this project, but why are so many ML-adjacent tools/services so tightly integrated with Python? It feels like the equivalent of going “write a bunch of C to use Postgres”. We have a code base consisting of a bunch of different languages, and given the option, nobody on the team wants to write any more Python if we don’t have to, but so many projects seem to have functionality or internals that are inextricably linked to operating with your code, inside a Python runtime.

[ Parent | on HN ]

Re:No-code workflows for vector search by p1esk on Wednesday January 19, 2022 @07:12PM (#30002391)

Because there are no good reasons not to use Python if you want to do ML, and also there's simply no strong contender to Python in ML field. Maybe Julia, but it will need a lot more effort to gain critical mass.

[ Parent | on HN ]

Re:No-code workflows for vector search by FridgeSeal on Friday January 21, 2022 @08:05PM (#30032036)

For training models, sure.

But I want to serve them, and run things like Vector search engines, and I don’t see a reasonable justification as to why we need to be chained to Python at that point as well.

[ Parent | on HN ]

Re:No-code workflows for vector search by neumll on Wednesday January 19, 2022 @06:06PM (#30001768)

One reason is that the most popular models were developed using either the TensorFlow or PyTorch Python APIs. The pre-trained models took an immense amounts of compute resources to build. Additionally, those who built the models weren't necessarily developers and Python is an low-barrier to entry language.

There are a number of models that are now available via APIs and can be used from any language.

[ Parent | on HN ]

Re:No-code workflows for vector search by FridgeSeal on Wednesday January 19, 2022 @06:46PM (#30002151)

> The pre-trained models took an immense amounts of compute resources to build.

Oh definitely, but nobody is serving models from the same machine + process that they used to train them right? And solutions like ONNX exist (although TF and PyTorch’s support is inconsistent at best)

Additionally, those who built the models weren't necessarily developers and Python is an low-barrier to entry language.

It just feels like an engineering anti-pattern to build “down” to this level, instead of skilling people up, or standardising on some standard model serialisation and serving format, model serving tools exist, and they’re often written in faster/more optimised languages, so at that point, why bother with Python after actual model training at all.

[ Parent | on HN ]

Re:No-code workflows for vector search by neumll on Wednesday January 19, 2022 @06:52PM (#30002208)

True, if a team doesn't want to use Python, the way models were trained shouldn't be the reason to use Python. ONNX is a good option, txtai has a notebook that shows how to export models for use in Rust/JavaScript/Java - https://github.com/neuml/txtai/blob/master/examples/18_Expor...

Seems like a lot of tooling is being created in other languages besides Python, may just take some time to get there.

[ Parent | on HN ]