liurenchaxin/docs/architecture/openbb_integration_architec...

7.1 KiB

OpenBB Integration Architecture for 炼妖壶 (Lianyaohu) - 稷下学宫AI辩论系统

Overview

This document outlines the architecture for integrating OpenBB v4 into the Lianyaohu 稷下学宫AI辩论系统. The integration aims to provide enriched financial data to the eight immortal agents while maintaining graceful degradation when OpenBB is not installed or available.

System Context

The Lianyaohu system is a multi-AI-agent debate platform rooted in traditional Chinese philosophy. The eight immortals (八仙) debate investment topics, leveraging data from multiple financial APIs. The system currently uses a "perpetual engine" based on 17 RapidAPI subscriptions. This architecture adds OpenBB as an optional, higher-level data source.

Key Components and Integration Points

1. Core Business Logic (src/jixia/)

a. engines/openbb_engine.py

  • Purpose: Primary interface to OpenBB v4 data.
  • Key Features:
    • Lazy loading of openbb library to prevent import errors if not installed.
    • ImmortalConfig mapping each immortal to a primary data provider (initially yfinance).
    • get_immortal_data method for agent-specific data retrieval based on specialty.
    • simulate_jixia_debate for testing and demonstration.
  • Integration Strategy:
    • Uses from openbb import obb for unified routing.
    • Handles different data types (price, historical, profile, news, earnings, etc.).
    • Provides fallback error handling returning APIResult objects.

b. engines/openbb_stock_data.py

  • Purpose: Utility functions for fetching stock and ETF data.
  • Key Features:
    • get_stock_data and get_etf_data functions.
    • Lazy loading of openbb.
    • Time window configuration.
    • Data formatting utilities.

2. Application Entry Point (app/)

a. tabs/openbb_tab.py

  • Purpose: Streamlit UI tab for visualizing market data.
  • Key Features:
    • _check_openbb_installed to detect availability.
    • _load_price_data with multi-level fallback (OpenBB -> demo JSON -> synthetic data).
    • KPI calculation from data.
    • Interactive charting with Plotly.
  • Integration Strategy:
    • Prioritizes obb.equity.price.historical, falling back to obb.etf.price.historical.
    • Handles various data frame formats and column names from different providers.
    • Graceful UI degradation with informative messages.

3. Data Models (src/jixia/models/)

(Note: This directory and specific model files were not found in the current codebase.)

  • Purpose: Standardized data models for financial data.
  • Proposed Implementation:
    • Define FinancialDataPoint, StockQuote, HistoricalPrice, etc.
    • Used by both OpenBB engine and existing perpetual engine for data abstraction.

4. Configuration (config/settings.py)

  • Purpose: Centralized configuration management.
  • Key Features:
    • No direct OpenBB configuration currently, but designed for extensibility.
    • Validates environment for hybrid AI provider modes.

Data Flow Architecture

graph TD
    A[User Request] --> B{OpenBB Installed?}
    B -- Yes --> C{OpenBB Data Available?}
    C -- Yes --> D[OpenBB Engine]
    C -- No --> E[Fallback to Demo/Synthetic Data]
    B -- No --> E
    D --> F[Format Data]
    E --> F
    F --> G[Return to Agent/UI]
  1. Agent Request: An immortal agent requests data via OpenBBEngine.get_immortal_data.
  2. OpenBB Check: The engine checks if OpenBB is available via lazy import.
  3. Data Retrieval: If available, the engine calls the appropriate obb.* function.
  4. Data Processing: The engine processes the result into a standardized APIResult.
  5. Fallback: If OpenBB is not installed or the call fails, an error result is returned.
  6. UI Request: The OpenBB tab requests data via _load_price_data.
  7. UI Fallback Chain:
    • Tries obb.equity.price.historical.
    • Falls back to obb.etf.price.historical.
    • Falls back to loading demo JSON files.
    • Finally falls back to generating synthetic data.
  8. Data Formatting: The UI formats the data for display, handling various column names and structures.

Component Interaction Diagram

graph LR
    A[Streamlit App] --> B[OpenBB Tab]
    A --> C[Debate System]
    C --> D[Immortal Agents]
    D --> E[OpenBB Engine]
    D --> F[Perpetual Engine]
    B --> G[_load_price_data]
    G --> H{OpenBB Available?}
    H -- Yes --> I[OpenBB obb]
    H -- No --> J[Demo/Synthetic Data]
    E --> K{OpenBB Available?}
    K -- Yes --> I
    K -- No --> L[Error Result]

Deployment Architecture

Environment Requirements

  • Python 3.8+
  • Optional: openbb>=4.1.0 (not in default requirements)
  • Standard project dependencies (Streamlit, etc.)

Configuration

  • No specific OpenBB configuration required for basic yfinance use.
  • Advanced providers (e.g., Polygon) would require provider-specific environment variables.

Scalability and Performance

  • OpenBB's provider system handles its own rate limiting and caching.
  • The lazy loading approach prevents unnecessary overhead if OpenBB is not used.
  • Fallback to demo/synthetic data ensures UI responsiveness.

Failure Handling and Degradation

OpenBB Not Installed

  • ImportError is caught in lazy loading.
  • Engine returns APIResult(success=False, error="OpenBB not installed...").
  • UI falls back to demo/synthetic data gracefully.

OpenBB API Call Failure

  • Exception is caught in get_immortal_data.
  • Engine returns APIResult(success=False, error="OpenBB call failed...").
  • Agent can decide how to handle the failure (e.g., switch to another engine).

UI Data Loading Failure

  • Multi-level fallback ensures data is always available for visualization.
  • Users are informed via UI messages if demo/synthetic data is being used.

Monitoring and Observability

Logging

  • OpenBB engine logs data requests and responses.
  • UI logs fallback events.

Metrics

  • Not currently implemented, but could track:
    • OpenBB usage frequency.
    • Fallback trigger rates.
    • Data load times.

Security Considerations

API Keys

  • OpenBB handles provider API keys internally.
  • Standard project security practices (Doppler, no hardcoded keys) apply.

Data Handling

  • Data is processed in memory and not persisted by the OpenBB integration components.

Future Enhancements

  1. Unified Data Model: Create standardized data models in src/jixia/models/ for seamless integration between OpenBB and other data sources.
  2. Provider Configuration: Allow dynamic configuration of data providers for each immortal.
  3. Enhanced UI Components: Add more detailed financial data visualizations and analysis tools.
  4. Debate Integration: Directly link debate outcomes to specific data points from OpenBB.
  5. Advanced OpenBB Routes: Integrate fundamental data, news, and alternative data sources from OpenBB.

Conclusion

This architecture successfully integrates OpenBB v4 into the Lianyaohu system while maintaining its core principles of graceful degradation and modular design. The lazy loading approach ensures that the system remains functional and performant regardless of whether OpenBB is installed, providing a robust foundation for future enhancements.