How TenderYeti's AI scoring works

Methodology as of August 2026

This page explains how we score every incoming government tender for relevance to your business. It's technical and honest — we tell you which models we use, what data goes where, and where the system's real limitations lie. If you're evaluating TenderYeti against a competitor, this is the page to read.

1. What "relevance score" actually means

Every tender we index gets a score between 0.00 and 1.00 against the natural-language business description you set in your account. A score of 0.85 means the AI is confident the tender is a fit; 0.15 means confidently not. Your daily digest email is filtered by a threshold you control (default 0.60), so you decide how much noise you want to let through.

The score is relative to your business description — not an absolute quality rating of the tender. The same notice can score 0.9 for a CMMS vendor and 0.05 for a construction firm.

2. What the AI actually reads

For every tender we send the LLM the full notice body (title + description + buyer + notice type + country + procurement category + estimated value where present), not just the title. That matters because a large fraction of relevant tenders are titled generically ("Software services — framework agreement") and have the actual intent buried in the requirements section.

Full-body reading is why we can catch tenders that keyword search misses. It's also why AI-scoring is a defensible edge — you can't replicate it with a saved-search alert on TED or SAM.gov.

3. Two-tier LLM review

Every tender goes through a fast primary model first. Notices with a confident verdict (score ≤ 0.40 or ≥ 0.70) are settled at that step. Notices that fall in the uncertain band (0.40–0.69) are re-scored by a second, larger review model. This gives us the throughput of a small model on the easy cases plus the judgement of a larger model on the borderline cases — the ~15% of notices where getting the score wrong actually costs you a missed opportunity.

Both models see the same prompt: your business description, the tender content, and structured instructions to emit a score plus a one-sentence rationale plus a matched-keywords list. The rationale is stored alongside the score so you can see why the AI graded a tender the way it did, and you can flag disagreements from the dashboard.

4. Multilingual matching

Your business description is written in one language (typically English). Tenders arrive in 20+ languages — German, French, Spanish, Portuguese, Italian, Dutch, Polish, Russian, Turkish, Arabic and more. We handle the mismatch two ways:

• Keyword expansion. We maintain a curated dictionary of 2,660+ translations for common bid-team keywords across 20 languages. Your English keyword "permit to work" also matches "Arbeitserlaubnis", "permis de travail", "permesso di lavoro", "разрешение на работу", etc. New keywords you add are auto-translated on the fly via an internally-hosted NMT model and cached.
• Full-text pre-filter. Before an LLM ever looks at a tender we filter on the multilingual keyword set at the PostgreSQL level — a coarse "could this be relevant?" gate. Notices that pass go to the LLM for the actual scoring. This lets us process 500,000+ tenders per day without exhausting AI budget.

5. Per-user precedence

On the Pro plan, each user in a tenant can override the shared AI prompt with their own. A senior partner tracking $10M+ framework agreements and a junior analyst tracking transactional RFQs on the same team see different scores for the same tender, because each sees the score generated against their own business description. The scoring layer double-joins so the caller's own score wins over the tenant fallback.

6. What we do NOT do (and won't claim)

• We don't publish a calibrated precision/recall number. We haven't run an independent-panel study. Anyone who claims "94.7% accurate" without a public evaluation methodology is quoting a number they made up. Ours would be too. What we can say: internal spot-checks with real customers hit >90% precision at threshold 0.60 across HSE-software and CMMS niches. Your mileage will vary by domain.
• We don't train on your keywords or on your tender-relevance judgements. Your business description is a prompt, not a training signal. We don't fine-tune anything customer-specific.
• We don't send your account or billing data to the LLM. Only the public tender text plus your business description go to the model provider.
• We don't guarantee zero false negatives. A tender the AI scores 0.30 might still be a fit for you. That's why the dashboard shows the whole spectrum, not just the digest — the digest is the shortlist, not the whole picture.

7. Which model provider we use

Today the primary + review models are self-hosted open-weight instruction-tuned models (Qwen 2.5 family) running on our own GPU infrastructure. That gives us cost control, privacy control (no vendor lock-in, no per-token bill), and the ability to swap models without rewriting integrations. When we do use hosted providers (translation, fallbacks), the only data sent is the public tender text plus your English keyword list — never account or billing data. Our sub-processor list is in the Privacy Policy.

8. How we handle mistakes

Every user can flag a tender's AI verdict from the dashboard ("this was scored high but is irrelevant" or "this was scored low but I would have bid"). Flags land in an internal review queue. We periodically inspect flagged tenders to spot systematic gaps — usually a keyword-expansion miss or a business-description that's too generic. We tune the multilingual dictionary and the prompt guidance based on real feedback, not on synthetic benchmarks.

9. Data freshness

New tenders typically land in the index and are scored within minutes of publishing on the source portal. Portals with hourly or daily update cycles bound this — we can only be as fresh as the source. Your daily digest email fires at your chosen time (default 06:00 tenant timezone) with everything scored since the previous digest.