Configuration Management
Relevant source files
The following files were used as context for generating this wiki page:
Configuration management in this project is handled through a combination of dedicated Python configuration files for the backend sentiment analysis models, and environment variables for the frontend and API services. This approach separates the complex, layered logic of sentiment analysis from the operational settings of the application, such as API keys and service URLs. The system has evolved from a complex 9-layer framework to a more streamlined and actionable 5-layer framework, reflecting a focus on optimization and clarity.
Backend Sentiment Configuration
The core of the sentiment analysis logic is defined in Python dictionary structures within the config/ directory. These files define the keywords, weights, and metadata for different layers of analysis.
Sentiment Framework Evolution
The project contains two versions of the sentiment configuration, showing a clear evolution towards a more optimized and actionable framework.
- Version 1 (
sentiment_config.py): A comprehensive 9-layer framework. - Version 2 (
sentiment_config_v2_optimized.py): A refined 5-layer framework designed for actionable insights, reducing categories from 34 to 18.
The diagram below illustrates the simplification from the V1 to the V2 framework.
This diagram shows the transition from the initial 9-layer model to the optimized 5-layer model, which focuses on Who, Why, When, and How.
Sources: config/sentiment_config.py, config/sentiment_config_v2_optimized.py:10-17
V2 Framework Structure
The optimized 5-layer framework is designed to answer key questions for stakeholders. Each layer is a Python dictionary containing categories, which in turn hold keywords, weights, and other metadata.
A typical category configuration looks like this:
# config/sentiment_config_v2_optimized.py:29-45
'pssi_management': {
'description': 'Kritik ke PSSI, pengurus, dan manajemen federasi',
'keywords': [
'pssi', 'pengurus', 'federasi', 'fa', 'asosiasi',
'ketua umum', 'sekjen', 'eksekutif', 'ketum', 'erick thohir',
'manajemen', 'kebijakan', 'keputusan', 'sistem pssi', 'esco'
],
'action_points': [
'Reform struktur PSSI',
'Transparansi finansial',
'Profesionalisme manajemen',
'Audit internal'
],
'weight': 1.3,
'layer': 'target_kritik',
'priority': 'HIGH'
},
The five layers in the V2 framework are summarized below:
| Layer | File Key | Purpose |
|---|---|---|
| 1. Core Sentiment | CORE_SENTIMENT | WHAT feeling? - Basic emotion classification (positive, negative, neutral). |
| 2. Target Kritik | TARGET_KRITIK | WHO to blame? - Responsibility identification (PSSI, players, etc.). |
| 3. Root Cause | ROOT_CAUSE | WHY failed? - Problem diagnosis (tactical, technical, mental, systemic). |
| 4. Time Perspective | TIME_PERSPECTIVE | WHEN to fix? - Solution timeline (immediate, short-term, long-term). |
| 5. Constructiveness | CONSTRUCTIVENESS | HOW valuable? - Feedback quality (constructive, destructive, hopeful). |
| Sources: config/sentiment_config_v2_optimized.py:10-333, config/sentiment_config_v2_optimized.py:354-362 |
Model and Evaluation Configuration
The V1 configuration file also contains settings for the machine learning model training and evaluation process.
| Configuration | Key | Description |
|---|---|---|
| Model Config | MODEL_CONFIG | Defines the ensemble method (weighted_voting), base models (svm_linear, random_forest, etc.), cross-validation strategy (stratified_kfold), and hyperparameter tuning method (grid_search). |
| Evaluation Config | EVALUATION_CONFIG | Specifies primary metrics (accuracy, f1_score), secondary metrics (roc_auc), and target scores for each analysis layer. |
| Sources: config/sentiment_config.py:408-449, dashboard-next/app/settings/page.tsx:64-71 |
The model configuration from sentiment_config.py is reflected on the dashboard's settings page, which displays the model type, feature extraction method, and validation strategy.
Sources: dashboard-next/app/settings/page.tsx:64-71
Frontend and API Configuration
The Next.js frontend and its associated API routes rely on environment variables and hardcoded configurations for their operation.
Environment Variables
API keys and service URLs are managed via environment variables, as recommended in the project's README.md.
# .env
YOUTUBE_API_KEY=your_youtube_api_key
GEMINI_API_KEY=AIzaSyC79pEPb22JKUyXlmOjVt99vnLounyYvrY
Sources: README.md:200-202
These variables are consumed by the API routes:
YOUTUBE_API_KEYis used indashboard-next/app/api/live-comments/route.tsto fetch comments from the YouTube Data API.GEMINI_API_URLis a hardcoded URL (http://localhost:8000) in the same file, pointing to the backend Python API.
The sequence diagram below shows how these configurations are used in the live comments feature.
This diagram illustrates the data flow for fetching and analyzing live comments, highlighting the use of configured API keys and URLs.
Sources: dashboard-next/app/api/live-comments/route.ts:3-4, 218-221
Build Configuration
The PERFORMANCE_OPTIMIZATION_REPORT.md mentions enhancements to the Next.js build configuration in next.config.js to improve performance.
| Setting | Value | Purpose |
|---|---|---|
swcMinify | true | Enables fast minification using SWC. |
compress | true | Enables Gzip/Brotli compression for production builds. |
experimental.optimizePackageImports | ['recharts', ...] | Improves tree-shaking for specified libraries. |
| Sources: PERFORMANCE_OPTIMIZATION_REPORT.md:73-86 |
Unified Scoring System Configuration
To ensure consistency between the static (SVM) and live (Gemini) analysis, a "Unified Scoring System" is used. Its configuration is defined both in documentation and within the API code itself, serving as a fallback when the primary AI service is unavailable.
Fallback Lexicon
The dashboard-next/app/api/live-comments/route.ts file contains a analyzeSentimentFallback function with a hardcoded sentimentLexicon. This configuration ensures that even if the backend API fails, the system can still perform a reasonable sentiment analysis.
The lexicon is structured with weighted keywords:
// dashboard-next/app/api/live-comments/route.ts:7-22
const sentimentLexicon = {
positive: {
strong: ['sangat bagus', 'luar biasa', ...], // weight: 3
medium: ['bagus', 'mantap', 'keren', ...], // weight: 2
weak: ['lumayan', 'cukup', 'ok', ...] // weight: 1
},
negative: {
strong: ['sangat jelek', 'sangat buruk', ...], // weight: 3
medium: ['jelek', 'buruk', 'kecewa', ...], // weight: 2
weak: ['kurang', 'tidak', 'bukan', ...] // weight: 1
}
};
Sources: dashboard-next/app/api/live-comments/route.ts:6-29, UNIFIED_SCORING_SYSTEM.md:25-36
Scoring Thresholds
The system uses unified thresholds to classify sentiment based on the calculated scores. This logic is present in the fallback function and documented in UNIFIED_SCORING_SYSTEM.md.
| Parameter | Value | Description |
|---|---|---|
positive_threshold | 0.35 | Minimum ratio of positive score to total score for a positive classification. |
negative_threshold | 0.35 | Minimum ratio of negative score to total score for a negative classification. |
confidence_base | 0.6 | The base confidence level for a non-neutral classification. |
neutral_confidence | 0.65 | The default confidence for a neutral classification. |
| Sources: dashboard-next/app/api/live-comments/route.ts:41-57, UNIFIED_SCORING_SYSTEM.md:38-44 |
The backend API at /predict also accepts a model_type parameter (static, realtime, unified) which applies different score adjustments based on the desired behavior (conservative vs. aggressive), making the scoring system configurable at runtime.
Sources: UNIFIED_SCORING_SYSTEM.md:46-53, 80-87
Summary
Configuration in the "Analisis-Sentiment-Data_Mining" project is multifaceted. It uses structured Python files to manage the complex, domain-specific logic of the sentiment analysis models, allowing for versioning and clear definition of analytical layers. For the application's operational aspects, it employs standard practices like environment variables for secrets and API endpoints. Finally, it embeds configuration for a fallback mechanism directly into the API code, ensuring resilience and consistency through a unified scoring lexicon and thresholds. This layered configuration strategy effectively separates concerns and supports the project's dual-model architecture.