Pentaho GenAI Plugin Suite: Connecting PDI Pipelines to LLMs

Most PDI pipelines move structured data: tables, CSV files, APIs. But a lot of useful business data sits in PDFs, Word files, slide decks and web pages, and more and more teams want to feed that content to large language models (LLMs). Pentaho's answer is the GenAI Plugin Suite, a set of PDI step plugins that connect your data pipelines to LLMs such as OpenAI and Azure OpenAI.

In this post I cover what is in the suite, how the pieces fit into a pipeline, how to get it, and what you can do if you do not have the license.

First, the licensing reality

The GenAI plugins are not part of standard PDI. On Pentaho's plugin page they are listed under Limited Availability and marked as requiring an additional paid license, and you get them by contacting Pentaho sales. They were built by Pentaho's Professional Services team together with an early "lighthouse" customer.

So if you install PDI 11 and search the step list for "AI Chat", you will not find it. Keep this in mind before you design a project around these steps.

What is in the suite

Pentaho groups the plugins into three layers that follow a typical GenAI pipeline: get the content in, prepare it, then send it to the model.

1. Data ingestion layer

• Read Unstructured Document: detects and extracts text from many file types, including PDF, Word, PowerPoint and plain text. This is the step that turns a folder of documents into rows on a PDI stream.
• HTML Parser: extracts useful content from web pages or HTML documents, for example to clean scraped pages before they go to a model.
• Web Crawler: listed by Pentaho as planned, for collecting content from websites.

2. Transformation layer

• Base64 Encode: converts files such as images or text to Base64. LLM APIs like OpenAI often expect attached files in this format.
• Base64 Decode: converts Base64 back to a file, for example when a model returns an image or document in Base64.
• Document Metadata Extractor: pulls system and file metadata from PDFs, Word, PowerPoint and text files, which is useful for tagging and filtering content later.

3. AI layer

• AI Chat: the core step. It connects to LLMs such as OpenAI and Azure OpenAI, sends prompts built from your stream data, and returns the responses as fields. It supports prompt engineering and retrieval-augmented generation (RAG), so the model can answer using your own documents.
• AI Segmentation: splits text into chunks by tokens, characters or regular expressions. Chunking matters because models have context limits and because RAG works on smaller passages, not whole documents.
• Vector Databases: steps to store and search embeddings in vector databases such as PGVector, AlloyDB, Pinecone, Weaviate and Chroma, plus an in-memory, file-based option for smaller jobs.

Pentaho is clear that these plugins do not build or train AI models. Their job is to get the right data into and out of existing models, whether those are cloud services or models you run locally.

How it fits together: a RAG pipeline in PDI

The most common pattern the suite is built for is RAG: instead of hoping the model knows your business, you give it the relevant passages from your own documents at question time. In PDI terms it is two transformations.

Transformation 1: load the knowledge base (run on a schedule)

1. Get File Names to list new documents in a folder (see my Get File Names step post).
2. Read Unstructured Document to extract the text, and Document Metadata Extractor for author, dates and file details.
3. AI Segmentation to split the text into chunks.
4. Generate embeddings and write them with a Vector Database step, keeping the source file name and metadata with each chunk.

Transformation 2: answer questions

1. Receive a question (from a table, a file, or a web service call).
2. Search the vector database for the most relevant chunks.
3. Send the question plus those chunks to AI Chat with a prompt such as "Answer only from the context below."
4. Write the answer and the source documents it used to a table or file.

Everything around the AI steps is normal PDI: Filter Rows, Select Values, Table Output, error handling, logging. That is the real selling point. The AI part becomes one more step in a pipeline your team already knows how to schedule and monitor.

Practical use cases

• Extracting tables from PDF reports. Pentaho's own example: monthly sales reports arrive as PDFs with a summary and product-by-region tables. The pipeline reads each PDF, asks the model to return the table as structured data, and loads it into the reporting database.
• Internal document search. Load manuals, policies and training material into a vector database so staff can ask questions and get answers with sources.
• Enriching records. Classify support tickets, summarize long comments, or extract fields such as product names from free text before loading them into a warehouse.
• Content generation with current data. Draft product or campaign text using the latest figures from your own systems instead of the model's general knowledge.

No license? You can still call an LLM from PDI

If the paid suite is not an option, standard PDI steps can already talk to an LLM API. It takes more wiring, but it works for simple cases like classification or summarization:

1. Build the request body as a JSON field, for example with Modified JavaScript Value or JSON Output. For OpenAI's chat API it contains the model name and a messages array with your prompt and the row's text.
2. Send it with the REST Client step: method POST, content type application/json, and an Authorization: Bearer ${OPENAI_API_KEY} header.
3. Parse the reply with JSON Input, reading the answer text from the response field.

What you do not get this way are the document readers, chunking and vector database steps, so full RAG pipelines are much harder to build by hand. PDI 11 also includes a Python Executor step, which is another route if your team already uses Python AI libraries.

Things to watch before you go to production

• Data privacy. Sending rows to a cloud LLM means sending your data outside your network. Check what is allowed, remove or mask personal data first, and consider Azure OpenAI or a locally hosted model where rules are strict.
• API keys. Keep keys in kettle.properties or environment variables and refer to them as variables. Never hard-code them in a .ktr file that ends up in a repository.
• Cost and rate limits. LLM APIs charge per token and limit requests per minute. A transformation that runs one call per row on a million-row table can get expensive fast. Filter first, test on a sample, and control parallel step copies.
• Output quality. Model answers are not deterministic and can be wrong. Ask for structured output (such as JSON), validate it with normal PDI steps, and send rows that fail validation to an error stream for review.
• Logging. Store the prompt, the response and the source document IDs so you can explain later why a record got a particular value.

Wrapping up

The GenAI Plugin Suite brings the main building blocks of an AI pipeline (document reading, chunking, vector storage and LLM calls) into the same drag-and-drop world as the rest of PDI. For enterprise teams already on Pentaho, that is a practical way to add AI to existing pipelines without a separate tool stack. Just be aware that it is a separately licensed, limited-availability add-on, and that for simple needs the core REST Client step can already get you started.

References: Pentaho Platform Plugins, GenAI Plugin Suite: Unlocking the Power of Pentaho Data Integration with GenAI (Pentaho blog).