Your vendor's knowledge base has answers buried in it. But you can't find them. Search requires exact phrasing, categories are wrong, articles contradict each other. After wasting hours hunting for configuration details, you decide to build something better: a private GPT that understands natural language queries and actually returns useful answers.
Why Traditional Search Fails
Traditional knowledge base search fails because knowledge bases are built for article authors, not searchers. Titles optimize for SEO or internal taxonomy, not for the questions people actually ask. You search "trunk registration fails," the KB has an article titled "SIP Authentication Methods for Distributed VoIP Networks." Same topic, zero keyword overlap.
Search indexes match keywords. If the article uses "admin panel" and you search "portal," you get nothing. If documentation calls it a "dial plan" in one place and "routing table" in another, search can't unify those concepts.
AI-powered search doesn't require exact matches. You ask "Why won't my trunk register?" in plain language. The model understands intent, maps your question to relevant content, and surfaces answers even when terminology varies. That's why it's worth building.
Scraping the Knowledge Base
Start by exporting every article. If the KB has an API, use it. If not, scrape the HTML. You want article title, body content, URL, and publication date for every doc.
# Simplified Python scraper
import requests
from bs4 import BeautifulSoup
import time
def scrape_kb_article(url):
response = requests.get(url)
soup = BeautifulSoup(response.content, 'html.parser')
title = soup.find('h1', class_='article-title').text.strip()
body = soup.find('div', class_='article-body').get_text(separator='\n')
return {'title': title, 'body': body, 'url': url}
# Scrape index to get all article URLs
index_url = 'https://kb.vendor.com/articles'
response = requests.get(index_url)
soup = BeautifulSoup(response.content, 'html.parser')
article_links = [a['href'] for a in soup.find_all('a', class_='article-link')]
articles = []
for link in article_links:
article = scrape_kb_article(link)
articles.append(article)
time.sleep(0.5) # Rate limiting
print(f"Scraped: {article['title']}")
# Save to JSON for processing
import json
with open('kb_articles.json', 'w') as f:
json.dump(articles, f, indent=2)Respect rate limits. Add delays between requests. If you're hitting a vendor KB aggressively, they'll block you. Slow and steady wins here.
Converting to PDFs
GPT platforms like OpenAI's custom GPTs support file uploads and PDF works best for long-form content. Converting each article to a well-formatted PDF with title, body, and metadata gets them into the right shape.
from fpdf import FPDF
import json
def create_article_pdf(article, output_path):
pdf = FPDF()
pdf.add_page()
pdf.set_font('Arial', 'B', 16)
pdf.multi_cell(0, 10, article['title'])
pdf.ln(5)
pdf.set_font('Arial', '', 12)
# Clean and encode body text
body = article['body'].encode('latin-1', 'replace').decode('latin-1')
pdf.multi_cell(0, 5, body)
pdf.output(output_path)
with open('kb_articles.json', 'r') as f:
articles = json.load(f)
for i, article in enumerate(articles):
filename = f"article_{i:04d}.pdf"
create_article_pdf(article, f"pdfs/{filename}")
print(f"Created: {filename}")For huge KBs, consider combining articles into larger PDFs organized by category or topic. One PDF per article works for smaller collections, but hundreds of individual files become unwieldy.
Deploying the Private GPT
OpenAI's custom GPT builder, lets you upload files for retrieval. Create a new GPT, upload your PDFs, and configure the system prompt to explain its purpose and constraints.
Your system prompt matters. Tell the GPT what it knows, what it doesn't, and how to behave when uncertain. Don't let it hallucinate answers when the KB doesn't cover a topic.
You are a knowledge base assistant for [Vendor] VoIP platform documentation.
You have access to technical articles covering configuration, troubleshooting, API documentation, and best practices.
When answering:
1. Search the uploaded knowledge base files first
2. Cite the specific article or section where you found the information
3. If the answer isn't in the KB, say "I don't have documentation on that topic" instead of guessing
4. When terminology varies (e.g., "portal" vs "admin panel"), treat them as synonyms
Do not invent configuration values, API endpoints, or troubleshooting steps not found in the documentation.This prompt reduces hallucinations. The GPT knows to cite sources and admit when it doesn't know something.
Handling Hallucinations
Even with good prompts, GPTs hallucinate when data is sparse. You ask about a feature, the KB has one vague paragraph, and the GPT fills in details from general VoIP knowledge that don't apply to your vendor's platform.
Test with known edge cases. Ask about features you know aren't supported. If the GPT says "Yes, configure it by..." instead of "That feature isn't documented," refine your prompt.
Add explicit constraints:
If a configuration option, API endpoint, or feature isn't explicitly mentioned in the knowledge base, respond: "I don't see that documented. You may want to contact [Vendor] support to confirm if this is supported."
Never suggest workarounds or alternatives unless they're documented in the KB.This makes the GPT conservative. Better to say "I don't know" than to confidently give wrong answers.
Fixing Inconsistent Terminology
Documentation teams don't enforce terminology consistency — one article calls it "SIP trunk," another says "VoIP carrier connection," a third uses "outbound route." They're the same thing.
Build a synonym map in your system prompt:
Terminology equivalents in this documentation:
- "Portal" = "Admin panel" = "Web interface"
- "Extension" = "User" = "Subscriber"
- "DID" = "Phone number" = "Direct number"
- "Trunk" = "SIP trunk" = "Carrier connection"
- "Auto attendant" = "IVR" = "Menu"
When searching or explaining concepts, recognize these as the same.This helps retrieval. When someone asks about "adding a phone number," the GPT knows to search for content about "DIDs" too.
Identifying Knowledge Gaps
Here's the trick that makes this system actually useful: ask the GPT what's missing.
After deploying your initial KB, ask:
"What topics do you have incomplete or minimal documentation on?"
The GPT will tell you: "I have limited information on failover configuration, backup procedures, and webhook authentication. These topics are mentioned but not fully explained."
That's gold. Those are the exact gaps that frustrate users. Fill them. Write supplemental documentation, scrape related vendor resources, or contact support for missing details. Add those to the KB.
This turns the GPT into an audit tool for your documentation. It knows what it doesn't know and can tell you explicitly.
Keeping It Updated
Vendor documentation changes — new features launch, APIs evolve, old articles get deprecated. Running the scraper monthly and regenerating changed PDFs keeps things current.
Run your scraper monthly. Diff the new articles against existing ones. When content changes significantly, regenerate the PDF and re-upload. Version your knowledge base snapshots so you can roll back if a bad update breaks retrieval.
Track when articles were last updated. If the GPT cites a 2019 article for a 2026 question, flag that for review. Old documentation might still be accurate, but it's worth checking.
Privacy and Access Control
Custom GPTs can be set to private (just you), internal (your organization), or public. For proprietary vendor documentation or internal KB content, keep it private or internal only.
Don't upload sensitive data. If your KB includes customer account examples, API keys, internal system details, scrub that before converting to PDFs. Assume anything uploaded could leak.
For true enterprise privacy, consider self-hosted alternatives like LangChain with local LLMs and vector databases. OpenAI's custom GPTs are convenient but data lives on their servers.
Results
A private AI knowledge base cuts search time significantly and improves answer quality. Before: Spend 20 minutes searching for "how to configure E911," find three partially relevant articles, piece together an answer, hope it's current.
After: Ask "How do I set up E911 for NetSapiens users?" Get a direct answer with citations in 10 seconds. The GPT pulls from multiple articles, synthesizes the steps, and links to source documentation.
The time savings compound. Support teams answer tickets faster. Engineers troubleshoot without hunting through docs. Onboarding new staff becomes easier because they can ask natural questions instead of learning your KB's taxonomy.
A useful AI knowledge base requires ongoing maintenance: ask the GPT what it doesn't know, fill those gaps, refine the prompt based on real queries, and keep the docs current. It's a system you tend, not a thing you deploy once.
When to Build This
This approach makes sense when:
- You have substantial documentation: Hundreds to thousands of articles with valuable content
- Search is actively painful: Team members waste hours hunting for answers
- Terminology is inconsistent: Different teams or doc authors use different terms for the same concepts
- You can maintain it: Someone owns keeping the KB updated as vendor docs change
Don't build this for small, well-organized KBs where search already works. The effort isn't worth it. But for massive, poorly indexed documentation repositories that frustrate everyone daily, a private GPT transforms how your team uses that knowledge.