layerwhat we testusually winswe pick otherwise when
l.01Language modelAccuracy on an evaluation set of your own cases, cost per request, speed and where the data is processedThe cheapest model that passes the evaluation set, often a smaller one than expectedData must stay on your servers: an open-weight model such as Llama or Mistral, self-hosted
l.02LLM frameworkWhether it saves code we would otherwise write, test and maintainPlain code, with LlamaIndex for retrieval or LangGraph for multi-step agents where they earn their placeA framework adds more moving parts than it removes: it is replaced with plain code
l.03Vector databaseHow much you will store, what you already run and how results must be filteredpgvector, inside a PostgreSQL database you may already run and back upVery large collections or heavy traffic: a dedicated store such as Pinecone or Weaviate
l.04ML frameworkThe kind of data and how much of it there isscikit-learn for tables of records: forecasts, scores and risk modelsImages, audio, free text or very large datasets: PyTorch
l.05IntegrationWhether each system has an API or a regular exportDirect API calls, scheduled with n8n or Power AutomateNo API at all: RPA bots, such as UiPath, that work the screens like a person
l.06HostingWhere your data may go, and the cloud and sign-in you already useYour own AWS, Azure or Google Cloud account, in a region you chooseRegulated or air-gapped sites: on-premises servers with open-weight models
l.00No model at allWhether a rule, a search or a report would do the jobSometimes it would. A SQL report or a business rule is cheaper to run and easier to trust, and we will say so
