Tabular data and numeric prediction
On rows and columns from ERP, CRM or transaction logs, classical methods such as gradient boosting are often more accurate, cheaper and easier to explain. We do not force a language model onto that job.
Custom AI Models
Measurable AI models trained on your own data.
ALGOFACT builds forecasting, classification, anomaly detection and text models trained on a company’s own data. We first decide whether the job calls for classical machine learning or a fine-tuned language model, measure the model on a test set it never saw in training, and then put it into production with drift monitoring. Experiments run on PyTorch and MLflow, and the model can run in the cloud, on premises or hybrid. Delivery comes from our engineering offices in Türkiye, with a US entity in Delaware.
At a glance
Last updated:
- Model types
- Forecasting, classification, anomaly, text
- Approach
- Classical ML or a fine-tuned language model
- Measurement
- Held-out test set and a business metric
- Tooling
- PyTorch, MLflow, PostgreSQL
- Runtime
- Cloud, on premises or hybrid
- Information security
- ISO/IEC 27001:2022 certified ISMS
When is a custom model worth building?
An off-the-shelf AI service handles general questions well, but it does not know your product codes, your customers’ behavior or your failure history. A custom model learns a recurring decision your operation makes every day from your own history: which order will ship late, which transaction looks suspicious, which request belongs to which team. When the decision is frequent, mistakes cost money and the correct outcome has been recorded in the past, a custom model usually pays for itself.
If one of those three conditions is missing, we suggest a different first step. With no labeled history, start with data collection and labeling. When the decision is rare, a rule-based solution is cheaper. When the real problem is finding information, a RAG assistant that cites its sources is the better fit. If your data cannot support a model, we say so in writing at the end of the data review.
Decisions we build models for
What these examples share: the decision repeats every day and the right answer already sits in your historical records.
- 01
Demand and inventory forecasting
Product or branch level demand forecasts from sales, order and seasonal data. Planners see the uncertainty range next to the forecast and size stock accordingly. - 02
Risk and anomaly detection
Flags unusual patterns in transaction, payment or sensor data. A flagged record is not blocked automatically; it lands in an expert’s review queue. - 03
Classification and routing
Assigns requests, complaints, documents or product records to the right category and team. Records the model is unsure about go to a person. - 04
Prediction from specialist data
One of our published use cases, Dioscorium, is a cardiac prediction platform built on models developed from cardiology data (MVP). In projects like this the model supports the decision; the specialist makes it. - 05
Domain-tuned language models
Language models fine-tuned for summarization, information extraction and classification that use your terminology in contracts, technical reports or customer correspondence.
Other model work on /work includes AI-based student profile analysis (Akademi Deneme, Edufact), a real estate valuation platform with AI-based checks (Bora AI) and drone detection models for a confidential defense contractor.
Classical machine learning or a fine-tuned language model?
The shape of the data picks the method, not the hype cycle. We decide by comparing candidates on the same test set.
Free text and domain language
Where the task depends on what the text means, we first try a strong hosted or open model with instructions and examples. We fine-tune on your data only if that approach falls short on the test set.
Little data, costly errors
With few labeled examples we pair a simpler model with a solid rule layer and human approval. The model is retrained as data accumulates and the rules shrink.
Privacy and running cost
If data must stay in your environment we choose open models that run on your servers. The trade-off between cost per prediction and accuracy is settled by comparing candidates on the same test set.
How a model project runs
- 01
Decision and metric
We write down the decision the model supports, today’s error level and the business metric that defines success. The cost of a false alarm and of a missed case are discussed separately. - 02
Data review
We pull sample data from source systems and report missing fields, label quality and leakage risks such as columns that carry information from the future. - 03
Baseline and proof of concept
We build a simple baseline first and measure more complex approaches against it. Where risk is high, this stage is scoped as a short proof of concept. - 04
Training and validation
Every experiment is tracked in MLflow: which data, which parameters, which result. The final model is evaluated on a time-based test set that was never used in training. - 05
Production release
The model connects to your systems as an API or a scheduled batch job. Access control, logging and a rollback plan are ready before go-live. - 06
Monitoring and retraining
Input distributions and prediction quality are tracked continuously. When drift crosses a threshold, an alert fires and retraining starts on fresh data.
What you receive
- 01
Model and model card
The trained model plus a model card describing the training data, assumptions, known limits and situations where the model should not be used. - 02
Evaluation report
Test set results, error analysis by segment and a comparison with the baseline. - 03
Reproducible training pipeline
Versioned data preparation and training code that rebuilds the same model on demand. - 04
Prediction service and integration
The service that runs the model as an API or batch job, and its connections to your source systems. - 05
Monitoring dashboards and runbook
Drift and performance dashboards, alert rules and written procedures your team uses to operate the model.
Evaluation, drift and data protection
A model is at its best on the day it goes live. As customer behavior, the product range or data entry habits change, its performance slips quietly. That is why monitoring goes into the design rather than the last sprint: which inputs are watched, when the true outcome flows back into the system and which drop triggers retraining are all written down up front.
If the training data contains personal data, the requirements of the GDPR or Türkiye’s Personal Data Protection Law No. 6698 (KVKK) are handled during data preparation. Unneeded fields are dropped, masking or pseudonymization is used where possible and access to the training environment is limited per person. Legal assessment stays with your counsel; we design and implement the technical measures. All work runs under ALGOFACT’s ISO/IEC 27001:2022 certified information security management system.
Questions
Approach01How much data do we need to train a model?
There is no fixed number. It depends on how hard the task is, how many classes there are and how clean the data is. At the end of the data review we tell you in writing whether your data can support a model and where you need more data or labels.
02Do we always need to fine-tune a language model on our data?
No. For most text tasks, well-built instructions, examples and, where needed, document retrieval are enough. Fine-tuning is recommended when those methods fall short on the test set or when the model must run small and fast in your own environment.
03Can we see why the model made a decision?
For models on tabular data we can produce explanations that show the most influential features for each prediction. Where explainability is mandatory, as in credit, healthcare or hiring, we choose the model with that in mind and accept a little less accuracy for a more interpretable method when needed.
04Who runs the model after go-live?
At handover your team receives the training pipeline, monitoring dashboards and runbooks. If you want, an embedded team keeps retraining and improving the model after the first release.
05What drives the timeline and cost?
How ready the data is, how much labeling is needed, the number of systems to integrate, whether the model runs in real time or in batches, and the monitoring scope. After the discovery call and data review we present the scope, the phases and any proof-of-concept plan in writing.
Sources
- Personal Data Protection Law (Law No. 6698), Personal Data Protection Authority (KVKK)
Tell us about your project
Describe the problem briefly and we will reply with a time for a 30-minute discovery call.
Book a discovery call