OutsourcingVN is operated by Netbase JSC, and this page sets out that choice, its trade-offs, and the Netbase work built on it; model names change faster than this page can track, so the comparison below stays on patterns and integration shape.
Where a large language model fits, and where it doesn't
Good fit
- Drafting, summarising, classifying or holding a conversation in natural language, with a human or a rule checking the result
- An answer that must be grounded in your own documents or data, where retrieval over an approved source register fits; the RAG context engineering guide scopes that project
- An agent-style feature that should call existing systems (look up an order, update a record) under defined scopes, rather than only produce text
- A single workflow that can be scoped and shipped on its own; the AI knowledge assistant solution covers the clearest version of that case
Another route fits better
- A task with a deterministic, auditable answer that a normal program already computes reliably and more cheaply
- Matching or ranking records by similarity rather than generating text, which the embeddings and semantic search guide covers as a separate decision
- A workflow with no natural-language input or output at all, where the model would add cost and risk without a reason
- A second or third workflow will need the same sources, evaluation store and access policy, where data and AI platform engineering builds the shared foundation instead
Four integration patterns
Hosted API. The model runs on a provider's infrastructure and your application calls it over an API; fastest to start, with data leaving your environment under the provider's contract and terms you must read before committing.
Self-hosted, open-weight model. You run the model on your own or a cloud account's infrastructure; it keeps data inside your environment and adds the operating burden the production AI inference assessment guide scopes, GPU capacity, patching and monitoring among it.
Retrieval (RAG). The model answers from passages fetched from an approved source register at request time, rather than from what it memorised during training; this is the pattern for answers that must cite your own current documents, and it depends on the data readiness the data platform readiness assessment checks first.
Tool use. The model is given a set of callable tools with a defined schema and decides when to request one; your application (or, for a hosted provider's own tools, the provider's infrastructure) executes the call and returns the result, and the model continues from there. The Model Context Protocol has emerged as an open, cross-vendor way to expose a set of tools and data sources to an AI application in this pattern, so a tool built once can be reused across more than one model or client.
These four patterns combine. A support assistant commonly pairs retrieval, for grounded answers from a knowledge base, with tool use, for looking up an order or escalating a ticket, behind a single hosted or self-hosted model.
Trade-offs to weigh
- Speed to start against data control. A hosted API is usually the fastest way to a working feature; a self-hosted model keeps data inside your environment at the cost of operating it yourself.
- Groundedness against engineering effort. Retrieval reduces invented answers by citing real sources, and it requires a source register, chunking and an evaluation set before it can be trusted, work the RAG context engineering guide scopes directly.
- Capability against blast radius. Tool use lets a model take action, not just produce text, which is also why every tool needs a defined scope, an audit log and a human checkpoint on anything consequential.
- Vendor flexibility against switching cost. Designing the integration behind a stable interface keeps the model replaceable later; coupling application code directly to one provider's API shape makes a future change more expensive than it needs to be.
A worked scenario: a support assistant for a SaaS product
A SaaS company wants a support assistant that answers plan and feature questions from its own help-centre articles and can look up a customer's subscription status when asked.
The first milestone builds the retrieval layer: a source register of approved help-centre articles, a chunking and indexing pipeline, and a small evaluation case set covering ordinary, ambiguous and out-of-scope questions. The second milestone adds one tool, a subscription-status lookup, scoped to read-only access and logged on every call. The third milestone runs the evaluation set against the combined retrieval-plus-tool assistant, in shadow mode beside the existing support queue, before any customer sees it. The assistant hands off to a person for billing disputes and anything the evaluation set flags as a weak answer, rather than guessing.
Each milestone closes on the evaluation set passing before the next one starts, which keeps a later model or prompt change a rerun of that same set rather than a fresh investigation.
Where Netbase has delivered with large language models
Netbase has delivered anonymised client AI projects including retrieval-based knowledge assistants, document AI and MLOps pipelines. For a client that is not named, Netbase built a WhatsApp Business AI chatbot with intent and conversation-flow handling, an LLM API with GPT-4 in the stack, and CRM synchronisation for lead capture, customer data and workflow automation. For an individual client that is not named, a classifieds platform used AI-powered content filtering that detects and flags offensive content into an admin moderation dashboard, the closest published example of a model making a narrow, bounded classification rather than holding open conversation. Netbase works with commercial and open-source AI models chosen per project, model-agnostic, with no vendor partnership implied, and applies the ISO/IEC 42001 AI management system framework to its own AI delivery practice.
What to check before committing
- Which of the four patterns the task actually needs, since a chatbot and a classification feature have different grounding and tool needs even when both use the same underlying model.
- Where the data each pattern depends on lives, since retrieval and tool use both need a cleared, governed source before they can be trusted; the data platform readiness assessment checks that.
- How a model or prompt change gets re-evaluated, with a kept evaluation set and a rollback path rather than a judgement call after it ships.
- Which compliance practices apply to the data involved. Netbase's compliance practices are GDPR alignment for data privacy in Europe, HIPAA-aligned methodologies for healthcare data handling, and CCPA compliance for clients with U.S. customer bases, which a client's own legal position still governs.
Failure modes
-
A model answering from memory instead of your sources
Without retrieval and a citation check, a confident but wrong answer is indistinguishable from a correct one until a reader catches it.
-
A tool given broad access it never needs
The classification record above shows the safer pattern: flag into a human review queue rather than let a model take an irreversible action alone.
-
No evaluation set kept across model or prompt changes
Each change becomes a fresh investigation instead of a rerun, and regressions slip through unnoticed.
-
Application code coupled directly to one provider's API shape
A model swap or a billing change becomes a rewrite instead of a configuration change.
-
Untrusted content steering a tool call
A retrieved document or a user message can attempt to redirect what the model does next, a pattern known as prompt injection; narrow tool scopes, input handling and a review step on consequential actions contain that risk rather than assume it away.
Common questions
No. Most production features combine retrieval and tool use behind one model, as in the support assistant scenario above; the four patterns in this guide are building blocks, not exclusive options.
No. Netbase works with commercial and open-source AI models chosen per project, model-agnostic, with no vendor partnership implied, so the pattern and the workload decide the model, not a standing preference.
It is an open, cross-vendor standard for exposing tools and data sources to an AI application, so a tool built once can be reused across more than one model or client; it matters once more than one assistant or client needs the same set of tools, not for a single narrow integration.
The AI model selection guide picks a model class for a single workflow already in scope; this page covers the integration patterns and trade-offs across a whole product, before or alongside that choice.
Yes, for a task with a deterministic, auditable answer a normal program already computes reliably; the fit table above exists to catch that before a project commits engineering time to a model that was never needed.
Where Netbase applies this stack
Data and AI platform engineering: one foundation your workflows share
Pipelines, retrieval indexes and model operations your AI and analytics workflows can share.
Learn More
From platform decision to project
Bring the workflow a model would read, draft or act inside, the sources it would need to ground answers in, and any system it would need to call, and data and AI platform engineering scopes the integration pattern, evaluation store and access policy before a line of prompt is written; the other platform pages sit under Technologies. OutsourcingVN is operated by Netbase JSC and is Netbase's own outsourcing-services platform; submit a project with the workflow a model would carry.