← Projects
04 / 05

Model and explanatory API · 2026

Bitcoin sentiment analysis

An experimental pipeline for an especially noisy signal: it turns text into semantic embeddings, combines two LightGBM ensembles and translates each classification into an explanation with visible confidence, signals and limitations.

1. Project overview

Bitcoin Decision Chat is an educational web prototype that analyzes English messages about Bitcoin. It combines text classification with an assistant-generated explanation to provide a general orientation—“Invest” or “Do not invest”—based on the wording of a message. It is intended for people interested in exploring NLP applications in a financial context; its main contribution is bringing inference, explanation, and a simple interface together in one service. The orientation is experimental: it does not predict prices or constitute financial advice.

2. Problem and objectives

Market messages express opinions with incomplete context. The project explores how to turn a text about Bitcoin into a readable classification and explanation while making the limits of that interpretation clear.

The technical objectives are to accept messages in a controlled way, reject texts without a recognizable reference to Bitcoin, estimate their orientation with classification models, and provide an explanation that does not turn textual tone into a market prediction. Another goal is to keep a response available when the language provider fails.

3. Solution and architecture

The browser provides examples and a field for entering a message. The service validates and normalizes the text, then checks that it refers to Bitcoin. It converts the message into a semantic representation and queries two LightGBM ensembles in sequence. The first classifier evaluates negative signals; when its probability reaches the threshold, the second evaluates neutral signals. The thresholds determine the returned orientation. An OpenAI model then writes the explanation; if credentials are unavailable or a call fails, a local response is used. The interface displays the result and an informational notice.

Bitcoin Decision Chat architectureA validated message is normalised and embedded. Two LightGBM ensembles apply sequential thresholds to produce experimental guidance. OpenAI writes the explanation, with a local alternative when the service fails.Input and representationSequential classificationExplanationEnglish messagenegative prob. < thresholdnegative prob. ≥ threshold< thresholdneutral prob. ≥ thresholderror / no serviceUserWeb interfaceValidation and Bitcoin filterText normalisationSemantic embeddingEnsemble:negative signalsEnsemble:neutral signalsDo not investInvestGeneral guidanceOpenAI explanationLocal explanation

4. Development and technical decisions

The application is organized as a FastAPI service that serves both the static interface and analysis responses. This keeps the user flow and inference in one deployment and avoids placing language-provider credentials in the browser. The input contract limits messages to 800 characters and rejects empty entries. A lexical check requires a recognizable reference to Bitcoin or the crypto market before analysis begins.

Text preparation lowercases the input, removes links, mentions, and ticker symbols, preserves useful punctuation, and reduces repeated characters and whitespace. Consistent cleaning matters because the classifier works on a representation derived from text, not on market variables. Sentence Transformers generates the semantic embedding; LightGBM classifiers operate on that representation. Instead of one multiclass label, inference chains two ensembles. If the negative-class probability is below its threshold, the result is “Do not invest”; if it reaches the threshold, the neutral ensemble is evaluated. In that second stage, a neutral probability equal to or above its threshold yields “Invest”; otherwise the result is also “Do not invest.”

The explanation is a layer after classification; it does not determine the orientation. When OpenAI is configured, it receives the original text as untrusted data together with the model label and is instructed to explain the result without inventing probabilities or promising returns. If the call fails or no key is available, the system generates a local explanation. This means the external provider does not have to be available for the user to receive a result. The response also makes the uncertainty of the analysis clear.

For packaging, Docker prepares the model artifacts and embedding model during the build, and the service loads them in offline mode at startup. A single worker is used to limit duplicated model memory. FastAPI exposes health checks; the application also includes a request limit, security headers, and a generic response to internal errors. These decisions address operational concerns and credential protection.

The project also preserves a separate binary sentiment-classification iteration—positive or negative—with another API flow and threshold tuning on validation data. It is distinct from the sequential web application, and its results do not describe the latter’s performance.

5. Challenges and solutions

The flow needs to distinguish messages about Bitcoin from unrelated text; a preliminary filter rejects the latter before analysis. It also decouples the explanation from the generative provider’s availability through a local response, and packages the embedding model so startup does not depend on an external download.

6. Evaluation and results

The automated tests cover page delivery, health status, both orientation outputs, and rejection of messages unrelated to Bitcoin. Historical results come from binary-classification experiments and do not measure the web application’s sequential model. A documented predictive evaluation of the current system is therefore still needed.

7. Current state and future improvements

The code configures a web application and API, loads both ensembles from artifacts, and provides a generated explanation with a local fallback. The scope remains experimental and depends on the training data and labels. The next step would be to document each class’s protocol and evaluate the models on recent, representative messages, measuring errors and calibration at each stage. It would also be useful to evaluate ambiguous, ironic, or out-of-domain text.