★ Interactive Demo · AI Hub

SLM for Webex Assistant

A domain-specific AI consulting system for Cisco Webex Calling and Contact Center — helping engineers explore configuration, troubleshoot flows, and plan migrations with verifiable, traceable reasoning. This page includes a working demo, the system design, and a component map, with the full source on GitHub.

Webex Calling Contact Center Migration Planning RAG + Knowledge Layer
View source on GitHub · rajmohan80/wxcc-slm
Try It

Interactive Demo

Click any sample question to see how the assistant responds. This demo runs on pre-written, expert-reviewed answers — no live model calls — so it is free to run and safe to share.

Sample Questions

These mirror the kind of queries the assistant is designed to handle.

SLM for Webex Assistant Demo mode
Pick a question on the left to start.

Planning document. The design and code below describe how this assistant will be built. Full implementation documentation will be published once the tool is developed and lab-validated.

Overview

Two Ways to Build It

"SLM" — Small Language Model — refers to a deliberately narrow, focused assistant rather than a general chatbot. There are two viable build paths, and this project documents both so the right one can be chosen for the deployment context.

Approach A

Hosted API + RAG

Use a hosted model (e.g. Claude Haiku) behind a secure proxy, grounded with Retrieval-Augmented Generation over Webex documentation. The "small" comes from tight scoping and retrieval, not model size. Fast to stand up, broad coverage, pay-per-use.

Approach B

Local LLM + Fine-tuning

Run a genuinely small open model (1–4B parameters) on local hardware, fine-tuned on a Webex corpus with QLoRA. Fully on-premise, no per-query cost, no data leaving the network — at the cost of training effort and infrastructure.

Side-by-Side Comparison

FactorA · Hosted API + RAGB · Local LLM + Fine-tuning
Setup speedFast — daysSlower — weeks
Cost modelPay-per-query (low with Haiku)Upfront compute, then free inference
Data privacyQueries leave your networkFully on-premise
Answer qualityHigh — frontier modelGood for the trained domain
HardwareNone requiredGPU for training; modest box for serving
MaintenanceLow — vendor maintains modelHigher — retrain, host, monitor
Best fitQuick demo, broad coverageOffline, privacy-sensitive deployments
Architecture

High-Level Design (HLD)

The HLD describes the major components and how data flows through the system for each approach.

Approach A — Hosted API + RAG

The browser never touches the model directly. An edge proxy holds the API key, enforces limits, and grounds each query with retrieved Webex documentation before calling the model.

Chat UIStatic page
Edge ProxyKey + rate limit
RetrieverTop-k chunks
Vector StoreWebex docs
Hosted LLMClaude Haiku
Approach B — Local LLM + Fine-tuning

Two pipelines: an offline training pipeline that produces a fine-tuned model, and an inference pipeline that serves it locally.

Webex DocsSource corpus
Data PrepQ/A pairs
QLoRA Fine-tuneBase model
EvaluateHeld-out set
GGUF ModelQuantized
Chat UILocal app
API WrapperFastAPI
Ollama / llama.cppFine-tuned SLM
Detailed Design

Low-Level Design (LLD)

The LLD breaks each component into concrete, implementable detail.

Approach A — Component Detail

Edge Proxy

Cloudflare Pages Function. API key stored as an encrypted environment secret. Validates request shape, enforces per-IP daily rate limit via KV, caps max_tokens.

RAG Pipeline

Webex docs chunked (~400 words), embedded with a sentence-transformer, stored in a vector index. At query time the top 3–4 chunks are retrieved and injected as grounding context.

Prompt & Guardrails

System prompt locks scope to Webex topics, instructs the model to answer only from retrieved context and to recommend verifying against Cisco documentation. Off-topic queries are politely declined.

Approach B — Component Detail

Base Model

A 1–4B instruction model — e.g. Phi-3-mini, Llama 3.2 3B, or Qwen 2.5 3B — small enough to fine-tune on a single GPU and serve on a modest box.

Training Data

Webex documentation converted into instruction/response pairs (JSONL). Cleaned, de-duplicated, and split into train and held-out evaluation sets.

Fine-tuning & Serving

QLoRA — 4-bit quantization plus low-rank adapters — keeps memory low. The trained adapter is merged, converted to GGUF, and served via Ollama or llama.cpp behind a small FastAPI wrapper.

Approach

Build Steps

The end-to-end sequence for each path, from raw documentation to a working assistant.

Approach A · Hosted API
1

Collect Webex docs

Gather Webex Calling and Contact Center documentation as the knowledge source.

2

Chunk & embed

Split docs into passages and generate embeddings.

3

Build vector index

Store embeddings in a searchable vector store.

4

Build edge proxy

Create the function that holds the key and calls the model.

5

Add guardrails

Rate limits, token caps, topic scoping, off-topic refusal.

6

Wire the chat UI

Connect the front-end to the proxy endpoint.

7

Test & deploy

Validate answers, set a Console spend cap, ship.

Approach B · Local LLM
1

Select base model

Choose a 1–4B instruction model that fits available hardware.

2

Build training data

Convert Webex docs into instruction/response pairs.

3

Clean & split

De-duplicate and separate train vs evaluation sets.

4

QLoRA fine-tune

Train low-rank adapters on the quantized base model.

5

Evaluate

Score answers on the held-out set; iterate if needed.

6

Merge & quantize

Merge the adapter and export to GGUF format.

7

Serve & connect

Run via Ollama, wrap with an API, link the UI.

How It's Built

Design & Component Mapping

The working build now lives on GitHub. Rather than a single hosted-API demo, it is a domain-specific consulting system: a structured knowledge layer decides what is correct, a RAG pipeline supplies grounded evidence, and the model only classifies, retrieves, and formats. Here is how it is put together and which tools do which job.

Full repository — github.com/rajmohan80/wxcc-slm
1,414
Knowledge rows
(Workbooks A–D)
2,633
RAG chunks
ingested (Qdrant)
9
Step intent-flow
state machine
11
MCP tools
exposed

Design Principle — Knowledge First, Model Third

Enterprise AI consulting fails when the intelligence lives only in model weights — they are opaque, unauditable, and stale the moment a new Cisco release ships. This build puts the intelligence in four structured workbooks and a provenance-ranked corpus instead. The model classifies intent, retrieves grounded evidence, and formats the answer; the workbooks decide what is correct. Certain queries never reach the generator at all — a stop-condition check runs before any LLM call, so an impossible request (for example, a data-locality region Cisco does not offer) returns a sourced blocker and a valid alternative rather than a hallucination.

Intent Flow Pipeline — 9 steps (LangChain + LangGraph)
Intent1 · Classify
Scenario2 · Detect
Requirements3–5 · Workbook rules
RAG6 · Qdrant + BGE-M3
Compliance7 · Flags
Architecture8 · Generate
Validate9 · Best-practice

Steps 3–5, 7 and 9 are deterministic workbook rules — not model calls. The LLM is invoked only where judgement genuinely helps: intent, scenario, and the architecture draft.

Tools Used

LLM · current
Groq Llama-3.3-70B
LLM · planned
Claude Haiku 4.5 + Sonnet 4.6
Embeddings
BGE-M3 · 1024-dim
Vector DB
Qdrant Cloud
Orchestration
LangChain + LangGraph
Session memory
LangGraph MemorySaver
MCP server
FastMCP · 11 tools
REST API
FastAPI
Frontend
Streamlit
Automation
n8n · 4 workflows
Deployment
GCP Cloud Run
Observability
MLflow + Evidently

Component Mapping

LayerComponentTechnologyRoleStatus
KnowledgeWorkbooks A–DStructured rows (1,414)Requirements, product knowledge, architecture patterns, engineering guardrailsComplete
KnowledgeRAG corpusQdrant + BGE-M348+ provenance-tiered docs, 2,633 chunks, Tier-1 ranked above Tier-2Ingested
PipelineIntent flowLangGraph (9-step)Classify → detect → check → retrieve → flag → generate → validateComplete
PipelineQuery engineQdrant retrievalProvenance-ranked scoring with knowledge-date stampingComplete
PipelineAgentLangChain ReActTool-calling agent with session memory and thread isolationComplete
DeliveryREST APIFastAPI/query and /health, local dev on :8000Local
DeliveryMCP serverFastMCP11 tools for agentic access to the knowledge layerLocal
DeliveryFrontendStreamlitInteractive demo UI, local dev on :8501Local
AutomationFreshness loopn8n (4 workflows)Weekly source checks keep the knowledge-date stamp honestPlanned
OpsDeploymentGCP Cloud RunPublic demo endpoint, post-validationPlanned

Demo build. The pipeline runs locally, the knowledge base is complete, and the architecture is production-ready. Cloud Run deployment, a public Streamlit demo, and the n8n automation loop are on the roadmap. Full source, schema references, and the build status board are in the GitHub repository.