Tipp: Erstelle flexibles Deep-Research-System mit OpenAI-API für geringe Kosten.

Tiefgründige Forschung mit dem OpenAI-API-Schlüssel – Ein praktischer Leitfaden Es ist kein Geheimnis, dass tiefgründige Forschungsmodelle (Deep Research, DR) die Welt des Web-Scrapings und der Analyse revolutionieren. Diese Modelle können ihre Forschungsschritte planen, Hunderte von Websites durchsuchen und selbstkorrigierende Maßnahmen ergreifen, was ihre Leistung gegenüber regulären Sprachmodellen erheblich verbessert. Allerdings sind diese Fähigkeiten nicht kostenlos. Bis Juli 2025 begrenzt ChatGPT Plus-, Team-, Enterprise- und Edu-Benutzer auf nur 25 DR-Anfragen pro Monat, während Pro-Benutzer 125 DR-Anfragen (plus 125 zusätzliche „leichte“ Anfragen) erhalten. Freiwillige Benutzer haben keine Möglichkeit, tiefgründige Forschungen anzufordern, obwohl OpenAI angibt, dass fünf „leichte“ Anfragen immer noch verfügbar sind. Um den steifen Abonnementmodell zu entgehen und nach Bedarf zu zahlen, kann ein eigenes Forschungsassistentensystem mit dem OpenAI-API-Schlüssel erstellt werden. Dies erfordert etwas Skriptgeschick, aber es ist durchaus machbar. Der OpenAI API bietet zwei DR-Modelle: „o3-deep-research“ und „o4-mini-deep-research“. Weitere Modelle sollen in Kürze erscheinen. Grundlagen Das einfachste Vorgehen bei der tiefgründigen Forschung mit dem OpenAI API besteht in einem einzigen Aufruf der Responses API: python system_message = """Sie sind ein professioneller Forscher und erstellen einen strukturierten, datengeführten Bericht im Auftrag eines globalen Gesundheitsökonomieteam. Ihre Aufgabe ist es, das Gesundheitsproblem des Nutzers zu analysieren. Seien Sie analytisch, vermeiden Sie Allgemeinplätze und stellen Sie sicher, dass jeder Abschnitt durch datengeführte Argumentation gestützt wird, die für Gesundheitspolitik oder Finanzmodellierung relevant sein könnte.""" user_query = "Untersuchen Sie den Einfluss von Semaglutid auf globale Gesundheitssysteme." response = client.responses.create( model="o3-deep-research", input=[ { "role": "developer", "content": [ { "type": "input_text", "text": system_message, } ] }, { "role": "user", "content": [ { "type": "input_text", "text": user_query, } ] } ], reasoning={ "summary": "auto" }, tools=[ { "type": "web_search_preview" }, { "type": "code_interpreter", "container": { "type": "auto", "file_ids": [] } } ] ) Einige wichtige Punkte zu diesem Snippet: - Das DR-Modell muss eine Web-Suche konfiguriert haben, um zu funktionieren. - Ein gesandter Code-Interpreter ist verfügbar, wird aber selten verwendet, da statistische Berechnungen oft nicht erforderlich sind. - Die Verwendung eines MCP-Servers ist ebenfalls möglich, bleibt aber auf die Funktionen „search“ und „fetch“ beschränkt. Architektur Wir verwenden den OpenAI Agents-Framework und modifizieren den Workflow. Wir können die Phasen der Prompt-Engineering überspringen und uns auf automatische Iterationen über die Ergebnisse konzentrieren. Das Diagramm zeigt, wie der Research-Agent das DR-Modell ausführt und dieser initiale Bericht vom Critique-Agent infrage gestellt wird. Wenn der Research-Agent das Forschungsergebnis als unzureichend ansieht, kann eine weitere Durchlaufung angefordert werden. Der Report-Agent fasst die Forschung und die Kritik zusammen und liefert den endgültigen Bericht. Das System ist auf maximal zwei DR-Durchläufe begrenzt, um Kosten zu sparen und den Ertrag abzuschwächen, wenn das Thema von mehreren Lookups nicht profitiert. Arbeit mit Modellbegrenzungen Da DR-Modelle keine Handovers unterstützen, müssen wir die Kontrolle programmatisch vom Research-Agent zum Critique-Agent übertragen. Die Critique-Agent kann ein reguläres Reasoning-Modell verwenden, um die Forschungsergebnisse zu überprüfen und gegebenenfalls erneut zum Research-Agent zurückzukehren. Für Web-Suchen und das Nutzen von MCP-Tools und benutzerdefinierten Tools müssen wir diese Funktionen dem Critique-Agent zuweisen. Ereignisverarbeitung Ein Parser für rohe Ereignisse muss implementiert werden, um Web-Suchen, Reasoning-Zusammenfassungen, MCP-Lookups und Toolaufrufe abzufangen. Zudem müssen wir die Token-Verwendung erfassen, um abschließende Kostenschätzungen bereitzustellen. Pipelining Übergänge zwischen Agenten bieten eine natürliche Stelle, um Ausgaben zu erfassen und die nächste Phase separat zu starten, falls gewünscht. Dies ist besonders nützlich für feine Anpassungen der Kritik oder Berichterstattung, ohne die Abfrage des Research-Agents erneut auszuführen. Implementierung Unsere Agentenfabrik gibt drei Arten von Agenten zurück: Research, Critique und Report-Agenten: ```python return Agent( name="ResearchAgent", instructions=research_instructions, model=MODEL_RESEARCH, model_settings=ResearchAgents._create_base_model_settings(), tools=[ WebSearchTool(), CodeInterpreterTool(tool_config=CodeInterpreter( type="code_interpreter", container={"type": "auto", "file_ids": []} )), ], handoffs=[] ) ... return Agent( name="CritiqueAgent", instructions=critique_instructions, model=MODEL_CRITIQUE, model_settings=ResearchAgents._create_base_model_settings(), tools=[ WebSearchTool(), verify_url ], handoffs=handoffs ) ... return Agent( name="FinalReportAgent", instructions=final_report_instructions, model=MODEL_FINAL_REPORT, model_settings=ResearchAgents._create_base_model_settings(), tools=[ CodeInterpreterTool(tool_config=CodeInterpreter( type="code_interpreter", container={"type": "auto", "file_ids": []} )), WebSearchTool() ] ) ``` Nur der Critique-Agent verwendet normale Handovers und kann entscheiden, die Kontrolle zurück an den Research-Agent oder an den Report-Agent zu übertragen. Zudem wird der Critique-Agent mit benutzerdefinierten Tools und einem MCP-Server ausgestattet: ```python async def create_critique_agent_with_mcp(research_agent=None) -> tuple[Agent, MCPServerSse]: deepwiki_server = MCPServerSse( params={ "url": "https://mcp.deepwiki.com/sse", "timeout": 30, "sse_read_timeout": 600, }, client_session_timeout_seconds=60.0, cache_tools_list=True, name="DeepWiki" ) await deepwiki_server.connect() agent = ResearchAgents.create_critique_agent(research_agent) agent.mcp_servers = [deepwiki_server] agent.mcp_config = { "convert_schemas_to_strict": True, "timeout": 30, "request_timeout": 60 } return agent, deepwiki_server ... def verify_url(url: str) -> Dict[str, Any]: if not url or not isinstance(url, str): return { "success": False, "status_code": None, "error": "Ungültige URL angegeben – muss ein nicht leerer String sein", "accessible": False, "response_time_ms": None } ``` Diese Tools repräsentieren die Workloads, die für meine Anwendung wichtig sind. Sie sollten je nach Anwendungsfall angepasst werden. Ich nutze DeepWiki, um Fragen zu GitHub-Repositories zu beantworten, und die verify_url()-Funktion, um zu prüfen, ob bestimmte API-Endpunkte und Websites existieren. Kostenschätzung Die Kostenschätzung wird automatisiert, indem der Report-Agent die Preise auf der OpenAI-Webseite abruft und dann mit den Token-Statistiken, die wir im Ereignisprozessor sammeln, multipliziert. Dies ist jedoch nur eine approximative Methode und sollte nicht für die Produktion verwendet werden. Konfiguration und Fehlerbehandlung Die Konfiguration unseres DR-Apps besteht hauptsächlich darin, benutzerdefinierte Tools (oder einen MCP-Server) hinzuzufügen, um die für Ihren Anwendungsfall relevanten Forschungsergebnisse zu verifizieren. Zudem müssen entsprechende Teile der Critique-Agent-Prompts in research_agents.py angepasst werden, um die verfügbaren benutzerdefinierten Tools widerzuspiegeln. Der Erfolg unserer DR-Abfragen hängt primär von der Fähigkeit ab, OpenAI-Modellanfragen erfolgreich abzuschließen. Abhängig von Ihrem Service-Tarif kann der OpenAI-Endpunkt zu unterschiedlichen Zeiten stark belastet sein. Wenn Ihre Anfrage abgelehnt wird, sehen Sie möglicherweise eine Fehlermeldung wie folgt: ERROR:openai.agents:Error streaming response: An error occurred while processing your request. You can retry your request, or contact us through our help center at help.openai.com if the error persists. Please include the request ID req_8c8c09a17f9544755961ba9a624ee920 in your message. ❌ Error: Workflow execution failed: An error occurred while processing your request. You can retry your request, or contact us through our help center at help.openai.com if the error persists. Please include the request ID req_8c8c09a17f9544755961ba9a624ee920 in your message. Wenn dies passiert, versuchen Sie es einfach ein paar Minuten später erneut, wenn die Last geringer ist. Alternativ können Sie den Rückgabecode überprüfen, um zu sehen, welcher Teil nicht abgeschlossen wurde: bash python main.py -q "query" -cvri case $? in 0) echo "Erfolg!" ;; 1) echo "Ungültige Argumente" ;; 2) echo "Research-Agent fehlgeschlagen" ;; 3) echo "Critique-Agent fehlgeschlagen" ;; 4) echo "Final-Report-Agent fehlgeschlagen" ;; 5) echo "Allgemeiner Fehler" ;; esac Verwendungsexempel Hier ein Beispiel, wie ein vollständiger Lauf der App aussieht: bash $ export QUERY="Vergleichen Sie Agenten-Handovers in Google ADK, LangChain und OpenAI Agents" $ python agentic_research.py -q "$(echo $QUERY)" -cvri Im ersten (Forschungs-)Schritt durchläuft die App einen langen Zyklus von Web-Suchen, gefolgt von Reasoning-Zusammenfassungen. Dies kann je nach Komplexität von zwei bis zehn Minuten dauern. Danach tritt die Kritikphase ein, in der der Critique-Agent die Ergebnisse überprüft und gegebenenfalls weitere Insights fordert. Fazit Dieser Ansatz ermöglicht es, tiefgründige Forschungen kosteneffizient und nach Bedarf durchzuführen. Die Gesamtkosten für einen kompletten Lauf betragen etwa 1,5994 USD, was deutlich günstiger ist als das monatliche Abonnement von 199 USD für den Pro-Plan. Das Repository mit dem Code ist auf GitHub verfügbar.