When Prophet Meets Perceptron: Chasing Alpha with NP‑DNN

Accuracy is a dangerous word in finance.

It sounds clean. It fits nicely into a slide. It makes a model feel disciplined, measurable, and almost adult. A stock-prediction system with accuracy above 90% sounds like something a hedge fund would guard behind three NDAs and a biometric door.

That is exactly why we should slow down.

The paper Stock Market Price Prediction using Neural Prophet with Deep Neural Network proposes an NP-DNN pipeline: preprocessing, missing-value imputation, Z-score normalization, MLP-based feature extraction, a Neural Prophet-style forecasting component, a deep neural network predictor, and Optuna hyperparameter tuning.¹ The reported result is striking. The abstract says the proposed model reaches 99.21% accuracy compared with a fused LLM baseline. Later, the results section repeatedly states 93.21% accuracy on the Crunchbase dataset.

Those are not small numbers. They are also not self-explanatory numbers.

The useful lesson of this paper is not simply “Neural Prophet plus DNN predicts stocks better.” The more useful lesson is how quickly an AI-finance claim can become ambiguous when the dataset, task, metric, and business outcome do not quite line up. For anyone building AI investment tools, that ambiguity is not a footnote. It is the product risk.

The evidence trail starts with a mismatch, not a model diagram

The paper presents a stock-market price prediction method, but the experimental dataset is described as Crunchbase: a database of public and private companies, professional profiles, founders, investors, positions, financing rounds, and sampled LinkedIn profile data. The literature survey also compares against studies about startup funding success, founder prediction, startup descriptions, and investment-pattern classification.

That does not automatically make the paper useless. Crunchbase-style data can be valuable for venture screening, startup-success prediction, funding-pattern analysis, or private-company intelligence. But it is not the same object as market-traded stock-price time series.

This distinction matters because finance models are not evaluated in the abstract. A model is only as meaningful as the chain connecting:

1. the data it sees;
2. the prediction target it learns;
3. the metric used to judge it;
4. the decision a business would make from it;
5. the economic outcome after costs, risk, and timing.

In this paper, that chain is not fully closed. The paper talks about stock price prediction, but evaluates with classification-style metrics — accuracy, precision, recall, and F1-score — on a Crunchbase dataset. It also labels Figure 3 as a comparative analysis for RMSE, while the figure and surrounding text discuss classification accuracy and related metrics.

That creates the central interpretive problem. The reader sees “stock prediction” and “93.21% accuracy.” A business decision-maker may hear “tradable alpha.” The paper itself does not establish that bridge.

What the NP-DNN pipeline actually does

The proposed architecture is a layered pipeline. Its components are familiar, but the paper’s contribution is in arranging them into one stock-prediction workflow.

This architecture is not irrational. In fact, it reflects a common instinct in applied AI: use preprocessing to clean the data, use a neural component to extract nonlinear patterns, use a time-series model to capture temporal structure, and tune aggressively.

The problem is not the existence of these modules. The problem is that each module can make the system look more sophisticated without necessarily making the business claim more valid.

A model can be deep, tuned, and carefully normalized — and still be answering the wrong question.

The main result is performance reporting, not an investment test

The paper’s main empirical evidence appears in two places.

First, Figure 2 compares the proposed Optuna-tuned DNN setup with other optimization algorithms, including PSO, ACO, HHO, and GWO. The stated purpose is hyperparameter tuning: identify the optimizer that improves model accuracy and convergence. This is best read as an implementation and tuning comparison, not as independent proof of investment value.

Second, Figure 3 compares NP-DNN against existing approaches: DSS, LightGBM, RF, and LLM. The paper says NP-DNN performs better across metrics and reaches 93.21% accuracy on the Crunchbase dataset. This is the paper’s main comparative evidence.

The reported comparison is useful, but its interpretation needs discipline.

Notice the last row. The discussion says real-time information from microblogs and news sources can provide valuable insights and that advanced models are needed to process them. That is a plausible statement. But in the experiment as described, the input is Crunchbase. The discussion gestures toward richer market intelligence, while the experiment does not fully demonstrate that richer setting.

For a research summary, this is a limitation. For a business reader, it is a diagnostic alarm: the model narrative has expanded beyond the evidence trail.

The 93.21% figure sounds strong because the task boundary is unclear

A 93.21% accuracy result can be impressive, ordinary, or misleading depending on what is being classified.

If the model predicts whether a startup belongs to a success category in a dataset with strong historical patterns, 93% may indicate useful classification power — though one still needs class balance, validation design, leakage checks, and temporal splits.

If the model predicts whether a liquid stock will rise tomorrow after costs, 93% would be extraordinary. So extraordinary that it would demand unusually careful evidence: walk-forward testing, transaction-cost assumptions, slippage, drawdown, turnover, benchmark comparison, and live or paper-trading validation.

The paper does not provide those investment tests.

That is why the dataset/task mismatch matters. The same metric can carry very different business meaning depending on the decision context. “Accuracy” in a startup-data classification task is not equivalent to “alpha” in a public-market trading system.

A venture investor might use Crunchbase signals to prioritize companies for due diligence. A public-equity trader uses market data to decide position size, timing, stop-loss, and execution. These are not the same workflow wearing different jackets.

Classification metrics are not enough for price forecasting

The paper defines accuracy, precision, recall, and F1-score. These are standard classification metrics. They are useful when the model predicts labels such as positive/negative, success/failure, buy/not-buy, or category membership.

For stock-price forecasting, however, the usual questions are different:

• How large is the forecast error?
• Does the model beat naive baselines such as random walk or last-price persistence?
• Does it predict direction, magnitude, volatility, or tail risk?
• Is the signal stable through regimes?
• Does it survive transaction costs?
• Does it improve portfolio-level risk-adjusted return?

Classification metrics can still be relevant if the target is directional movement or trade signal classification. But then the target must be clearly defined. What exactly counts as a positive? A price increase? Funding success? A company classification? A future stock return above a threshold? The paper does not make that boundary sufficiently clear for an investment reader.

This is where a deceptively simple audit table helps.

This does not require a dramatic takedown. It requires careful reading. The paper may still be useful as a hybrid-model proposal. It is just not enough to claim deployable trading intelligence.

The architecture is more credible as a screening engine than a trading engine

One way to read the paper charitably is to reinterpret its business setting.

Instead of asking, “Can this forecast stock prices?” ask, “Could this architecture support company intelligence or startup screening?”

Under that framing, the ingredients make more sense. Crunchbase data contains company attributes, investor relationships, funding events, founder information, and profile signals. A model that combines structured data, nonlinear feature extraction, and time-aware components could plausibly help rank companies, classify funding prospects, or identify patterns in private-market data.

That is still valuable. It is just a different value proposition.

A private-market intelligence tool might use a similar architecture to answer questions such as:

• Which companies resemble previously funded firms?
• Which startup profiles show signals associated with later financing?
• Which sectors or founder patterns are changing over time?
• Which companies deserve analyst review before competitors notice them?

Those are not trivial questions. They are also not “buy this stock tomorrow.”

The distinction is not pedantic. It changes the user, the benchmark, the compliance risk, the data pipeline, and the ROI calculation.

A startup-screening system can tolerate a model that narrows a large universe into a smaller research queue. A trading system cannot hide behind “analyst review” if it is placing orders automatically. The cost of a false positive changes from “wasted diligence time” to “real capital loss.”

Where the paper’s design is still useful

The paper’s practical contribution is not a ready-made trading machine. Its more realistic contribution is a modular recipe for building prediction systems around messy financial or company data.

Three ideas are worth preserving.

First, preprocessing is not clerical work. Missing-value handling and normalization can materially affect model behavior, especially in heterogeneous business datasets. In real deployments, preprocessing quality often determines whether the model learns signal or simply memorizes data availability patterns.

Second, feature extraction matters when raw variables are weak or noisy. The MLP layer is meant to transform raw tabular inputs into more useful representations. That is a reasonable design choice for company datasets where relationships may be nonlinear: founder background, funding stage, sector, investor type, and organizational attributes rarely combine linearly.

Third, hyperparameter tuning should be treated as part of the model design, not an afterthought. Optuna is used to tune the DNN configuration. In business environments, this matters because a poorly tuned model can make a promising architecture look bad, while an aggressively tuned model can also overfit if validation is weak. The tuning step is powerful; therefore, it deserves governance.

That last sentence is where finance teams often become slightly allergic, and for good reason. Optimization is useful, but in noisy markets it can become a machine for discovering historical coincidences with excellent posture.

The missing bridge: from model score to financial decision

For a business team considering AI-based investment analytics, the question is not whether NP-DNN has an interesting architecture. It does. The question is what evidence would be needed before anyone puts it inside an investment workflow.

The answer depends on the workflow.

This is the practical pathway from the paper to business interpretation: use it as a due-diligence case, not as a deployable alpha claim.

The model family may inspire internal experiments. A company can test hybrid architectures combining time-series components, neural feature extraction, and automated tuning. But before the system touches capital, the evaluation must match the intended decision.

That sounds obvious. It is frequently ignored. Finance is full of models that perform beautifully against the metric they were given and badly against the job they were hired to do.

The result inconsistency is not cosmetic

The paper contains two different headline accuracy numbers: 99.21% in the abstract and 93.21% in the results, comparative analysis, discussion, and conclusion-like reporting. A casual reader may shrug and treat this as a typo.

A business reader should not.

The issue is not that 93.21% is low. It is still high. The issue is that internal inconsistency in a headline metric makes it harder to know which experiment is being discussed, what baseline was used, and whether the reported performance is reproducible.

In research-to-business translation, small reporting inconsistencies can have large downstream effects. A product team may copy the larger number into a pitch deck. A client may ask whether similar accuracy is achievable in their market. A manager may approve a prototype based on an inflated expectation. Somewhere later, a data scientist has to explain that the number was never the right KPI in the first place. A glamorous day for everyone involved.

A disciplined article should therefore not treat the inconsistency as a side note. It affects interpretation directly. When a paper’s headline claim is unstable, the burden shifts from “How impressive is the result?” to “What exactly was measured?”

A better validation design for this kind of model

Suppose a team wanted to build on this paper. What would a stronger version look like?

The answer depends on whether the target is public-market trading or private-company intelligence.

For public-market stock prediction, the validation design should include:

• a clearly defined target, such as next-day return, next-week direction, volatility bucket, or excess return over benchmark;
• chronological train/validation/test splits, not random splits that leak future structure;
• comparison against naive baselines, classical time-series models, tree-based models, and simple momentum/mean-reversion strategies;
• forecast-error metrics for regression tasks, such as MAE, RMSE, or MAPE where appropriate;
• directional metrics only when direction is the explicit target;
• portfolio metrics, including cumulative return, drawdown, Sharpe ratio, turnover, hit rate, and exposure;
• transaction costs and slippage assumptions;
• regime analysis across bull, bear, high-volatility, and low-liquidity periods.

For private-company screening, the validation design should be different:

• define the target as funding success, exit event, growth category, failure risk, or investor relevance;
• use time-based splits to test whether the model generalizes to future cohorts;
• report class balance and confusion-matrix behavior;
• test robustness by sector, geography, funding stage, and company age;
• compare against analyst rules and simpler models;
• measure workflow lift, such as how many successful companies appear in the top-ranked review bucket.

This is not bureaucracy. It is alignment. A model should be tested in the shape of the decision it is supposed to improve.

What Cognaptus infers — and what it does not

Here is the clean separation.

What the paper directly shows: it proposes a hybrid NP-DNN architecture and reports higher classification-style performance than selected DSS, LightGBM, RF, and LLM baselines on the Crunchbase dataset, with repeated reporting of 93.21% accuracy and one abstract-level claim of 99.21%.

What Cognaptus infers for business use: the paper is most useful as a reminder that AI-finance models need evidence-chain auditing. The architecture may be worth experimenting with for company intelligence, startup screening, or internal financial-data classification. It is not sufficient evidence for an automated trading product.

What remains uncertain: the exact prediction target, the relationship between Crunchbase data and stock-price forecasting, the cause of the 99.21% versus 93.21% discrepancy, the robustness of the result under time-based validation, and the model’s economic value after costs and risk controls.

That uncertainty does not make the paper irrelevant. It makes the paper a good example of why model evaluation must be designed backward from business use.

The real business lesson: audit the claim before admiring the architecture

There is a familiar failure mode in AI adoption. A team sees a complicated architecture, a strong metric, and a finance-flavored title. The architecture creates confidence. The metric creates urgency. The finance label creates budget.

Then someone asks the inconvenient question: “What decision can we safely make with this?”

That question should arrive earlier.

For this paper, the answer is not “trade with NP-DNN.” The better answer is: use NP-DNN as a prompt to design better internal experiments, especially if your business deals with messy company data, funding signals, or hybrid structured/unstructured financial intelligence. But do not let the phrase “stock prediction” do more work than the experiment actually supports.

The model stack — Neural Prophet, MLP, DNN, Optuna — is not the weak part by itself. The weak part is the gap between reported classification performance and the stronger claim readers may be tempted to hear: reliable, deployable, tradable market prediction.

In finance, the most expensive errors often begin as small translation errors. Accuracy becomes alpha. Classification becomes forecasting. Dataset performance becomes investment performance. A model comparison becomes a strategy. A chart becomes a mandate.

NP-DNN may be an interesting architecture. But the smarter lesson is colder and more useful: before chasing alpha, check whether the model has even been asked an alpha-shaped question.

Cognaptus: Automate the Present, Incubate the Future.