imixs/office-dynamixs-ai
imixs/office-dynamixs-ai
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docu

Browse source
This commit is contained in:
Ralph Soika 2025-06-05 23:15:54 +02:00
parent 5c1ce63a17
commit 1e07854375
5 changed files with 347 additions and 237 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
README.md
View file

@ -5,7 +5,7 @@ This repository contains the source code as also build scripts to setup an Hyper
**Topics**
- [Retrieval Augmented Generation (RAG)](./doc/RAG.md)
- [Knowledge DB (Apache Cassandra)](./doc/CASSANDRA.md)
- [Knowledge DB (Apache Cassandra)](./doc/RAG_CASSANDRA.md)
## Build & Run

65
doc/CASSANDRA.md
View file

@ -1,65 +0,0 @@
# Cassandra - The RAG Database
The retrieval database in the dynamixs.ai RAG system is based on Apache Cassandra which provides a distributed database system with high availability and scalability.
The schema for the RAG database is created automatically during startup. This includes the Cassandra keyspace as also the data base schema.
The main table has the following definition:
```sql
CREATE TABLE IF NOT EXISTS document_vectors (
id text,
chunk_id uuid,
content_chunk text,
content_vector VECTOR <FLOAT, " + DIMENSIONS + ">,
PRIMARY KEY (id, chunk_id)
);
```
The default dimensions for float vector is based on the LLM used for indexing. 'all-MiniLM-L6-v2' s is a sentence-transformers model to map sentences & paragraphs to a 384 dimensional dense vector space. Find more details in the section [RAG](RAG.md).
Aside from that, the Cassandra cluster can also be managed through the Command Line Console (CLI).
## Using the Cassandra CLI
To connect to your cluster you can use the cqlsh tool.
To run cqlsh from your started docker environment run:
```bash
$ docker exec -it cassandra cqlsh
Connected to dynamixsAiCluster at 127.0.0.1:9042
[cqlsh 6.2.0 | Cassandra 5.0.4 | CQL spec 3.4.7 | Native protocol v5]
Use HELP for help.
cqlsh>
```
## CQL Examples
The following section contains some basic cqlsh commands. For full description see the [Cassandra CQL refernce](https://docs.datastax.com/en/dse/6.0/cql/).
**show key spaces:**
Show all available keyspaces:
cqlsh> DESC KEYSPACES;
**Switch to Keysapce:**
Select a keyspace be name to interact with this keyspace:
cqlsh> use embeddings;
**Show tables in a keyspace:**
Show tables schemas in current keyspace:
cqlsh:embeddings> DESC TABLES;
**Drop Keyspace:**
Drop the keyspace:
DROP KEYSPACE IF EXISTS <keyspace_name>;
### Create a dev keyspace with cqlsh
cqlsh> CREATE KEYSPACE <keyspace_name> WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 1};

20
doc/RAG-draft.md Normal file
View file

@ -0,0 +1,20 @@
# Dynamixs AI - Retrieval-Augmented-Generation (RAG)
Retrieval Augmented Generation (RAG) is a term from the field of artificial intelligence and machine learning.
- **Retrieval** - refers to the ability to quickly and efficiently access stored information or retrieve it from a database or other storage system.
- **Augmented** - refers to the idea of improving or expanding an existing function or capability by adding something new.
- **Generation** - refers to the creation of new content or results based on available information.
In summary, Retrieval Augmented Generation (RAG) describes a method that uses artificial intelligence or machine learning to quickly and efficiently access stored information and use it to generate new content or results. This method can help improve the accuracy and relevance of generated content by drawing on a broader range of information.
The following section give a general overview how the Retrieval-augmented generation (RAG) is realized in Dynamixs AI.
## The Model
The retrieval data in Dynamixs.AI is generated by the LLM [nomic-embed-text-v2-moe](https://huggingface.co/nomic-ai/nomic-embed-text-v2-moe-GGUF) which is
a [sentence-transformers model](https://www.sbert.net/) supporting more then 100 languages and trained on over 1.6B pairs.
The model is used in Q4 quantitation and a size of 328MiB which provides a good quality for most use cases.
The model maps sentences & paragraphs to a 768 dimensional dense vector space. It can be run on a CPU with adequate performance.
## BPMN

236
doc/RAG.md
View file

@ -1,224 +1,118 @@
# Dynamixs AI - Retrieval-augmented generation (RAG)
# Dynamixs AI - Hyper AI with Process-Driven RAG
Retrieval Augmented Generation (RAG) is a term from the field of artificial intelligence and machine learning.
**Integrating Retrieval-Augmented Generation with Business Process Management**
- **Retrieval** - refers to the ability to quickly and efficiently access stored information or retrieve it from a database or other storage system.
- **Augmented** - refers to the idea of improving or expanding an existing function or capability by adding something new.
- **Generation** - refers to the creation of new content or results based on available information.
## 1. Executive Summary
In summary, Retrieval Augmented Generation (RAG) describes a method that uses artificial intelligence or machine learning to quickly and efficiently access stored information and use it to generate new content or results. This method can help improve the accuracy and relevance of generated content by drawing on a broader range of information.
Traditional Retrieval-Augmented Generation (RAG) systems excel at finding semantically similar content but struggle with the complex realities of enterprise environments: dynamic access permissions, evolving business contexts, and the need to integrate unstructured data with structured business processes. This white paper introduces Process-Driven RAG, a novel architectural approach that bridges the gap between AI-powered information retrieval and enterprise business process management.
The following section give a general overview how the Retrieval-augmented generation (RAG) is realized in Dynamixs AI.
By integrating RAG capabilities directly into Business Process Management (BPM) platforms through BPMN-controlled workflows, organizations can achieve unprecedented levels of security, context awareness, and business logic integration in their AI-driven information systems. This hybrid approach transforms RAG from a purely technical search mechanism into a business-aware intelligence layer that respects organizational hierarchies, process states, and regulatory requirements.
## The Model
## 2. Introduction & Problem Statement
The retrieval data in Dynamixs.AI is generated by the LLM [ nomic-embed-text-v2-moe](https://huggingface.co/nomic-ai/nomic-embed-text-v2-moe-GGUF) which is
a [sentence-transformers model](https://www.sbert.net/) supporting more then 100 languages and trained on over 1.6B pairs.
The model is used in Q4 quantitation and a size of 328MiB which provides a good quality for most use cases.
The model maps sentences & paragraphs to a 768 dimensional dense vector space. It can be run on a CPU with adequate performance.
Retrieval-Augmented Generation (RAG) represents a significant advancement in AI-powered information systems, combining the generative capabilities of Large Language Models (LLMs) with dynamic information retrieval from external knowledge bases. Unlike traditional LLMs that rely solely on their training data, RAG systems
## Storage
1. first search through current document repositories to **retrieve** relevant information,
2. then use this retrieved context to **argument** the problem
3. and finally **generate** accurate, up-to-date responses.
The retrieval data generated by the LLM is stored in a [Cassandra Database](CASSANDRA.md) with the following schema:
This approach addresses the "knowledge cutoff" limitation of LLMs while enabling organizations to leverage their proprietary data for AI-powered insights.
```sql
CREATE TABLE IF NOT EXISTS document_vectors (
id text,
chunk_id uuid,
content_chunk text,
content_vector VECTOR <FLOAT, " + DIMENSIONS + ">,
PRIMARY KEY (id, chunk_id)
);
```
However, the enterprise adoption of RAG has revealed a fundamental tension between the power of semantic search and the complexity of real-world business environments. While RAG systems can efficiently locate relevant information across vast document repositories, they operate in isolation from the business processes that give this information meaning and context.
The following section explains the schema in more detail.
Consider a contract management scenario: when a legal team searches for "penalty clauses exceeding one million EUR," a traditional RAG system might return relevant text chunks from various contracts. However, it cannot determine
### The Chunk Content
- whether the requesting user has authorization to access specific contracts,
- whether those contracts are currently under litigation (making them sensitive),
- or whether the contract status has changed since the last indexing cycle.
The RAG database stores not only the vectors but also the textual representation of the content chunks. This has several advantages:
This disconnect between semantic search capabilities and business reality creates significant gaps in enterprise AI implementations.
**Context provision for the LLM**
The challenge becomes even more pronounced in regulated industries where data access must be governed by complex business rules, approval workflows, and real-time process states. Static content indexing cannot capture the dynamic nature of business information, where the same document might be accessible to different users under different circumstances, or where the relevance of information depends on current process contexts.
The vector is only used for similarity searching - it is a numerical representation of text, but not human-readable. Once the most similar documents have been found, the original text (content_chunk) can be used directly as context for a LLM. Note: the LLM cannot work with the vectors, but needs the readable text.
Furthermore, traditional RAG architectures suffer from the "context island" problem. Each document chunk exists in isolation, disconnected from the broader business ecosystem that gives it meaning. A contract clause about delivery terms becomes significantly more valuable when combined with real-time information about supplier performance, current order status, or pending negotiations – context that exists within active business processes but remains invisible to conventional RAG systems.
**Efficiency of Queries**
This paper presents **Hyper:AI** as a solution to these challenges, demonstrating how the integration of RAG capabilities with Business Process Management creates a new class of context-aware, business-intelligent information retrieval systems that maintain semantic search power while respecting enterprise governance requirements and leveraging dynamic business context.
The chunk content also allows an immediate access to the context with no need to make a separate query to the Imixs Workflow instance after the vector search to retrieve the original content. This would mean additional latency and complexity. `content_chunk` stores exactly the text section that corresponds to the vector.
## 3. Technology Foundation
**The typical RAG workflow**
### 3.1 Retrieval-Augmented Generation (RAG) Overview
The typical workflow in RAG system can be separated into 3 phases:
RAG systems operate through a three-phase workflow: documents are chunked and converted into high-dimensional vectors (embeddings) stored in vector databases, similarity searches retrieve relevant content based on user queries, and Large Language Models generate responses using this retrieved context as input. This architecture enables AI systems to access current, domain-specific information beyond their training data.
1. **Search:** Vector similarity search finds relevant content_vector entries.
2. **Retrieval:** The corresponding content_chunk texts are extracted.
3. **Generation:** These texts from the `content_chunk' is sent as context to the LLM.
### 3.2 Business Process Management (BPMN) Overview
Without the stored text, the retrieval part of RAG would not be possible, as you would have no content to provide to the LLM as context.
Business Process Management Notation (BPMN) provides a standardized method for modeling business workflows as executable processes. Within BPM platforms, each process instance maintains its own lifecycle, metadata, and access control lists (ACLs), creating a dynamic environment where business rules govern data access and process flow in real-time.
### The Content Reference
A powerful capability of BPMN 2.0 is its extension mechanism, which allows organizations to add custom attributes and behaviors to standard BPMN elements without breaking model portability. These extensions enable process designers to embed technical specifications directly into business process models - transforming abstract workflow diagrams into executable, technology-aware systems. Through BPMN extensions, organizations can seamlessly integrate complex technical operations like data indexing, AI model invocation, or security checks into their business process flows, making the process model itself a configuration layer for technical implementations.
Together with the `content_chunk` the RAG system stores also the UniqueID from to the referred business process instance within the workflow instance. This is a hybrid concept that provides several advantages:
### 3.3 The Integration Challenge
**1. Normalization and Consistency**
Traditional RAG systems treat documents as static entities, disconnected from the business processes that created, govern, and give meaning to them. This separation creates security gaps, context loss, and missed opportunities for dynamic content enrichment. The challenge lies in bridging semantic search capabilities with process-aware business logic while maintaining the performance and scalability requirements of enterprise systems.
- Single Source of Truth: The main Document with the full data exist only once in the imixs-workflow system.
- Changes to data inside a process instance which is not part of the Vector DB are automatically available without the need to update the Vector DB.
- No full data duplication.
## 4. The Process-Driven RAG Architecture
**2. Better Integration**
### 4.1 Core Concept & Design Principles
- Easy access not only to text chunks but also the complete business process objects with its metadata for further refinement of a result set.
- Ability to apply additional business logic (permissions, status, etc.).
[To be developed]
**3. Flexibility**
### 4.2 Technical Architecture
- The application can decide dynamically if either the content_chunk or other parts of the referred process instance is used as context.
- Easier updates in case of document changes.
- The `content_chunk` still provide fast access to context during the retrieval process.
[To be developed]
## Example
### 4.3 Data Flow & Processing Pipeline
The following shows the advantage of hybrid concept of content_chunks and workitem references.
[To be developed]
The user enters the following question:
## 5. Key Advantages & Differentiators
_"Show me all service contracts from non-EU countries with a penalty clause of over 1 million EUR."_
## 6. Implementation Details
**The problem with pure text chunks:**
### 6.1 BPMN-Based Process Modeling
In this kind of a request the context can be build from the received text chunks like :
The **Hyper:AI** architecture leverages an event-driven approach within BPMN models to orchestrate AI operations seamlessly within business workflows. This implementation utilizes BPMN Signal Events as the primary mechanism for integrating RAG functionality into process execution.
- Chunk 1: _"...in case of breach of contract, contractual penalties of 1.5 million EUR are applicable..."_
- Chunk 2: _"...Penalty clause: contractual penalties of 2.3 million EUR..."_
- Chunk 3: _"...penalties of 1.8 million EUR in case of non-fulfillment..."_
#### 6.1.1 Signal Adapter Architecture
What is missing here: contract number, date, contracting party, country, contract value, status, etc.
At the core of this approach are Signal Adapters - specialized technical components that bridge the gap between BPMN process models and RAG operations. Process modelers define Signal Definitions within their BPMN models, each corresponding to a specific adapter (such as RAG indexing or retrieval). When a BPMN Signal Event is triggered during process execution, the associated Signal Adapter automatically executes the corresponding technical operation and returns results directly into the process instance data.
**The Advantage of reference IDs:**
This architecture provides several key advantages:
But using the id the RAG system can access the full business data from the workflow system. This allows to build more relevant context like :
- Declarative Configuration: Process modelers can configure complex AI operations through standard BPMN modeling without requiring programming knowledge
- Event-Driven Execution: RAG operations are triggered precisely when needed within the business process flow
- Automatic Context Integration: Results from RAG operations are immediately available as process variables for subsequent process steps
```
Found service contracts:
#### 6.1.2 Dynamic Content Generation through BPMN Data Objects
1. Contract SVC-2024-001 (ABC Corp Singapore)
- Concluded: 15.03.2024
- Contract penalty: 1.5 million EUR
- Status: Active
The system extends BPMN's Data Object concept to serve as intelligent prompt templates for content generation. Process modelers can define structured prompts within BPMN Data Objects, which are then dynamically populated with process context data during execution. This approach enables the creation of contextually relevant content for RAG indexing directly from within the process model.
For example, in a customer complaint process, a Data Object might contain a template that combines customer information, product details, and complaint specifics into a coherent text block optimized for vector embedding and later retrieval.
2. Contract SVC-2024-007 (XYZ Ltd Hong Kong)
- Concluded: 22.01.2024
- Contract penalty: 2.3 million EUR
- Status: Under negotiation
```
#### 6.1.3 Practical Implementation Example: Customer Complaint Process
Using the combination of content_chunk text and metadata form the process instance allows to build even more complex context.
Consider a customer complaint handling process where RAG integration enhances decision-making through intelligent context retrieval:
So the hybrid approach is clearly more sensible for a Business Process Management System, as it combines both the advantages of RAG (semantic search) and structured business data.
1. **Initial Complaint Processing:** When a customer complaint is received, a BPMN Signal Event triggers the RAG retrieval adapter
2. **Context Enhancement:** The RAG system searches for similar complaints, related products, customer history, and relevant documentation
3. **Process Enrichment:** Retrieved information is automatically integrated into the process instance, expanding the available context
4. **Intelligent Routing:** With enriched context, the process can make informed decisions about escalation, assignment, or automated resolution
5. **LLM Integration:** The expanded process context enables sophisticated queries to Large Language Models for decision support or automated response generation
## A More Complex Example
This integration transforms a simple complaint handling workflow into an intelligent system that leverages organizational knowledge and experience for each individual case, while maintaining full traceability and business process control.
Next we can examine a more complex use case.
### 6.2 Vector Database Architecture (Cassandra)
The user enters the following question:
[To be developed]
_"Are there incoming invoices in which service fees have been charged that do not correspond to the underlying contracts?"_
### 6.3 Reference-Based Data Model
This example indeed touches the limits of RAG, but not necessarily insurmountable ones.
[To be developed]
The challenges:
### 6.4 Process-Controlled Indexing
1. **Cross-Document Reasoning:**
[To be developed]
- RAG finds similar chunks, but the question requires comparisons between different document types (invoices vs. contracts).
- An LLM would need to simultaneously receive invoice chunks AND corresponding contract chunks.
## 7. Use Case Demonstrations
2. **Structured Data Extraction:**
## 8. Performance & Scalability Considerations
- "Service fees" need to be extracted and compared from unstructured text.
- Numbers, prices, and service descriptions must be semantically mapped.
3. **Relationship Logic:**
- Which invoice belongs to which contract?
- The LLM needs this connection to make meaningful comparisons.
### Possible Solutions
The following solutions are specific implementations in the RAG workflow:
**Approach 1:** Enhanced RAG with a Multi-Step Retrieval
```
# Pseudo-Code
def complex_query_handler(question):
# Step 1: Finde relevante Rechnungen
invoice_chunks = vector_search("Servicegebühren Rechnungen")
# Step 2: Extrahiere Vertrags-IDs aus gefundenen Rechnungen
contract_ids = extract_contract_references(invoice_chunks)
# Step 3: Hole zugehörige Vertrags-Chunks
contract_chunks = get_contract_chunks(contract_ids)
# Step 4: LLM mit beiden Kontexten
return llm.query(question, context=invoice_chunks + contract_chunks)
```
**Approach 2:** Hybrid-System with structured data
```
# Pseudo-Code
def intelligent_agent(question):
# Agent entscheidet: "Ich brauche Rechnungs- UND Vertragsdaten"
plan = create_execution_plan(question)
for step in plan:
if step.type == "find_invoices":
invoices = rag_search(step.query)
elif step.type == "find_contracts":
contracts = rag_search(step.query)
elif step.type == "compare":
result = llm_compare(invoices, contracts)
return synthesize_answer(result)
```
**Recommendation**
Since we already have a business process management suite, we can follow the hybrid approach:
1. RAG for content discovery: "Find all documents with service fees"
2. Structured queries: Use your business data for relationships
3. LLM for final analysis: With all relevant data as context.
```
# Pseudo-Code
def analyze_service_fee_discrepancies():
# RAG: Finde relevante Dokumente
relevant_docs = vector_search("Servicegebühren")
# Business Logic: Hole strukturierte Daten
invoices_with_contracts = get_invoice_contract_pairs(relevant_docs)
# LLM: Analysiere mit vollem Kontext
return llm.analyze_discrepancies(invoices_with_contracts)
```
**Conclusion:**
A pure RAG solution reaches its limits here, but an intelligent hybrid system consisting of RAG + structured data + multi-step reasoning can certainly answer such complex questions.
## Chunking Business Documents
As the content_chunk can only have a small size below 1KB the RAG system includes a split process to split documents into smaller content_chunks.
The split-process breaks down large business processes into logical chunks. Since the data is usually available in markup or can be prepared for the indexing process within the BPMN model, the split is made based on the structure in the markup. This guarantees a clean separation of text parts without the need to compute overlapping.
## Data Protection
Also the vector db may contain sensitive business data represented in content chunks. To protect also this kind of data the RAG system is tightly integrated into the security layer of Imixs-Workflow. In the retrieval phase each content_chunk returned by the vector db is immediately validated against the ACL of the corresponding process instance. This avoids the affect that unauthorized uses may receive sensitive data in a retrieval phase.
As the
## Data Deletion
## BPMN
## 9. Conclusion & Future Outlook

261
doc/RAG_CASSANDRA.md Normal file
View file

@ -0,0 +1,261 @@
# Cassandra - The RAG Database
The retrieval database in the dynamixs.ai RAG system is based on Apache Cassandra which provides a distributed database system with high availability and scalability.
The schema for the RAG database is created automatically during startup. This includes the Cassandra keyspace as also the data base schema.
The main table has the following definition:
```sql
CREATE TABLE IF NOT EXISTS document_vectors (
id text,
chunk_id uuid,
content_chunk text,
content_vector VECTOR <FLOAT, " + DIMENSIONS + ">,
PRIMARY KEY (id, chunk_id)
);
```
The default dimensions for float vector is based on the LLM used for indexing. 'nomic-embed-text-v2-moe' is a sentence-transformers model to map sentences & paragraphs to a 768 dimensional dense vector space. Find more details in the section [RAG](RAG.md).
The following section explains the schema in more detail.
## The Chunk Content
The RAG database stores not only the vectors but also the textual representation of the content chunks. This has several advantages:
**Context provision for the LLM**
The vector is only used for similarity searching - it is a numerical representation of text, but not human-readable. Once the most similar documents have been found, the original text (content_chunk) can be used directly as context for a LLM. Note: the LLM cannot work with the vectors, but needs the readable text.
**Efficiency of Queries**
The chunk content also allows an immediate access to the context with no need to make a separate query to the Imixs Workflow instance after the vector search to retrieve the original content. This would mean additional latency and complexity. `content_chunk` stores exactly the text section that corresponds to the vector.
**The typical RAG workflow**
The typical workflow in RAG system can be separated into 3 phases:
1. **Search:** Vector similarity search finds relevant content_vector entries.
2. **Retrieval:** The corresponding content_chunk texts are extracted.
3. **Generation:** These texts from the `content_chunk' is sent as context to the LLM.
Without the stored text, the retrieval part of RAG would not be possible, as you would have no content to provide to the LLM as context.
## The Content Reference
Together with the `content_chunk` the RAG system stores also the UniqueID from to the referred business process instance within the workflow instance. This is a hybrid concept that provides several advantages:
**1. Normalization and Consistency**
- Single Source of Truth: The main Document with the full data exist only once in the imixs-workflow system.
- Changes to data inside a process instance which is not part of the Vector DB are automatically available without the need to update the Vector DB.
- No full data duplication.
**2. Better Integration**
- Easy access not only to text chunks but also the complete business process objects with its metadata for further refinement of a result set.
- Ability to apply additional business logic (permissions, status, etc.).
**3. Flexibility**
- The application can decide dynamically if either the content_chunk or other parts of the referred process instance is used as context.
- Easier updates in case of document changes.
- The `content_chunk` still provide fast access to context during the retrieval process.
## Examples
The following shows the advantage of the hybrid concept of content_chunks and workitem references in some examples.
### Retrieval Example
The user enters the following question:
_"Show me all service contracts from non-EU countries with a penalty clause of over 1 million EUR."_
**The problem with pure text chunks:**
In this kind of a request the context can be build from the received text chunks like :
- Chunk 1: _"...in case of breach of contract, contractual penalties of 1.5 million EUR are applicable..."_
- Chunk 2: _"...Penalty clause: contractual penalties of 2.3 million EUR..."_
- Chunk 3: _"...penalties of 1.8 million EUR in case of non-fulfillment..."_
What is missing here: contract number, date, contracting party, country, contract value, status, etc.
**The Advantage of reference IDs:**
But using the id the RAG system can access the full business data from the workflow system. This allows to build more relevant context like :
```
Found service contracts:
1. Contract SVC-2024-001 (ABC Corp Singapore)
- Concluded: 15.03.2024
- Contract penalty: 1.5 million EUR
- Status: Active
2. Contract SVC-2024-007 (XYZ Ltd Hong Kong)
- Concluded: 22.01.2024
- Contract penalty: 2.3 million EUR
- Status: Under negotiation
```
Using the combination of content_chunk text and metadata form the process instance allows to build even more complex context.
So the hybrid approach is clearly more sensible for a Business Process Management System, as it combines both the advantages of RAG (semantic search) and structured business data.
### Complex Example
Next we can examine a more complex use case.
The user enters the following question:
_"Are there incoming invoices in which service fees have been charged that do not correspond to the underlying contracts?"_
This example indeed touches the limits of RAG, but not necessarily insurmountable ones.
The challenges:
1. **Cross-Document Reasoning:**
- RAG finds similar chunks, but the question requires comparisons between different document types (invoices vs. contracts).
- An LLM would need to simultaneously receive invoice chunks AND corresponding contract chunks.
2. **Structured Data Extraction:**
- "Service fees" need to be extracted and compared from unstructured text.
- Numbers, prices, and service descriptions must be semantically mapped.
3. **Relationship Logic:**
- Which invoice belongs to which contract?
- The LLM needs this connection to make meaningful comparisons.
#### Possible Solutions
The following solutions are specific implementations in the RAG workflow:
**Approach 1:** Enhanced RAG with a Multi-Step Retrieval
```
# Pseudo-Code
def complex_query_handler(question):
# Step 1: Finde relevante Rechnungen
invoice_chunks = vector_search("Servicegebühren Rechnungen")
# Step 2: Extrahiere Vertrags-IDs aus gefundenen Rechnungen
contract_ids = extract_contract_references(invoice_chunks)
# Step 3: Hole zugehörige Vertrags-Chunks
contract_chunks = get_contract_chunks(contract_ids)
# Step 4: LLM mit beiden Kontexten
return llm.query(question, context=invoice_chunks + contract_chunks)
```
**Approach 2:** Hybrid-System with structured data
```
# Pseudo-Code
def intelligent_agent(question):
# Agent entscheidet: "Ich brauche Rechnungs- UND Vertragsdaten"
plan = create_execution_plan(question)
for step in plan:
if step.type == "find_invoices":
invoices = rag_search(step.query)
elif step.type == "find_contracts":
contracts = rag_search(step.query)
elif step.type == "compare":
result = llm_compare(invoices, contracts)
return synthesize_answer(result)
```
**Recommendation**
Since we already have a business process management suite, we can follow the hybrid approach:
1. RAG for content discovery: "Find all documents with service fees"
2. Structured queries: Use your business data for relationships
3. LLM for final analysis: With all relevant data as context.
```
# Pseudo-Code
def analyze_service_fee_discrepancies():
# RAG: Finde relevante Dokumente
relevant_docs = vector_search("Servicegebühren")
# Business Logic: Hole strukturierte Daten
invoices_with_contracts = get_invoice_contract_pairs(relevant_docs)
# LLM: Analysiere mit vollem Kontext
return llm.analyze_discrepancies(invoices_with_contracts)
```
**Conclusion:**
A pure RAG solution reaches its limits here, but an intelligent hybrid system consisting of RAG + structured data + multi-step reasoning can certainly answer such complex questions.
## Chunking Business Documents
As the content_chunk can only have a small size below 1KB the RAG system includes a split process to split documents into smaller content_chunks.
The split-process breaks down large business processes into logical chunks. Since the data is usually available in markup or can be prepared for the indexing process within the BPMN model, the split is made based on the structure in the markup. This guarantees a clean separation of text parts without the need to compute overlapping.
## Data Protection
Also the vector db may contain sensitive business data represented in content chunks. To protect also this kind of data the RAG system is tightly integrated into the security layer of Imixs-Workflow. In the retrieval phase each content_chunk returned by the vector db is immediately validated against the ACL of the corresponding process instance. This avoids the affect that unauthorized uses may receive sensitive data in a retrieval phase.
As the
## Data Deletion
TBD
# Administration
Aside from internal database logic, the Cassandra cluster can also be managed through the Command Line Console (CLI).
## Using the Cassandra CLI
To connect to your cluster you can use the cqlsh tool.
To run cqlsh from your started docker environment run:
```bash
$ docker exec -it cassandra cqlsh
Connected to dynamixsAiCluster at 127.0.0.1:9042
[cqlsh 6.2.0 | Cassandra 5.0.4 | CQL spec 3.4.7 | Native protocol v5]
Use HELP for help.
cqlsh>
```
## CQL Examples
The following section contains some basic cqlsh commands. For full description see the [Cassandra CQL refernce](https://docs.datastax.com/en/dse/6.0/cql/).
**show key spaces:**
Show all available keyspaces:
cqlsh> DESC KEYSPACES;
**Switch to Keysapce:**
Select a keyspace be name to interact with this keyspace:
cqlsh> use embeddings;
**Show tables in a keyspace:**
Show tables schemas in current keyspace:
cqlsh:embeddings> DESC TABLES;
**Drop Keyspace:**
Drop the keyspace:
DROP KEYSPACE IF EXISTS <keyspace_name>;
### Create a dev keyspace with cqlsh
cqlsh> CREATE KEYSPACE <keyspace_name> WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 1};