Building Internal Knowledge Base Search With Vector Databases and PHP

Why Standard SQL Keyword Search Fails Operations Teams

Operations and support teams store critical procedures across hundreds of PDFs, Notion pages, and internal wiki articles. When a new staff member searches for client refund approval limits, a standard SQL LIKE query or basic full-text index only returns documents containing those exact words. If the official policy document calls the process credit memo authorization, the search returns zero results.

Staff then interrupt senior managers on Slack to ask questions that are already documented. Building a retrieval system that understands meaning as well as exact part numbers requires combining vector embeddings with traditional keyword indexing inside your existing PHP stack.

Why We Prefer PostgreSQL pgvector Over Separate Vector Silos

Many tutorials tell teams to spin up a separate cloud vector database alongside their relational database. In practice, maintaining two separate data stores creates synchronization bugs whenever a document permission changes or an old SOP gets deleted. We run PostgreSQL with the pgvector extension directly inside the primary application database.

Keeping document metadata, role-based access control lists, and vector embeddings in the same PostgreSQL tables lets us filter search results by user department in a single SQL query. A warehouse supervisor only retrieves warehouse safety manuals, and finance staff only see accounting procedures, with zero risk of stale permission caches.

• Split source documents by markdown headings and paragraph boundaries at 400 to 600 tokens per chunk.
• Prepend the document title and section hierarchy path to every chunk before generating embeddings.
• Combine HNSW vector similarity scores with PostgreSQL tsvector keyword rankings using Reciprocal Rank Fusion.
• Enforce user role permissions directly in the SQL WHERE clause before passing chunks to the answer generator.

Chunking Technical Manuals Without Losing Context

The quality of an internal search tool depends far more on document chunking than on the choice of language model. Splitting a PDF every five hundred characters cuts tables and numbered checklists in half. When a checklist gets split across two chunks, the retrieved answer misses the final safety steps.

Our PHP ingestion service parses headings, bullet lists, and markdown tables as atomic units. Each stored chunk keeps a JSON reference to its parent document ID, page number, and last updated timestamp. When an administrator uploads a revised policy PDF, a background job hashes each section and re-embeds only the paragraphs that changed.

Enforcing Strict Source Citations to Prevent Hallucinations

An internal knowledge assistant should never guess company policy when the underlying documents do not cover a topic. We instruct our synthesis prompt to answer strictly from the retrieved chunks and attach a clickable link to the exact document section and page number on every claim.

If the hybrid search returns chunks below our similarity threshold, the portal skips generation entirely and tells the user no matching policy was found. We also log every zero-result query so operations managers can see which topics need new documentation written.