nmachado

We actually leverage LLMs very sparingly. We do not generate the transformed data directly as this would not just introduce significant latency, but also quality and reliability issues. Rather, we use LLMs to produce high-level mapping/transformation logic in a language of our design that is deterministically executed to produce your desired data. So this means LLMs are used only when you introduce new data formats that requires new logic, and used surgically even then. The vast majority of usage so far in terms of volume leverages the logic created in the underlying pipeline and will not have latency issues. This also allows for building reliable and stable pipelines with our APIs, which is a requirement that's difficult to meet considering the non-determinism of LLMs.

We haven't had bandwidth to run it on this example yet, but will report back when we do!

Sounds very useful, thank you for sharing.

Customers can use Lume to do one-off mappings along with recurring mappings. As seen in the demo video, you can create a mapping between any source and target schema. So, the workflow of using Lume is the same for both one-off and recurring cases. Was this what you were referring to?

Our customers have a recurring need to map data and use those mappings, such as onboarding client, normalizing data from multiple systems, or build and maintain data pipelines. All of them have the common denominator of continually having to map and maintain these mappers (e.g. n clients). You can learn more here https://www.lume.ai/use-cases. Of course, if we may be of help, reach out to nicolas@lume.ai

Thank you!

wow! It's a pleasure, qarl :) Reach out anytime.

They are written in python but SQL is in the roadmap.

Great question. We focus on embedding in your data pipelines themselves. So, our AI automatically maps data, and can be used as a data pipeline indefinitely. Indeed, it can connect to APIs and handle dynamic output or edge cases you did not expect. Also, we work on handling any complexity of transformations (1-1 mappings, all the way to string manipulation, classification, aggregrations, etc).

Thank you for shouting this out! I'll look into getting a smaller version in there.

Right Lume is a low to no code tool (see demo), but we have gotten requests for an SDK. Creating a library / SDK is in our radar! If anyone has personal or company use cases for a library / SDK, please email founders@lume.ai, we'd love to learn more.

Gotcha! In that case, we do not yet support an end-to-end experience for this, but would be willing to prioritize building it for clients if we get strong demand.

This would be a concern if we are feeding the raw user input and feed it directly into an LLM. In our case, we are not simply a wrapper over an LLM.

There are multiple parsing and rule-based steps done to the input schemas - we extract specific pieces from the schemas and convert them to our internal format before feeding it our models. Thus, it mitigates such malicious behavior.

Another user asked this about other IPaaS’, such as Workato. This is our response: https://news.ycombinator.com/item?id=35238714

In short, Lume can be used for the same use cases as Zapier. However, Zapier focuses on and supports the most common trigger integrations and offer them as an automation service. For most custom integrations, users still have to write custom code within these products if possible, or build them out in-house. With Lume, this would not be necessary.

Our V1 supports json and csv formats for manual imports, and we’re quickly expanding to other formats (like pdf).

So, to clarify - Lume supports this today only if you provide the linked claim data in json or csv format, and in the near future will support direct pdf formats. All of our users so far provide custom data through their data warehouse, json, or csv.

If you have the desired standardized claim format, Lume supports this use case. We also have a pdf parser in the roadmap to parse documents exactly like the one you linked, to then transform and pipe the data accordingly.

Thanks! It is a funny meta moment to be using a similarly-named tool.

Yep - we do not expose any sort of prompting. We use the LLM only at specific parts of the process, and the user has no access to it.

Regarding guarantee that it will work correctly, there are ways to reduce the ambiguity in the task given. One way is to input very detailed descriptions of your end schema. This limits the amount of assumptions our model has to make. In addition, you can define tests either by writing SQL code on Lume, or by explaining in plain English the tests the final data has to pass (and edit them, of course). Our models make sure the end data passes these tests, guaranteeing your desired outcomes. We also offer versioning and backtesting capabilities, so you can have more confidence in your deployments. You can also review the sample data + the sql used to guarantee Lume drafted the integration you desired.

With regards to where your data is stored, technically we only need your schema information for our models and everything is run on your cloud, which some customers prefer for privacy / safety. That being said, the ability to sample source data or test the end schema, which does require some data read access, will improve your experience with Lume. In these cases, we of course have contractual agreements with our customers.

Yes, we are using an LLM for some parts of the code generation, specifically GPT-4. In the medium-term, we plan to go lower in the stack and have our own AI model. We broke down the process into modular steps to only leverage LLMs where it's most needed, and use rule-based methods in other parts of the process (e.g. in fixing compilation errors). This maximizes the accuracy of the transformations.

We leveraged Airbyte - it makes supporting that many connections much more seamless ... and a lot of coding!