We use cookies to improve your experience on our site. By clicking “Accept”, you are agreeing to the collection and use of data as described in our Privacy Policy.
We use cookies to improve your experience on our site. By using our site, you are agreeing to the collection and use of data as described in our Privacy Policy.
Why embedded iPaaS solutions fail to support AI-powered product features
Anuj Jhunjhunwala
Director of Product Management
at Merge
Customer data can play an essential role in the retrieval part of the retrieval-augmented generation (RAG) pipelines that power your product.
Using this type of data effectively, however, requires connecting to all the relevant systems across your customer base, standardizing the data that’s synced from these systems into a common format, and diagnosing and resolving any integration issues quickly.
Your RAG pipelines wouldn’t scale across your customer base
Powering widely-available RAG features means building the integrations your RAG pipelines depend on for all of your customers.
Embedded iPaaS solutions are inherently bad at facilitating this.
The solution forces you and/or your customers to build one integration at a time through the platform’s “low-code” workflow builder.
As we’ve learned through numerous customer conversations, these workflow builders still require deep technical expertise—which forces your engineers to use them.
In addition, your engineers will need to spend several hours configuring each integration for every customer.
Each file storage integration build can take your engineers several hours to implement with an embedded iPaaS
Since you’ll likely need to support hundreds of integrations over time across countless customers, your engineers won’t be able to keep pace with demand. And even if they try, it’ll come at the expense of them spending time on building and improving your core product features and capabilities.
Your integrated data could lead to inaccurate outputs
Normalized data, which is consistent and doesn’t include unnecessary details, is easier for an embedding algorithm to understand.
Fields related to a file's creation date can be normalized across file storage solutions
As a result, normalized data can be embedded (or converted into a vector) more accurately before it’s added to a vector database.
Embedded queries can then be closest to the most relevant embeddings in the vector space.
Both the embedded query and the nearest embeddings would go on to be fed to an LLM—enabling the LLM to generate precise outputs.
By normalizing an embedded query like “Who reports to John?”, relevant context can be identified successfully and fed to the LLM, which helps it generate an accurate response
Unfortunately, embedded iPaaS solutions don’t normalize the data on your behalf.
Embedding the integrated data from embedded iPaaS solutions can, as a result, yield inconsistent vectors that lead to incorrect outputs.
And while your team can perform the normalization step for the integrated data, this requires them to define the data model for each integration category and build out and maintain the data transformation logic for normalizing each integrated application’s data—all of which can be incredibly time and resource intensive to perform.
Your observability tooling may limit your AI feature’s performance
Embedded iPaaS solutions fail to provide the integration observability features you need to diagnose, troubleshoot, and resolve integration issues quickly.
This causes integration issues to persist, which prevents fresh data from being embedded and available to the LLM.
The LLM you’re using would then generate low quality outputs, which quickly degrades your UX.
Take Telescope, a sales automation platform, for example.
To consistently recommend high-fit leads for customers, their RAG pipeline needs to constantly collect fresh data on leads from customers’ integrated CRMs.
Otherwise, the LLM they use can disproportionately rely on characteristics that are no longer a strong indicator of a promising lead. For instance, one of Telescope’s customers may have closed many companies in a certain industry several months ago—but those companies are no longer a strong fit for the company.
Without having up-to-date lead data from customers’ integrated CRMs, Telescope couldn’t recommend best-fit leads
Normalizing all the integrated data according to defined Common Models and allowing you to access and sync additional custom data through advanced features, like Field Mapping
Fully owning the maintenance of the integrations (through their team of partner engineers)
Providing robust Integration Observability features, like fully-searchable logs, automated issue detection, and a comprehensive dashboard overview
Merge lets you not only diagnose issues but also uncover specific steps for resolving them