Watch out with the array mode though, according to OpenAI docs it technically can return the results in any order and you must sort them by index to be sure you have the right associations. I’ve never seen them out of order in practice, but it’d be entirely in-character for them to suddenly change that sporadically and without warning, and now your entire vectordb may or may not be nondeterministically ruined.

I was involved in an attempt to do this kind of thing with CNN neural networks just around the time BERT came out that was mostly successful and actually we did great projects for companies in the beverages, telecom, aviation and consumer goods space.

It worked because it also had a conventional data-processing pipeline that revolved around JSON documents.

For (2) it seems a system like that should be able to generate a script in Python, a codesigned DSL or some other language to do the conversion.

One interesting thing about the product I worked on was that it functioned as a profiler by looking at one cell at a time, so if there is some field that has "Gruff Rhys" or "范冰冰" it could tell that was probably somebody's name, all the better if it can also see the field label is something like "Full Name" or "姓名". I'd contrast that to more conventional column-based profilers who might noticed that a certain field only has the values "true" and "false" throughout the whole column and would probably have some rule that would determine it was a boolean field.

One thing that system could do is recognize private data inside unstructured data. Where I work for instance we have

https://www.spirion.com/sensitive-data-discovery

which scans text and other files and it warns if it sees something like a lot of personal data, like an Excel spreadsheet full of names, addresses and phone numbers -- even if I just made them up as test data.

> returns a reusable data structure mapping input keys to output keys

IMO this use case is exactly what Copilot is for. Write a comment including one example each of input and output, and tab-complete in your language of choice to have it create a rewriter for you.

One benefit (and danger) is that it will look at the values, not just the keys, and also may generate arbitrary code that can e.g. adapt a firstName and lastName to a fullName. But that's why you have a human being triggering and auditing this for subtle bugs, and putting it through code review and source control, right?

Thanks for the suggestions! Will implement these. Caching is a great idea.

It's not using an LLM, it's just comparing embeddings (which are waaay cheaper)

My thinking as well.

This isn't using an LLM, it simply checks for similarity between keys using vector embeddings

> fastText is faster, cheaper and runs locally

the question is if quality will be acceptable

BTW Bag of words models were once considered ML not too long ago.

As is, it's not good for much beyond looking cool. (Maybe implementing Postel's Law for a json API, but I think that's considered bad taste these days.)

If instead of transforming a single object it would output a table of src_field->dst_field, it could potentially be a useful first pass in some ETL development.

The lazy part of my brain screams “use this instead of dealing properly with nested objects!” In a production setting I’d be worried about consistency from the base to result layers if based on LLM transpositioning.

Data import via customer self-service onboarding.

We do something very similar with embeddings in our product. Users import files that they have to match to a dynamically-defined target schema. The embedding matching provides suggested matches to the user that are generally very accurate, so they don't have to go through and manually match up "telephone" to "phone number" etc. It even works across languages.