There is still much discussion about the potential applications of GenAI, but beforehand, it is necessary to consider the preparation of cloud infrastructure to deploy such products.
A significant portion of businesses in Brazil are already operating in the cloud, ranging from large corporations with their dedicated spaces in partnerships with AWS, Azure and GCP,, for the most part, to small and medium-sized companies that adopt platforms that largely run on one of these three providers. The migration process, accentuated in the last decade, has brought increased complexity to a company's application ecosystem, as data transformation and processing occur across multiple instances (often still on-premises, meaning applications running on local servers) and drive a company to operate with hundreds, if not thousands, of automated and distributed routines. The analysis below, from 2021, demonstrates the trend of expenditures and apps migrated to the cloud by businesses.
The majority of these new applications are either born as serverless or, more accurately, "containerized" to adapt. GenAI comes to add to this migration trend.
The RPA technology is also part of this complex scenario. Although the RPA agent itself runs on a virtual machine that emulates a UI of an operating system, often these agents make queries and request data transformations that run on cloud applications, creating a linked combination of extraction, transformation, and data consolidation routines both in the cloud and locally. It is no longer possible to segregate these processes. They are hybrid instances and routines that are integral to the overall process journeys of companies.
Generative AI will naturally fit into all of this, as all new frameworks are 100% cloud-oriented, following a trend that was already underway, reducing deployment bottlenecks and bringing productivity.
First, let's analyze the aspects related to deployment: we can simplify a GenAI product into three basic layers: a vector database (which can be fed by traditional databases), an agent trained from a LLM and finely tuned to perform a task, and an API layer, which allows making requests to this model, as well as enabling the model itself to perform actions in its external environment. It's important to emphasize that a significant portion of OpenSource projects for LLMs are prepared to run on Docker/Kubernetes, greatly facilitating deployment on any cloud. Here's a simple diagram to aid in the explanation:
Every application encapsulated within the container, composed of libraries that can vary depending on the application and desired costs, which in this representation consists of LangChain to run the Agent, LLM, and workflows, Chroma for the vector database, LammaIndex for indexing proprietary unstructured data, form a single Docker image that can be generated by FlowiseAI: in this post, you can better understand how to 'assemble' this application.
This Docker image can be easily deployed on any cloud compatible with Docker/Kubernetes. In this same representation, the model consumes OpenAI both as a foundation for the language model and for retraining with proprietary data (indexing), but it could also be other generic models from Google, for example, or Anthropic. Emphasizing once again, this is a generic architecture proposed for LLMs, in this case, an agent that performs actions, since in the I/O layer, we add, for instance, the possibility for the agent to execute an action based on textual analysis, requested through a prompt by the user.
This GenAI application can be seamlessly integrated into a macro process flow where RPA agents are involved, especially when dealing with unstructured data. Consider a use case of a workflow where engineering projects are evaluated by a coordinator through SAP. GenAI can assist in extracting metadata from non-standardized proposals as well as assessing structural and/or commercial risks of the project already registered in SAP, based on structured historical data.
The significant leap is that GenAI greatly facilitates this retraining for specific contexts, especially when compared to previous machine learning methods. Another major advantage is that a large portion of the available frameworks are coded in Python, making them easily "pluggable" into RPA applications supported by this language. In previous experiments, I was able to demonstrate this ease of retraining as well as deployment, as you can see in these posts on the blog. It appears that the main barriers to adoption still lie in the lack of allocation of time and resources for proof of concept, given that the risks of adopting such technology, after appropriate refinements, are infinitely lower than the potential for process automation deployment. Additionally, the ROI for such projects, in preliminary analysis, seems very promising. So why not start? Well, just like the RPA technology had its boom after the first successful cases were publicized in the market, it will be no different with GenAI. The difference now lies in the degree of disruption. 👨💻 We will see.
Comments