Auf der diesjährigen Minds Mastering Machines (M3) Konferenz in Köln standen neben den neuesten Trends im Bereich Machine Learning besonders Sprachmodelle (LLM), aber auch der AI Act, AI Fairness und automatische Datenintegration im Fokus. Wir waren mit zwei talks zu unseren Projekten beteiligt.
Zusammen mit der Carl Remigius Fresenius Education Group (CRFE) entwickelten wir NextGeneration:AI. Dabei handelt es sich um eine datenschutzkonforme Plattform zur Nutzung von Sprachmodellen für alle Studierende und Mitarbeitende der CRFE. Das besondere an NextGeneration:AI ist die Authentifizierung über das Learning Management System Ilias mit Hilfe einer LTI-Schnittstelle, sowie die umfassende Personalisierbarkeit, die Nutzer:innen geboten wird. Im Blogartikel gehen wir auf die Details der Implementierung ein.
In diesem zweiten Teil zu Multi-Agenten-LLM-Systemen wird es um die Umsetzung komplexer Informationsflüsse mit Hilfe von LangGraph gehen. In Teil 1 wurde generell erklärt, warum Multi-Agenten-Systeme hilfreich sind und wie sie mit AutoGen umgesetzt werden können.
LangChain ist das populärste Framework für die Entwicklung von LLM-Applikationen. Es bietet nicht nur eine riesige Auswahl vordefinierter Text-Extraktionstools, Sprachmodelle und sonstiger Tools, sondern vor allem eine Hierarchie von Klassen. Typischerweise kombiniert man ein PromptTemplate mit einem LLM und optional einem Validator in einer Chain. Am einfachsten funktioniert dies durch die Nutzung der LCEL (LangChain Expression-Language), welche zwar etwas Gewöhnung erfordert, dafür aber kompakten und standardisierten Code ermöglicht.
dpunkt.verlag GmbHfrom langchain.output_parsers.boolean import BooleanOutputParser
from langchain.prompts import PromptTemplate
from langchain_openai import AzureChatOpenAI
prompt = PromptTemplate.from_template(
"""Decide if the user question got sufficiently answered within the chat history. Answer only with YES or NO!
Sentences like "I don't know" or "There are no information" are no sufficient answers.
chat history: {messages}
user question: {user_question}
"""
)
llm = AzureChatOpenAI(
openai_api_version="2024-02-15-preview",
azure_deployment="gpt-35-turbo-1106",
streaming=True
)
parser = BooleanOutputParser()
validator_chain = prompt | llm | parser
# Zum Aufruf der Chain müssen alle Prompt-Variablen übergeben werden
validator_chain.invoke({
"user_question": "Was sind die aktuellen Trends in Italien?",
"messages": ["die aktuellen Trends Italiens sind heute Formel 1 und ChatGPT"],
}) # Returns True
Natürlich wird auch die Ausführung von Funktionen (bzw. Tools) von LangChain unterstützt. Hierfür müssen wir zunächst die auszuführende Funktion in ein LangChain-Tool umwandeln. Dies kann explizit oder via Funktionsannotation erfolgen. Der Vorteil hierbei ist, dass die notwendigen Informationen für die Nutzung in einem Sprachmodell automatisch aus den Docstrings der Funktion extrahiert werden und somit Redundanzen vermieden werden können.
from pytrends.request import TrendReq
def get_google_trends(country_name='germany', num_trends=5):
"""
Fetches the current top trending searches for a given country from Google Trends.
Parameters:
- country_name (str): The english name of the country written in lower letters
- num_trends (int): Number of top trends to fetch. Defaults to 5.
Returns:
- Prints the top trending searches.
"""
pytrends = TrendReq(hl='en-US', tz=360)
try:
trending_searches_df = pytrends.trending_searches(pn=country_name)
top_trends = trending_searches_df.head(num_trends)[0].to_list()
return top_trends
except Exception as e:
print(f"An error occurred: {e}")
from langchain.tools import StructuredTool
google_trends_tool = StructuredTool.from_function(get_google_trends)
google_trends_tool.invoke(input={})
Anschließend muss das erstellte Tool dem Modell übergeben werden. Nutzt man ChatGPT, unterstützt das Modell natives function_calling, sodass das Tool lediglich mit Hilfe des Aufrufs bind_functions aktiviert werden muss. Nun kann das Modell einen entsprechenden Funktionsaufruf bei Bedarf triggern, um die Funktion aber auch automatisch auszuführen und die Ergebnisse dem Modell zurückzugeben, muss die Chain in einen Agenten überführt werden. Hierfür existiert eine eigene Klasse, die neben der auszuführenden Chain lediglich einen Namen und die auszuführenden Tools benötigt.
from langchain_core.prompts import ChatPromptTemplate, MessagesPlaceholder
from langchain.agents import create_openai_functions_agent
from langchain_core.utils.function_calling import convert_to_openai_function
from langchain_core.runnables import RunnablePassthrough
from langchain.agents.output_parsers.openai_functions import OpenAIFunctionsAgentOutputParser
from langchain.agents import AgentExecutor
from langchain_core.messages import HumanMessage
from langchain.agents.format_scratchpad.openai_functions import (
format_to_openai_function_messages,
)
from langchain_community.tools.tavily_search import TavilySearchResults
tavily_tool = TavilySearchResults(max_results=5)
tools = [google_trends_tool, tavily_tool]
system_prompt = "\\nYou task is to get information on the current trends by using your tools."
prompt = ChatPromptTemplate.from_messages([
("system", system_prompt),
MessagesPlaceholder(variable_name="messages"),
MessagesPlaceholder(variable_name="agent_scratchpad"),
])
agent = create_openai_functions_agent(llm, tools, prompt)
llm_with_tools = llm.bind(functions=[convert_to_openai_function(t) for t in tools])
agent = (
RunnablePassthrough.assign(
agent_scratchpad=lambda x: format_to_openai_function_messages(
x["intermediate_steps"]
)
)
| prompt
| llm_with_tools
| OpenAIFunctionsAgentOutputParser()
)
executor = AgentExecutor(name="Analyzer", agent=agent, tools=tools)
Mit der LangChain-Version 0.1 wurde zudem LangGraph als Konzept zur Implementierung von Multi-Agenten-Systemen eingeführt. LangGraph orientiert sich an der Idee von AutoGen, organisiert die Kommunikation jedoch nicht über einen freien Nachrichtenaustausch und geteilte Chat-Historie, sondern mittels eines Graphen. Das Interface orientiert sich an der beliebten NetworkX Python-Bibliothek und ermöglicht so eine flexible Komposition von gerichteten Graphen, welche auch zyklisch sein dürfen, also Schleifen enthalten können.
Zunächst wird ein Graph mit einem definierten Status definiert. Anschließend werden Knoten und Kanten hinzugefügt und ein Startpunkt gewählt. Kanten können statisch oder durch Bedingungen bestimmt werden, wodurch der Graph seine Dynamik erhält. Sowohl die Knoten wie auch die bedingten Kanten können einfache Python-Funktionen sein oder auch mittels LLM-Call bestimmt werden. Sie erhalten dafür jeweils den aktuellen State und geben einen neuen State für den nächsten Knoten zurück. Abschließend wird der Graph mit allen Knoten und Kanten zu einem “Pregel”-Objekt kompiliert.
from langchain_core.prompts import ChatPromptTemplate
from typing import TypedDict, Annotated, Sequence
import operator
from langchain_core.messages import BaseMessage
from langgraph.graph import StateGraph, END
compliance_prompt = ChatPromptTemplate.from_messages([
("system", """Make sure the answer is written in the same language as the user language.
The answer should be well-written in a formal style. It should use gender neutral language.
Modify the answer if necessary.
user question: {user_question}
chat history: {answer}
""")
])
compliance_chain = compliance_prompt | llm
class AgentState(TypedDict):
messages: Annotated[Sequence[BaseMessage], operator.add] = []
round: int = 0
workflow = StateGraph(AgentState)
def call_writer(data):
if data.get("round") is None:
round = 1
else:
round = data["round"] + 1
return {"round": round, "messages": [executor.invoke(data).get("output")]}
def call_compliance(data):
return {"messages": [compliance_chain.invoke({"user_question": data["messages"][0], "answer": data["messages"][-1]})]}
workflow.add_node("writer", call_writer)
workflow.add_node("compliance", call_compliance)
workflow.set_entry_point("writer")
workflow.add_conditional_edges(
"compliance",
lambda x: validator_chain.invoke({"user_question": x["messages"][0], "messages": x["messages"][1:]}) if x["round"]<2 else True,
{
True: END,
Fals4e: "writer"
}
)
workflow.add_edge('writer', 'compliance')
app = workflow.compile().with_config(run_name="Conduct Interviews")
app.invoke({"messages": [HumanMessage("Was sind die derzeit größten Trends in der Türkei?")]})
Dieser Pregel-Graph implementiert selbst das LangChain Runnable Interface, kann also synchron wie asynchron und als Stream- oder Batch-Operation ausgeführt werden. Typisch für LangChain wird die Komplexität selbst also möglichst vor dem Nutzer verborgen, was jedoch auch das Debugging erschwert. Sehr hilfreich ist in diesem Zug LangSmith, die von LangChain entwickelte Monitoring-Lösung. Die Integration erfordert lediglich einen API-Key, anschließend werden sämtliche Events in die Cloud gestreamt und dort in einer benutzerfreundlichen WebUI dargestellt. Diese bietet einen schnellen Einblick in sämtliche ausgeführte Operationen wie LLM-API-Calls, ausgeführte Tools und aufgetretene Fehler. Dazu werden Ausführungszeiten, generierte Tokens bzw. deren Kosten sowie zahlreiche System-Meta-Informationen getrackt.
Wer LangSmith nicht nutzen möchte oder mehr Kontrolle wünscht, kann dem Workflow einen eigenen Callback mitgeben und darin auftretende Events weiterverarbeiten. Beispielsweise eignen sich Callbacks auch, um eine eigene UI anzuschließen. Die Implementierung ist durchaus aufwändig, denn es existieren insgesamt 14 verschiedene Event-Typen, die bei Start, Ende und Fehlern von unterschiedlichen Aktionen relevant sind. In unserem Fall konnten wir leider nicht in jedem Event die gewünschten Informationen extrahieren, sondern mussten teilweise auf verlinkte Parent-Events zurückgreifen, sodass wir selbst einen Graph-Callback entwickelt haben, über den sich auch die Komplexität der versteckten Aufrufe innerhalb eines LangGraph-Calls visualisieren lässt.
| AutoGen | LangGraph | |
|---|---|---|
| Projektstatus | Als erstes Framework für Multi-Agenten-Systeme erfreut sich AutoGen großer Beliebtheit. Das Projekt wird durch Microsoft vorangetrieben, basiert aber architektonisch auf dem dünnen Fundament eines wissenschaftlichen Aufsatzes. | Die Multi-Agenten-Lösung des populärsten LLM-Frameworks wurde im Januar 2024 veröffentlicht. Sie nutzt erste Erfahrungen von AutoGen und kombiniert sie mit Ansätzen aus etablierten Open-Source-Projekten (NetworkX, Pregel). LangGraph wird als eine Komponente des LangChain-Ökosystems fortgeführt. |
| Function Calling | Bei Autogen werden sämtliche Funktionsausführungen durch einen idee proxy agent ausgeführt. Entweder nativ oder für mehr Sicherheit innerhalb eines Docker Containers. | In LangChain können Funktionen und Agenten selbst in Executables verwandelt werden. Das vereinfacht die Struktur, eine Kapselung von Funktionsausführung in einer separaten Sandbox wie bspw. einem Container ist derzeit nicht vorgesehen.. |
| Nachrichtenfluss | Die Kommunikation zwischen Agenten erfolgt innerhalb eines Gruppenchats prinzipiell frei und wird über einen group chat manager gesteuert. Dies bietet viel Flexibilität für Agenten, aber erschwert explizite Struktur. | Die Kommunikation wird durch einen Graphen abgebildet. Darüber lassen sich auch spezifische Kommunikationspfade einfach und intuitiv abbilden. Durch Conditional Edges sind aber auch komplett offene Gruppengespräche zwischen Agenten abbildbar. |
| Usability | AutoGen bietet mit seinen Beispielen und dem AutoGen Studio einen einfachen Einstieg in die Nutzung mehrerer Agenten. Möchte man jedoch nicht nur Prompts und Tools modifizieren, müssen die eigentlichen Agentenklassen erweitert werden, was Upgrades und Maintenance erschwert. | LangChain ist ein mächtiges Framework, das versucht, Komplexität vor dem Nutzer zu verstecken, ihn dafür aber abverlangt, zahlreiche Framework-Eigenheiten zu erlernen. Der hohe Grad an Abstraktion führt jedoch gerade zu Beginn oft zu Hindernissen. Hat ein Nutzer jedoch die Spezifika von LangChain verstanden, ist der Einsatz von LangGraph einfach und intuitiv. |
| Reifegrad | Autogen eignet sich hervorragend für einen Einstieg ins Thema Multi-Agenten, jedoch ist es schwierig, produktive Use-Cases hiermit umzusetzen. Gruppenkonversationen sind wenig verlässlich und es gibt keine Unterstützung bezüglich Monitoring und Ähnlichem. Durch die geteilte Chat-Historie der Agenten werden die ausgeführten Prompts schnell lang und damit teuer und langsam. | LangGraph ist eine noch junge Software auf einem gut durchdachten Fundament. Das LangChain-Ökosystem bietet zahlreiche Output-Parser und Möglichkeiten des Fehlermanagements. LangGraph bietet zudem eine genaue Kontrolle, welcher Knoten zu welchem Zeitpunkt welche Informationen verfügbar haben soll und Business-Anforderungen an den Kommunikationsfluss lassen sich flexibel abbilden. Zudem wird es durch seine Serving- und Monitoring-Infrastruktur unterstützt. |
AutoGen hat einen wertvollen Beitrag für Multi-Agenten-Systeme geleistet und eignet sich gut für erste Experimente. Wer allerdings eine genauere Kontrolle über die Kommunikation der Agenten wünscht oder eine produktive Anwendung bauen möchte, sollte eher auf LangGraph setzen. Wir selbst haben kürzlich eine existierende Anwendung von AutoGen auf LangGraph umgebaut. Während die Umsetzung der Agenten und Tools relativ einfach war, lagen die größten Aufwände in der Migration der UI-Anbindung, um via LangGraph-Callback alle notwendigen Informationen bezüglich Tool- und LLM-Nutzung abzubilden. Zudem unterstützen beide Frameworks bisher noch nicht nativ die parallele Ausführung von Agenten, wenn anschließend die Ergebnisse zusammengeführt werden sollen. Dennoch lässt sich sagen, dass sich mit LangGraph und LangSmith auch komplexe Workflows unter Einbeziehung von LLMs erstellen und betreiben lassen.
Nachdem 2023 große Sprachmodelle die Masse erreichten und Retrieval-Augmented-Generation-Use-Cases im Fokus der meisten Anwender lagen, rücken 2024 Agenten deutlicher ins öffentliche Blickfeld. Agenten sind (teil-)autonom arbeitende Instanzen, die es ermöglichen, Chat-Anwendungsfälle flexibler zu gestalten. Soll in einem Chat nicht immer das gleiche Dokumentenarchiv über RAG eingebunden werden, sondern je nach Use-Case unterschiedliche Informationsquellen herangezogen werden, so können Agenten beispielsweise selbstständig entscheiden, welche für eine Abfrage die richtige ist. Es können aber nicht nur Datenbanken bzw. nicht-textuelle Informationen integriert werden, sondern auch jeder IT-Prozess, von der Veröffentlichung von Inhalten auf der Website bis hin zur Erstellung und Ausführung von Softwarecode. Der Fantasie sind bezüglich dessen, was mit generativer KI möglich sein könnte, keine Grenzen gesetzt, doch die praktische Umsetzung stößt schnell auf Herausforderungen in Bezug auf Stabilität und Verlässlichkeit.
Dieser Blog-Post diskutiert, wann mehrere kollaborativ zusammenarbeitende Agenten hilfreich sein können. Er ist der erste einer Serie: In diesem werden die Bausteine eines Multi-Agenten-Systems erklärt sowie deren Umsetzung mit Autogen, der ersten Bibliothek speziell für Multi-Agenten-Setups. Der zweite Teil wird dann auf LangGraph eingehen, die kürzlich erschienene Bibliothek zur Umsetzung von Multi-Agenten-Workflows aufbauend auf die beliebte Bibliothek LangChain.
Zunächst sollte klar gestellt werden: Mehrere Agenten helfen nicht, wenn es darum geht, eine einzige Aufgabe besonders gut zu lösen. Ist die Aufgabe hingegen gut in mehrere Teilaufgaben zerteilbar, dann können mehrere, spezialisierte Agenten, die zusammenarbeiten, ein guter Ansatz sein. Wollt ihr beispielsweise Kundenanfragen automatisch beantworten, aber das Modell trifft nicht den Kommunikationsstil des Unternehmens, solltet ihr die Zeit lieber in Fine-Tuning stecken. Wenn für die Beantwortung aber verschiedene Informationsquellen erfragt, zusammengefasst und anschließend nochmal unter Berücksichtigung der Corporate-Communication-Policy validiert werden soll, könnte die Aufteilung auf mehrere Agenten hilfreich sein.
Sprachmodelle wie ChatGPT generieren nicht nur Text, sondern wurden inzwischen auch für Function Calling gefinetuned. Auf diese Art wurde ihnen prinzipiell das Konzept von Funktionsaufrufen erklärt. Allerdings können sie derzeit selbst keine Funktionen direkt aufrufen, sondern sagen lediglich, dass sie eine bestimmte Funktion mit gewissen Parametern aufrufen würden. Die tatsächliche Ausführung der Funktion erfordert dann eine entsprechende Runtime. Kombiniert man diese mit der Intelligenz des Sprachmodells, erhält man einen Agenten, der beispielsweise selbstständig Programmcode erstellen, ausführen und anhand der Fehlermeldungen debuggen kann. Ein solcher Agent ist ein besonders mächtiges Tool, da er im Gegensatz zu einem reinen LLM nicht nur in der Lage ist einen textuellen output zu generieren, sondern darüber hinaus selbstständig Handlungen planen und ausführen kann. Grundsätzlich können derartige Agenten mit den unterschiedlichsten Tools kombiniert werden, etwa zum Suchen von Informationen aus einer Datenbank, zum Abfragen einer WebAPI, zur Analyse von Bildern oder zur Erstellung einer Website. Natürlich kann man diese sehr unterschiedlichen Tools zur Ausführung alle in einem Agenten kombinieren, und einen genrealistischen Agent bauen; jedoch muss man dann Kompromisse machen. Manche Aufgaben erfordern ein besonders gutes und teures Sprachmodell, für andere reicht ein kleines Modell mit Fine-Tuning. Selbst wenn nur ein Modell für alles genutzt wird, empfehlen sich meist unterschiedliche Konfigurationen, etwa ein niedriger Temperature-Wert für Programmieraufgaben, ein höherer für kreatives Schreiben. Darüber hinaus brauchen Agenten, die etwa Informationen aus einer Datenbank extrahieren sollen, ausführliche Informationen zu Tabellenschemata im System-Prompt, sodass unterschiedliche Tools hier stark konkurrieren würden. Zu guter Letzt stellt sich die Frage, warum ein Agent alles gleichzeitig können sollte, wenn sich in der UNIX- und Microservice-Philosophie immer wieder gezeigt hat, dass unterschiedliche Aufgaben in unterschiedlichen Teilen behandelt werden sollten.
Autogen ist ein Framework zur Erstellung solcher Multi-Agenten-Systeme. Es basiert auf einem 2023 vorgestellten Paper und ist als Open-Source-Repository von Microsoft verfügbar. Im Autogen-Konzept sind Multi-Agenten-Systeme Gruppenkonversationen zwischen verschiedenen conversable_agent Objekte, die durch eine Python-Klasse manifestiert sind. Es gibt 3 Arten von Conversable Agents:
Das Basis-Konzept besteht darin, dass ein Agent einem anderen eine Nachricht sendet, mit der optionalen Bitte um eine Antwort. Kombiniert man nun mehrere solcher Agenten in einen Gruppen-Chat, so werden die Nachrichten nicht nur einem, sondern in der Regel allen Teilnehmern weitergeleitet, sodass eine gemeinsame Chat-Historie entsteht. Auf diese Art haben Agenten einen gemeinsamen Wissenspool und können auf der Arbeit der Vorgänger aufbauen. Hierfür finden sich bei Autogen zahlreiche Beispiele, etwa um mit Hilfe eines Programmierers zunächst relevante Paper herunterzuladen und diese von einem Produktmanager anschließend daraus Produktideen generieren zu lassen. Gleichzeitig führt dieses Vorgehen bei größeren und komplexeren Gruppengesprächen dazu, dass die Chat-Historie schnell wächst und Abfragen langsamer und teurer werden.
llm_config = {"config_list": config_list_gpt4, "cache_seed": 42}
user_proxy = autogen.UserProxyAgent(
name="User_proxy",
system_message="A human admin.",
code_execution_config={
"last_n_messages": 2,
"work_dir": "groupchat",
"use_docker": False,
},
human_input_mode="TERMINATE",
)
coder = autogen.AssistantAgent(
name="Coder",
llm_config=llm_config,
)
pm = autogen.AssistantAgent(
name="Product_manager",
system_message="Creative in software product ideas.",
llm_config=llm_config,
)
groupchat = autogen.GroupChat(agents=[user_proxy, coder, pm], messages=[], max_round=12)
manager = autogen.GroupChatManager(groupchat=groupchat, llm_config=llm_config)
user_proxy.initiate_chat(
manager, message="Find a latest paper about gpt-4 on arxiv and find its potential applications in software.")
Für zahlreiche Applikationen wäre es nützlich, nicht eine offene Gruppendiskussion zwischen allen Agenten zu führen, sondern den Gesprächsverlauf genauer zu kontrollieren. Auch dies ist mit Autogen prinzipiell möglich und es existieren ein paar Beispiele, wie etwa ein Schachspiel, bei dem zwei Spieler einerseits mit dem Spiel, andererseits miteinander kommunizieren. Hierfür müssen speziellere AssistantAgent-Klassen erstellt werden, welche mit Hilfe von register_reply zusätzliche Antworten-Funktionen registrieren. Der erste Parameter ist dabei als ein Filter zu verstehen, für welche Art von Nachrichtensender diese Antwortfunktion genutzt werden soll. In der Antwortfunktion wird im Fall von _generate_board_reply die besondere Logik des Schachspiels abgehandelt und ein Tuple aus True und dem gewählten Zug zurückgegeben. Das True besagt, dass die Funktion eine abschließende Antwort generiert hat und entsprechend keine weiteren registrierten Antwort-Funktionen ausgeführt werden sollen.
sys_msg = """You are an AI-powered chess board agent.
You translate the user's natural language input into legal UCI moves.
You should only reply with a UCI move string extracted from the user's input."""
class BoardAgent(autogen.AssistantAgent):
board: chess.Board
correct_move_messages: Dict[autogen.Agent, List[Dict]]
def __init__(self, board: chess.Board):
super().__init__(
name="BoardAgent",
system_message=sys_msg,
llm_config={"temperature": 0.0, "config_list": config_list_gpt4},
max_consecutive_auto_reply=10,
)
self.register_reply(autogen.ConversableAgent, BoardAgent._generate_board_reply)
self.board = board
self.correct_move_messages = defaultdict(list)
def _generate_board_reply(
self,
messages: Optional[List[Dict]] = None,
sender: Optional[autogen.Agent] = None,
config: Optional[Any] = None,
) -> Union[str, Dict, None]:
message = messages[-1]
# extract a UCI move from player's message
reply = self.generate_reply(
self.correct_move_messages[sender] + [message], sender, exclude=[BoardAgent._generate_board_reply]
)
uci_move = reply if isinstance(reply, str) else str(reply["content"])
try:
self.board.push_uci(uci_move)
except ValueError as e:
# invalid move
return True, f"Error: {e}"
else:
# valid move
m = chess.Move.from_uci(uci_move)
display( # noqa: F821
chess.svg.board(
self.board, arrows=[(m.from_square, m.to_square)], fill={m.from_square: "gray"}, size=200
)
)
self.correct_move_messages[sender].extend([message, self._message_to_dict(uci_move)])
self.correct_move_messages[sender][-1]["role"] = "assistant"
return True, uci_move
Mit Hilfe dieser Logik lassen sich prinzipiell vielfältige Kommunikationsmuster erstellen, in der Praxis wird diese Logik insbesondere bei komplexeren Setups diese Logik aber schnell kompliziert und unübersichtlich, denn der Nachrichtenfluss wird in vielen verschiedenen Klassen zerstreut definiert und hängt von Sender und Position der Antwort-Registration ab. Soll darüber hinaus auch gesteuert werden, wer welche Informationen erhält, so muss dies gesondert innerhalb des GroupChatManagers geregelt werden, was anspruchsvolle Kommunikationsflüsse weiter erschwert.
Fazit
Multi-Agenten-Systeme sind hilfreich, wenn komplexere (teil-)autonome Systeme gebaut werden sollen. Sie ermöglichen es, für jede Teilaufgabe einen speziellen Agenten zu definieren mit Hinblick auf Prompting, Modellauswahl und Konfiguration. Autogen war das erste Framework, das Entwickler bei der Definition solcher Systeme unterstützt und bietet zahlreiche Beispiele, insbesondere für offene Gruppengespräche. Sollen jedoch ein bewusst gesteuerter Informationsfluss realisiert werden, ist Autogen aufgrund seines Designs weniger geeignet. Hierfür empfehlen wir einen Blick in den zweiten Teil dieser Blogpost Reihe: Multi-Agenten-LLM-Systeme kontrollieren mit LangGraph
Nico Kreiling, Data Scientist bei scieneers GmbH
nico.kreiling@scieneers.de
Was ist Row-Level-Security?
Row-Level-Security (RLS) ist ein Konzept in Power BI, welches es ermöglicht, den Zugriff auf Daten auf Zeilenebene zu steuern. Mit RLS kann festlegt werden, welche Daten bestimmte Reportuser oder Usergruppen sehen dürfen, basierend auf definierten Rollen. Diese Rollen können auf verschiedenen Regeln bzw. Kriterien basieren, wie z.B. Benutzerrollen, Abteilungszugehörigkeit oder individuellen Berechtigungen. So können Sie sicherstellen, dass jeder Reportuser nur die Daten sieht, auf die er zugreifen darf und gleichzeitig die Datensicherheit und -integrität gewährleisten.
Wie implementiert man es & wo gibt es Probleme?
Um zu erklären, wie man RLS implementieren kann, wird als Beispiel ein Auszug der Adventureworks Sales LT DB herangezogen:
AdventureWorks Sales LT ist eine von Microsoft entwickelte fiktive Datenbank. Sie enthält typische Daten eines Unternehmens, insbesondere im Bereich Vertrieb (Sales), wie zum Beispiel Produkte, Bestellungen und Verkaufstransaktionen:
Für das Beispiel wird das Modell noch um die Tabelle SalesLT.Employee ergänzt, die Informationen über Mitarbeiter im Vertrieb enthält. Somit können Verkäufe Mitarbeitern zugeordnet werden, um nachzuvollziehen, wer für bestimmte Transaktionen verantwortlich ist.
Ein unkomplizierter und leicht umzusetzender Anwendungsfall für Row-Level-Security liegt vor, wenn der Kontext direkt aus den vorhandenen Daten abgeleitet werden kann. Beispielsweise, wenn Sales-Mitarbeiter Verkäufe tätigen, die in einem Report dargestellt werden sollen, um ihren Fortschritt zu verfolgen. In diesem Szenario ist es wichtig, dass jeder Sales-Mitarbeiter ausschließlich seine eigenen Verkaufszahlen einsehen kann.
Dies lässt sich einfach realisieren, da jedem Verkauf ein bestimmter Sales-Mitarbeiter zugeordnet werden kann. Die Umsetzung und Pflege gestalten sich ebenfalls unkompliziert, da lediglich eine Rolle definiert und verwaltet werden muss, um dieses Szenario abzudecken.
Es wird komplizierter, wenn der Bezug des Reportusers nicht aus dem vorhandenen Kontext der Daten abgeleitet werden kann, das heißt es keine direkten Verbindungen zwischen Reportuser und Records des Datenmodells gibt. Ein Beispiel hierfür sind Sales-Manager, die für unterschiedliche Regionen, Mitarbeiter oder Vertriebskanäle zuständig sind, jedoch keine eigenen Verkäufe vorweisen können. In solchen Fällen müssen für jede mögliche Ausprägung separate Rollen erstellt, zugewiesen und verwaltet werden, was sowohl zeitaufwändig als auch fehleranfällig sein kann, da dies händisch erfolgt.
Insbesondere bei einer großen Anzahl von Reports erhöht sich der Aufwand erheblich, da für jeden Report die individuellen Rollen gleichermaßen erstellt, zugewiesen und gepflegt werden müssen. Dies steigert das Fehlerpotenzial zusätzlich und erfordert eine umfassende Verwaltung der Zugriffsstruktur.
Lösung: Entwicklung von Security-Tabellen und pflege über eine grafische Oberfläche wie Power Apps
Eine Möglichkeit, diese Zugriffsstruktur bereitzustellen, ist die Entwicklung von Security-Tabellen. Hier werden die Berechtigungsattribute und die User losgelöst vom eigentlichen Datenmodell abgebildet und über Mapping-Tabellen (User_2_) einander zugeordnet.
Die Mapping-Tabellen werden anschließend aufbereitet und im Power BI-Datenmodell per DirectQuery an die entsprechenden Tabellen angebunden, sodass die vorgenommenen Änderungen an der Berechtigung auch sofort vollzogen werden.
Da Attribute immer auf die jeweiligen Email-Adressen der Reportuser gemappt werden, reicht hierfür eine einzige Rolle mit einer einfachen DAX-Formel pro Mapping-Tabelle im Dataset.
Ist diese Rolle allen Reportusern im Power BI Service zugewiesen, müssen die gesetzten Berechtigungen an einem Ort verwaltet werden. Hier kommt Microsoft Power Apps ins Spiel:
Power Apps ist eine Low-Code Plattform von Microsoft, die es Benutzern ermöglicht, benutzerdefinierte Unternehmensanwendungen ohne umfangreiche Programmierkenntnisse zu erstellen. Mit Power Apps können schnell und einfach interaktive Apps erstellt werden, die auf verschiedenen Geräten wie PCs, Tablets oder Smartphones laufen können. Die Plattform bietet eine Vielzahl von Vorlagen und Tools zur Gestaltung von Benutzeroberflächen sowie zur Integration von Daten aus verschiedenen Quellen wie Microsoft 365, SharePoint, SQL-Server und vielen anderen.
In dieser entwickelten Power App werden links in der Liste zu berechtigende Reportuser und rechts die bereits vergebenen Berechtigungen angezeigt. Über die Dropdown-Menüs kann dann die entsprechende Berechtigung gewählt werden. Die getroffene Auswahl wird nach dem Speichern in der App direkt in die Mapping-Tabellen geschrieben. Durch die bereits angesprochene Anbindung der Security-Tabellen via DirectQuery werden Änderungen direkt in das Power BI-Datenmodell übertragen und bietet so die Möglichkeit, schnell und flexibel auf Änderungen in der Berechtigungsstruktur zu reagieren.
Bei einer größeren Anzahl von Reports kann eine solche Lösung als zentrales Verwaltungstool eingesetzt werden und somit das oben erläuterte repetitive Zuweisen der Rollen pro Report durch einfache Klicks ersetzen. Zudem verschafft es einen Überblick aller vergebenen Rechte an einem Ort und beugt somit Fehler in der Zuweisung der Rollen vor.
Maximilian Leist, Power BI Developer bei scieneers GmbH
maximilian.leist@scieneers.de
In einer datengetriebenen Welt, in der die Entscheidungsfindung auf der Analyse von Daten beruht, ist das Konzept der Self-Service-Business Intelligence (BI) sehr wertvoll. Mit der Fülle an Informationen, die Unternehmen täglich sammeln, ist es ein entscheidender Vorteil für Mitarbeitende, selbstständig und auf einfache Art datengestützte Einsichten zu generieren. Hier kommt Power BI ins Spiel, ein leistungsstarkes Business Intelligence -Tool von Microsoft. Dieser Blog-Artikel stellt den typischen Power BI-Workflow in fünf Schritten vor, beschreibt die Umsetzung im Detail und gibt Tipps für jeden Schritt.
Self-Service BI ist ein Ansatz, bei dem die Enduser selbst Daten abfragen, aufbereiten und präsentieren können, ohne auf IT-Fachleute angewiesen zu sein. So können schnell und flexibel anwendungsspezifische Auswertungen erstellt werden, die eine datengetriebene Entscheidungsfindung unterstützen. Im Optimalfall wird dies ergänzend zu einem zentralen Analytics- oder BI-Team eingesetzt, welches die grundlegende Infrastruktur und zentralen Datasets verantwortet.
Power BI besteht aus drei Hauptkomponenten:
Das Schaubild verdeutlicht wie diese drei Komponenten zusammenspielen und so eine umfassende Self-Service BI-Lösung bereitstellen.
Der typische Workflow in Power BI umfasst fünf Schritte:
Dies ist ein zyklischer Prozess, da oft Feedback oder weiterführende Ideen zum Report entstehen, die du in den Report einbauen und einige Schritte wiederholen musst, um den Report erneut zu teilen. Darüber hinaus kann die Person, die den Report konsumiert hat, Ideen für ihren eigenen Report haben und das Datenset des Reports nutzen, um eigene Transformationsschritte oder Visualisierungen hinzuzufügen. Dazu muss die Person die notwendigen Rechte besitzen.
Die folgenden Kapitel fassen für dich die wichtigsten Punkte der einzelnen Schritte zusammen und geben dir einige nützliche Tipps an die Hand.
Das Laden von Daten in Power BI ist der erste Schritt um einen Report zu erstellen. Power BI kann Daten aus verschiedensten Quellen importieren, wie z.B. Excel-Dateien, CSV-Dateien, Datenbanken, Webseiten oder Online-Diensten.
Um Daten in Power BI zu laden, wählst du unter Start den Punkt Daten abrufen aus und klickst auf die Datenquelle, die du anbinden willst. Sollte die gewünschte Datenquelle nicht angezeigt werden, klicke ganz unten auf Weitere.
Je nach Datenquelle, die du anbinden möchtest, erscheint ein entsprechender Verbindungsdialog. Möchtest du z.B. eine lokale Datei anbinden, musst du in der Regel einen Pfad zu der Datei angeben.
Möchtest du dich mit einer Datenbanken verbinden, musst du die entsprechenden Serverinformationen eingeben.
Erfrage diese intern bei den zuständigen Personen, oder schlage sie in eurem Unternehmens-Wiki nach. Trage sie anschließend in den Verbindungsdialog ein.
Möchtest du dich mit einer Datenbank verbinden, musst du dich in der Regel authentifizieren, also anmelden. Sollte es hier Probleme geben, sprich mit Kolleg*innen, die die Datenbank bereits nutzen, oder gehe auch hier auf die zuständigen Personen zu. Der vorausgewählte Datenkonnektivitäts-modus Importieren kann ausgewählt bleiben. Bei DirectQuery handelt es sich um ein Feature für fortgeschrittene Power BI-Reportdesigner. Wenn du Interesse hast, erfährst du hier mehr.
Ist das erledigt, öffnet sich der Navigator, in welchem du je nach Datenquelle auswählen kannst, welche Arbeitsblätter, Tabellen oder Views du laden möchtest. Setze bei allen von dir benötigten Elementen einen Haken und wähle Laden aus. Nun sollte jede ausgewählte Tabelle im Datenpanel auf der rechten Seite von Power BI Desktop auftauchen. Klappst du diese auf, siehst du die verschiedenen Spalten.
Wenn du dir alle Daten, die du geladen hast, in tabellarischer Form angucken willst, kannst du dies tun, indem du auf der linken Seite von der Berichtsansicht auf die Tabellenansicht wechselst. Du hast erfolgreich die ersten Daten in deinen Report geladen!
Weitere Infos zum Anbinden von Daten findest du hier.
Tipps zum Laden von Daten
Oftmals liegen die Daten im Quellsystem nicht in der Form vor, wie du sie benötigst. Aus diesem Grund bietet dir der in Power BI Desktop integrierte Power Query-Editor eine Vielzahl von Möglichkeiten, um Transformationsschritte zu definieren. Zum Power Query-Editor gelangst du auf zwei Wegen:
1. Direkt beim Anbinden einer neuen Datenquelle. Hast du, wie im ersten Schritt beschrieben, eine Datenquelle angebunden, klickst du im Navigator-Fenster anstatt auf Laden auf Daten transformieren.
2. Aus der Power BI Hauptansicht. Möchtest du an einem späteren Zeitpunkt der Report-Erstellung deine Transformationsschritte erneut anpassen, öffnest du den Power Query-Editor jederzeit über den Button Daten transformieren in der Registerkarte Start deiner Power BI-Menüleiste.
Der Power Query-Editor öffnet sich anschließend in einem eigenen Fenster.
Auf der linken Seite des Fensters findest du deine Abfragen. In der Regel entspricht eine Abfrage einem Datenobjekt, z.B. einer Tabelle, das du in deiner Datenquelle ausgewählt hast. Über einen Doppelklick auf die Abfrage kannst du sie einfach umbenennen.
Für jede Abfrage kannst du mittels der Buttons im Menüband, oder über Rechtsklick auf die jeweiligen Spalten, Transformationsschritte definieren. Du kannst z.B. Spalten oder Tabellen umbenennen, Zeilen oder Spalten entfernen oder filtern und Datentypen ändern.
Der Power Query-Editor erfasst diese Schritte sequenziell im Bereich Abfrageeinstellungen unter Angewendete Schritte auf der rechten Seite.
In diesem Menü kannst du einzelne Schritte durch Klicken auf das Zahnrad-Symbol im Nachhinein anpassen, oder durch klicken auf das X entfernen. Weitere Möglichkeiten öffnen sich auch hier mit einem Rechtsklick auf einen bestimmten Schritt.
Jedes Mal, wenn die Daten einer Tabelle in deinem Report aus dem Quellsystem geladen werden, durchlaufen sie diese Schritte nacheinander von oben nach unten und werden abschließend in der Form in deinen Report geladen, die sie nach dem letzten Transformationsschritt haben. Beachte, dass die Daten im Quellsystem zu jeder Zeit von diesen Transformationen unberührt bleiben.
Hast du alle Transformationsschritte definiert und möchtest den Power Query-Editor verlassen, klickst du in der oberen linken Ecke auf Schließen und übernehmen.
Mehr Informationen und Beispieltransformationen findest du z.B. hier.
Tipps zum Transformieren von Daten
Ein großer Vorteil von Power BI ist es, dass es dir erlaubt, Daten aus verschiedenen Quellen in einem einzelnen analytischen Datenmodell zu kombinieren. Gerade aus diesen Datenkombinationen lassen sich oft wichtige Insights gewinnen, die ohne ein geeignetes Analysetool verborgen bleiben.
Für analytische Datenmodelle hat sich das sog. Sternschema als ausgereifter und performanter Modellierungsansatz erwiesen. Es ermöglicht schnelle und einfache Analysen aus verschiedenen Perspektiven. Wenn du also einen Report mit mehreren Tabellen erstellst, die sich inhaltlich aufeinander beziehen, solltest du überprüfen, ob du ein Sternschema anwenden kannst.
Im Sternschema unterscheidet man zwei unterschiedliche Arten von Tabellen
Unabhängig davon, aus welcher Datenquelle deine Daten stammen, nutzt du in Power BI in der Regel sog. Beziehungen, um verschiedene Tabellen in Relation zueinander zu setzen. Diese modellierst du in der Modellansicht in Power BI Desktop.
Um eine Beziehung zwischen einer Fakten- und einer Dimensionstabelle erstellen zu können, benötigst du eine Schlüsselspalte, welche in beiden Tabellen vorkommt. Als Schlüsselspalten eignen sich Spalten, die eindeutige Werte enthalten und so z.B. ein Produkt klar identifizieren. Beispiele können Produkt-Codes oder -IDs, Auftragsnummern oder eindeutige Sensornamen sein. Die Spalten müssen dabei nicht zwangsläufig den gleichen Namen haben.
Um eine Beziehung zwischen zwei Tabellen zu erstellen, ziehst du die beiden Schlüsselspalten in der Modellansicht per Drag-and-Drop aufeinander. Hat alles funktioniert, solltest du wie in der obigen Abbildung eine Verbindung zwischen den beiden Tabellen sehen. Fährst du mit dem Mauszeiger über eine Verbindungslinie, werden die beiden verbundenen Spalten in den Tabellen hervorgehoben. Ein sauber erstelltes Datenmodell spart dir eine Menge Arbeit und Ärger im nächsten Visualisierungs-Schritt und bei späteren Anpassungen. Investiere hier ausreichend Zeit um ein sauberes Modell zu erstellen.
Tipps zur Datenmodellierung
Nachdem du die benötigten Daten in deinen Report geladen hast, kannst du anschließend die Visualisierungsmöglichkeiten von Power BI Desktop nutzen, um einen möglichst ansprechenden und übersichtlichen Report zu kreieren. Visualisierungen erstellst und formatierst du über das Visualisierungs-Panel auf der rechten Seite. Power BI bietet standardmäßig eine Vielzahl von Visualisierungen an, mit der du in der Regel alle Darstellungsanforderungen umsetzen kannst. Du findest Balken-, Säulen- und Kreisdiagramme, aber auch Karten und Tabellen. Hier findest du eine Übersicht und Erklärung aller Visualisierungstypen.
Hast du in deinem Report gerade kein Visual ausgewählt, enthält das Visualisierungs-Panel allgemeine Informationen zu den verfügbaren Visualisierungen.
Wählst du ein bestimmtes Visual aus (in unserem Beispiel das Säulen-Diagramm), verändert sich das Panel leicht. Im oberen Menü (1) findest du jetzt einen weiteren Reiter, um die Darstellung deines Visuals anzupassen. Hier findest du Möglichkeiten, um bspw. Farben oder Schriftarten anzupassen.
Außerdem erscheint der Bereich mit den Daten-Buckets (2). Dieser Bereich sieht etwas anders aus, je nachdem, welches Visual du gerade ausgewählt hast. In diese Daten-Buckets kannst du per Drag & Drop Felder aus deinem Daten-Panel hineinziehen. Möchtest du z.B. das Datum auf der X-Achse darstellen, ziehst du die Datumsspalte in den Daten-Bucket mit der Beschriftung „X-Achse“.
Hast du deinem Report ein Visual hinzugefügt, aber noch kein Daten-Bucket befüllt, erscheint ein Platzhalterdiagramm.
Du kannst die Größe jedes Visuals anpassen, indem du es auswählst, und dann mit der Maus an einer der Ecken oder Kanten ziehst.
Unter dem Menüpunkt Einfügen findest du außerdem weitere Elemente, die für eine ansprechende Gestaltung deines Reports nützlich sind. So kannst du ähnlich wie in PowerPoint Textfelder, Buttons, Formen und Bilder einfügen.
In der linken unteren Ecke findest du außerdem die Möglichkeit, ein spezielles Layout für User zu gestalten, die deinen Report über die Handy-App konsumieren. Klicke hierfür einfach auf das Handy-Symbol. Direkt daneben findest du die Möglichkeit, deinem Report mehrere Seiten hinzuzufügen. Nutze dies, um für verschiedene Analysen eigene Seiten zu erstellen. So hältst du die einzelnen Seiten übersichtlich.
Weiterführende Infos zur Visualisierung in Power BI findest du hier.
Tipps zur Visualisierung:
Hast du deinen Report finalisiert, besteht der letzte Schritt darin, ihn im Power BI Service zu veröffentlichen, damit er von Kolleg*innen genutzt werden kann.
Hierzu nutzt du den Button Veröffentlichen in der rechten oberen Ecke des Menübandes, im Menüpunkt Start. Evtl. wirst du aufgefordert, dich mit deinem Microsoft-Konto anzumelden.
Im folgenden Dialog kannst du auswählen in welchem Arbeitsbereich du deinen Report veröffentlichen möchtest. Jeder User hat einen persönlichen Arbeitsbereich, der unter Mein Arbeitsbereich ausgewählt werden kann. Dort hast ausschließlich du selbst Zugriff. Nutze diesen Arbeitsbereich, um Dinge aus-zuprobieren, dich mit dem Power BI Service vertraut zu machen, oder um die Usability deines Reports im Power BI Service zu testen, bevor du ihn in einem anderen Arbeitsbereich veröffentlichst.
Die übrigen Arbeitsbereiche kannst du dir wie Gruppen- oder Team-Arbeitsbereiche vorstellen, in denen du mit einer bestimmten Gruppe von Usern Reports teilen und entwickeln kannst. So kann es z.B. einen Controlling-, einen Marketing- und einen Gesamt-Arbeitsbereich geben. Wie diese Arbeitsbereiche strukturiert sind und ob du die Rechte hast, um ggfs. neue Arbeitsbereiche anzulegen, hängt ganz von den Einstellungen und Entscheidungen ab, die dein Unternehmen getroffen hat.
Hast du deinen Bericht veröffentlicht und möchtest diesen im Power BI Service nutzen, öffnest du deinen Browser und navigierst zu app.powerbi.com und meldest dich mit dem selben Microsoft-Konto an.
Jetzt bist du im Power BI Service und hast eine Übersicht über die verschiedenen Funktionen. In diesem Guide werden wir nur auf einige Grundlagen eingehen, eine Erklärung der Funktionen des Power BI Services findest du hier.
In der linken Leiste findest du den Button Arbeitsbereiche. Klickst du dieses Fenster, öffnet sich eine Navigation, in der du zwischen allen Arbeitsbereichen wechseln kannst, zu denen du Zugriff hast. Sie stimmen mit der Auswahl überein, die dir auch beim Veröffentlichen aus Power BI Desktop angezeigt wurde.
Klickst du einen der Arbeitsbereiche an, wechselst du in diesen.
Innerhalb eines Arbeitsbereiches siehst du die enthaltenen Objekte. Außerdem kannst du neue Objekte erstellen, oder bestimmte Einstellungen für den Arbeitsbereich ändern. Veröffentlichst du einen Report, wird immer ein Objekt vom Typ Bericht und ein gleichnamiges Objekt vom Typ Semantikmodell (früher Dataset) erstellt.
Das Objekt mit dem Typ Bericht enthält deinen Report. Klickst du auf den Namen, öffnet sich dein Bericht in der User-Ansicht. Dies ist die Darstellung, in der auch andere User deinen Bericht sehen. Diese können deinen Bericht in dieser Ansicht in der Regel nur nutzen, aber nicht ändern. Sie können also z.B. nicht einfach Visualisierungen verschieben oder löschen.
Am oberen Rand findest du die sog. Aktionsleiste. Sie enthält Möglichkeiten, wie mit dem Bericht interagiert werden kann. Mache dich wenn möglich mit diesen Aktionen vertraut, z.B. hier. Als Owner eines Berichtes kannst du hier in der Regel alle Aktionen ausführen. Für andere User sind die Möglichkeiten eingeschränkter und hängen von ihren Rechten ab.
Wie oben bereits beschrieben, wird beim Veröffentlichen eines Berichts auch das dazugehörige Semantikmodell hochgeladen. Dies enthält das Datenmodell, welches du modelliert hast. Hat ein anderer User die notwendigen Rechte, kann er direkt auf diesem Datenmodell einen eigenen Bericht erstellen, ohne dass er ein eigenes Datenmodell erstellen muss. So lässt sich ggfs. viel Arbeit sparen.
Tipps zum Teilen von Reports:
In diesem Artikel haben wir uns eingehend mit den fünf Schritten des Power BI-Workflows beschäftigt: Daten laden, Daten transformieren, Daten modellieren, Daten visualisieren und Berichte teilen. Jeder dieser Schritte ist entscheidend für die Erstellung aussagekräftiger und informativer Berichte mit Power BI.
Aus Gründen der Kompaktheit sind wir in diesem Artikel nicht auf die Möglichkeit eingegangen, Reports und Sematikmodelle direkt im Power BI Service zu erstellen. Für Interessierte, die ihr Wissen über Power BI weiter ausbauen möchten, bieten wir fortgeschrittene Power BI-Trainings an. In diesen 2-stündigen Sessions werden verschiedene weiterführende Konzepte wie bspw. DAX-Measures vorgestellt. Mehr Informationen zu unseren Kursen und Trainings findest du auf unserer Webseite unter www.scieneers.de/power-bi-training-de/.
Die effektive Nutzung von Self-Service BI und insbesondere von Power BI erfordert sowohl Wissen als auch Übung. Es ist jedoch die Mühe wert. Mit diesen Fähigkeiten kannst du umfangreiche Datenanalysen durchführen, aussagekräftige Visualisierungen erstellen und Deine Erkenntnisse auf einfache Weise mit anderen teilen. Dies ermöglicht es Dir, informierte Entscheidungen zu treffen und Deine Arbeit effektiver zu gestalten.
350 Millionen, fast 5% der Weltbevölkerung leben mit einer seltenen Erkrankung. Etwa 75% der seltenen Erkrankungen betreffen Kinder. 80% dieser Erkrankungen entstehen durch eine einzige genetische Veränderung und können durch eine Genomanalyse diagnostiziert werden. Das menschliche Genom besteht aus etwa 3.3 Milliarden Bausteinen und jeder Mensch trägt etwa 3.5 Millionen Varianten. Die Suche nach der einen, pathogenen Variante, als Ursache der Krankheit, gleicht der Suche nach der Nadel im Heuhaufen.
In unserem Blogartikel zur Individualisierung von Konferenz-Programmen durch LLMs zeigen wir bereits einen Anwendungsfall von Textpersonalisierung durch den Einsatz von LLMs. Neben dem Individualisieren von Konferenz-Programmen anhand gegebener Interessen und Kenntnisse existieren weitere Anwendungsfälle im Bereich der personalisierten Generierung von Text. Daher haben wir die Personalisierung von Stellenausschreibungen durch LLMs anhand einer kurzen Personenbeschreibung getestet.
Erstmals durften wir bei den IT-Tagen 2023 im Dezember in Frankfurt dabei sein. Die Konferenz bietet einen vielfältigen Einblick in die IT-Welt, von Software-Architektur über Agile-Praktikten bis zum zu großen Sprachmodellen. Wir trugen mit zwei Vorträgen zu Unit-Testing und Personalisierung mit LLMs spannende Themen für Data Scientists bei.
Zusammen mit der RWTH Aachen University haben wir rwthGPT entwickelt: Eine datenschutzkonforme Plattform zur Nutzung von OpenAI-Modellen für Studierende und Mitarbeitende. Ergänzt wird rwthGPT durch ein dediziertes User-Management mit Kostenzuordnung, das Speichern von Chat-Verläufen und Talk to your Data. Wir werfen einen detaillierten Blick auf die Datenschutz-relevanten Aspekte.