RAG-Anwendungen mit OCI Generative AI Agents und Oracle APEX bauen

APEX 26.1 bringt agentische Fähigkeit in die Anwendung. Die meisten nützlichen Unternehmensfragen reichen aber über eine Anwendung hinaus — und über strukturierte Daten hinaus. Die richtige Architektur für "beantworte meine Frage aus unseren internen Dokumenten" ist nicht ein größerer APEX-Agent. Sie ist OCI Generative AI Agents, mit APEX als Eingangstür. Dieser Beitrag zeigt das praktische Muster, beide zu verbinden.

Was OCI Generative AI Agents tatsächlich tun

OCI Generative AI Agents ist ein Managed Service von Oracle, der die schwere Arbeit einer Retrieval-Augmented-Generation-Pipeline übernimmt: Dokumenten-Ingestion, Chunking, Embedding, Vektor-Speicherung, Retrieval, Prompt-Konstruktion und LLM-Aufruf. Sie zeigen ihm eine Inhaltsquelle — einen Object-Storage-Bucket mit PDFs, einen OCI-Search-Index, eine Datenbanktabelle mit kuratiertem Wissen — und der Service exponiert einen Chat-artigen Endpunkt, der Fragen gegründet in diesen Dokumenten beantwortet.

Das Verkaufsargument ist nicht die KI selbst; RAG kann man auch mit Bordmitteln zusammenstellen. Das Verkaufsargument ist, dass der Datenpfad innerhalb von OCI bleibt, das Zugriffsmodell sich mit OCI Identity integriert, die Audit-Story dieselbe wie für jeden anderen OCI-Service ist, und die operative Last eines selbstgebauten RAG-Stacks wegfällt.

Warum APEX hier OCI will

APEX KI-Agenten und KI-Tools sind auf eine Anwendung beschränkt. Der Scope ist das Feature, keine Einschränkung. Anwendungsübergreifende, dokumentübergreifende, modal-übergreifende Fragen brauchen eine andere Form:

• Wissen, das in PDFs, Verträgen, Policy-Dokumenten und SharePoint-Seiten lebt, nicht in Tabellen.
• Antworten, die das Quelldokument, den Absatz und die Seite zitieren müssen.
• Ein Retrieval- und Embedding-Modell, das Sie nicht selbst betreiben wollen.
• Eine LLM-Wahl, die durch die OCI-Bedingungen zu Datenresidenz und Vertraulichkeit reguliert ist.

Das ist die Spur von OCI GenAI Agents. APEX ist die Erlebnisebene.

Die Integrationsform

Die Architektur ist erfreulich einfach. Aus APEX-Sicht ist OCI GenAI Agents einfach ein weiterer REST-Endpunkt. Sie wickeln ihn als einzelnes REST-KI-Tool an Ihrem APEX-Agenten, geben dem Tool einen klaren Namen (zum Beispiel askKnowledgeBase) und lassen den APEX-Agenten entscheiden, wann er es aufruft.

Aus OCI-Sicht ist der Request authentifiziert, die Konversation hat eine Session-ID, das Retrieval läuft gegen die konfigurierte Inhaltsquelle, und die Antwort enthält sowohl die Antwort als auch die zitierten Dokument-Chunks.

Aus Nutzersicht chatten Anwender innerhalb einer APEX-Seite, die sich wie Teil ihrer normalen Anwendung anfühlt — selbes Login, selbes Theme, selber Audit, selbe Stelle, an der sie schon arbeiten.

Ein konkretes Beispiel: ein HR-Wissensassistent

Stellen Sie sich ein HR-Portal vor, gebaut in APEX. Die strukturierten Daten (Personalakten, Zeiterfassung, Urlaubssalden) liegen in Tabellen, auf die Ihr APEX-Agent direkt antworten kann. Aber Mitarbeitende fragen auch Sachen wie:

• "Was ist die Regelung zur Elternzeit für ein zweites Kind?"
• "Welche Kündigungsfrist habe ich, wenn ich zum 15. Dezember kündigen möchte?"
• "Gilt die Dienstwagen-Regelung anders für Senior-Manager?"

Diese Antworten leben in PDFs in einem kontrollierten Ordner, von HR verfasst, von Legal reviewt, quartalsweise aktualisiert. Sie gehören nicht in Tabellen. Die richtige Architektur:

1. HR lädt die aktuellen Policy-PDFs in einen OCI-Object-Storage-Bucket.
2. Ein OCI GenAI Agent ist gegen diesen Bucket als Inhaltsquelle konfiguriert.
3. Die APEX-HR-Anwendung hat einen KI-Agenten mit zwei Tools: employeeRecordLookup (PL/SQL, intern) und askPolicyKnowledgeBase (REST, ruft OCI GenAI Agents auf).
4. Die Instruktionen des APEX-Agenten sagen: "Nutze employeeRecordLookup für Fragen zu den eigenen Daten des Nutzers; nutze askPolicyKnowledgeBase für Policy-Fragen."
5. Der Nutzer bekommt ein Chat-Erlebnis; der Agent routet still das richtige Tool für die richtige Frage.

Jede zitierte Antwort kommt mit dem Quell-PDF und dem Absatz, sodass die Mitarbeitenden verifizieren können. Jedes Retrieval wird geloggt. Jedes Policy-Update ist einfach ein neues PDF im Bucket — kein Model-Retraining, keine Entwickleränderung.

Was diese Architektur vermeidet

Es lohnt sich aufzuzählen, was diese Architektur nicht braucht. Keine selbstbetriebene Vektor-DB. Keine Embedding-Pipeline-Cronjobs zum Debuggen. Keine "hat jemand die Modell-Deprecation im letzten Quartal bemerkt"-Überraschungen. Keine Daten, die OCI in Richtung eines Drittanbieter-LLM verlassen. Keine maßgeschneiderte Integration zwischen vier beweglichen Teilen. Die Integration ist ein REST-Aufruf und eine Tool-Registrierung auf Anwendungsebene.

Das Wertvolle an OCI GenAI Agents ist nicht, dass es technisch neuartig ist. Es ist, dass es die sieben schlechtesten Wochen eines selbstgebauten RAG-Projekts entfernt.

Wo APEX-Agenten OCI-Agenten weiterhin schlagen

Nicht überrotieren. APEX KI-Agenten bleiben die bessere Antwort, wenn:

• Die Frage aus den eigenen Tabellen der Anwendung und den eigenen Berechtigungen des Nutzers beantwortbar ist.
• Die Aktion das Schreiben von Daten über klar definierte PL/SQL- oder REST-Tools beinhaltet.
• Die Interaktion kurz und transaktional ist, nicht explorativ.

OCI GenAI Agents übernehmen, wenn:

• Der Korpus aus unstrukturierten Dokumenten besteht.
• Die Antwort Passagen zitieren muss.
• Die Konversation Themen abdecken kann, die das Schema der Anwendung nicht darstellt.

Die saubersten Produktionsdesigns nutzen beides und lassen den APEX-Agenten zwischen ihnen routen.

Ein praktischer Startplan

1. Identifizieren Sie einen Dokumentenkorpus, auf den wiederkehrend Fragen kommen und dessen Eigentümer ihn aktuell halten können. HR-Policies, IT-Servicekatalog, interne Compliance-Handbücher sind gute erste Kandidaten.
2. Richten Sie einen OCI-Bucket ein mit striktem Zugriff. Entscheiden Sie, wer hochladen und wer löschen darf.
3. Provisionieren Sie einen OCI GenAI Agent gegen diesen Bucket. Testen Sie ihn über die OCI-Konsole, bevor APEX ins Spiel kommt.
4. Fügen Sie ein REST-Tool am KI-Agenten Ihrer APEX-Anwendung hinzu, das den OCI-Endpunkt mit einem Service-Principal-Credential aufruft.
5. Pilotieren Sie mit einer Nutzergruppe. Erfassen Sie die gestellten Fragen, die zitierten Dokumente und die Antworten, die Nutzer als unhilfreich markieren.
6. Iterieren Sie am Korpus, nicht am Modell. Die meisten Qualitätsgewinne kommen vom Verbessern der zugrundeliegenden Dokumente — klarere Titel, bessere Abschnittsstruktur, weniger veraltete PDFs.

Der architektonische Punkt

Das Muster, das 2026 für Enterprise-KI gewinnt, ist nicht ein riesiger Agent, der alles tut. Es sind viele schmale Agenten, jeder auf eine Domäne zugeschnitten, komponiert über klar benannte Tools. OCI GenAI Agents und APEX 26.1 zusammen erlauben Ihnen, diese Komposition zu bauen, ohne dass eine Komponente in die andere ausläuft. APEX bleibt die vertrauenswürdige Anwendungsfläche. OCI bleibt die verwaltete Wissensschicht. Der Anwender sieht ein Erlebnis. Der Auditor sieht saubere Grenzen. Das ist das Design, das skaliert.