Why I stopped trading and started tendering with AI

Why I Stopped Trading and Started Tendering with AI

For years, I was a trading junkie. Algorithms, backtesting, market analysis - I devoured it all. I built countless bots, chased fleeting arbitrage opportunities, and generally lost sleep trying to squeeze marginal gains out of increasingly efficient markets. It was intellectually stimulating, sure, but ultimately… draining. And, frankly, not consistently profitable.

Then, I stumbled into a different world: government and commercial tendering. And I realized something profound: the real money wasn’t being made reacting to a market, it was being made shaping it. But tendering is a beast. Massive documents, complex requirements, a sea of competitors. That’s where AI came in. I didn't just want to use AI, I wanted to build AI specifically for tendering. This is the story of how I switched from trading and started "tendering with AI".

The Problem with Traditional Tendering

Think about a typical tender. Hundreds of pages. Technical specifications, legal jargon, weighting criteria, compliance checklists. You need to analyze it all, understand if you're even a good fit, and then craft a response that precisely addresses every requirement. The process is manual, time-consuming, and prone to human error.

My initial approach was, well, naive. I thought I could brute-force it with keyword matching. It didn’t work. A tender asking for “reliable network infrastructure” doesn’t just contain those keywords; it implies a whole host of related capabilities: scalability, security certifications, redundancy, support SLAs.

Traditional methods relied on manual reading and tagging - a process slow and expensive. Plus, responding to a large volume of tenders requires a dedicated team. For smaller businesses, it’s simply not feasible.

From Trading Bots to Tender Bots: A Conceptual Shift

The core skill from my trading days wasn't the specific algorithms, it was the ability to automate information processing and decision making. This, surprisingly, translated beautifully to tendering. But the goal was different. Trading was about prediction; tendering is about demonstrating capability.

Instead of predicting price movements, I needed to extract requirements and map them to our capabilities. Instead of executing trades, I needed to generate compliant, compelling tender responses.

Building IronVision Nexus: The Core Components

I started building what I now call IronVision Nexus, a suite of tools centered around a large language model (LLM) tailored for tender analysis and response generation. Here’s a breakdown of the key components:

1. Document Parsing & OCR:

This wasn't about just getting text. Many tenders are scanned PDFs. So, the first step is robust Optical Character Recognition (OCR). I used PyTesseract and pdfminer.six to extract text and attempt to reconstruct document structure.

from pdfminer.high_level import extract_text
import pytesseract
from PIL import Image

def extract_text_from_pdf(pdf_path):
  """Extracts text from a PDF, handling scanned images with OCR."""
  try:
    text = extract_text(pdf_path)
    return text
  except:
    # Attempt OCR if PDF extraction fails (likely a scanned image)
    try:
      img = Image.open(pdf_path)
      text = pytesseract.image_to_string(img)
      return text
    except Exception as e:
      print(f"Error during OCR: {e}")
      return ""

2. Requirement Extraction (Key to Everything)

This is where the LLM shines. I fine-tuned a model (currently a quantized Llama 2 7B, deployed locally for cost and control) on a dataset of tender documents and manually labeled requirements. The goal: identify what the tender is asking for, not just the words it uses.

from transformers import pipeline

# Initialize the question-answering pipeline (fine-tuned LLM)
qa_pipeline = pipeline("question-answering", model="path/to/fine-tuned-model", tokenizer="path/to/tokenizer")

def extract_requirements(tender_text):
  """Uses the LLM to identify requirements in the tender text."""
  question = "What are the core requirements outlined in this document?"
  result = qa_pipeline(question=question, context=tender_text)
  return result['answer']

This is a simplified example. In practice, it's much more complex, involving:

• Chunking: Breaking the document into manageable segments.
• Recursive Summarization: Summarizing sections to distill key information.
• Requirement Classification: Categorizing requirements (e.g., technical, legal, commercial).

3. Capability Mapping & Response Generation

Once we have the requirements, we map them to our company’s capabilities. This is done using a vector database (I'm using Pinecone) to store our capability descriptions. Each requirement is converted into a vector embedding, and the database finds the most relevant capabilities.

import pinecone

# Initialize Pinecone connection
pinecone.init(api_key="YOUR_PINECONE_API_KEY", environment="YOUR_PINECONE_ENVIRONMENT")
index = pinecone.Index("tender-capability-index")

def find_relevant_capabilities(requirement_embedding):
  """Finds relevant capabilities in the Pinecone vector database."""
  results = index.query(vector=requirement_embedding, top_k=5)
  return [match['metadata']['capability'] for match in results['matches']]

Finally, the LLM generates the tender response, incorporating our mapped capabilities. Prompts are carefully crafted to ensure compliance and persuasiveness.

4. Compliance Checking

Before submitting, we use the LLM to cross-reference the generated response against the original tender requirements. This helps catch gaps and ensure full compliance.

The Results: From Zero to Consistent Wins

The difference has been remarkable.

• Increased Bid Volume: We can now analyze and respond to significantly more tenders.
• Higher Win Rate: The precision of our responses, driven by AI-powered analysis, has led to a substantial increase in our win rate.
• Reduced Costs: Automation reduces the manual effort required for tendering, lowering costs.
• Scalability: The system is designed to handle increasing volumes of tenders with minimal additional effort.

Beyond the Basics: Future Development

This is just the beginning. I'm currently working on:

• Automated Risk Assessment: Using AI to assess the risk associated with a particular tender (e.g., competitive landscape, probability of success).
• Dynamic Pricing Optimization: Suggesting optimal pricing strategies based on tender requirements and market conditions. *