Knowledge Base — Manufacturing Search Engine¶
A precision information-retrieval service for manufacturing knowledge. Built on Elasticsearch with hybrid BM25 + vector search — not RAG, not generative AI. Documents are returned verbatim or not at all.
Why not RAG?
In manufacturing, alarm codes differ by one character, equipment parameters are meaningless without domain context, and wrong answers have real consequences. This system is designed around a zero-fabrication guarantee: if a document matches, it is shown as-is; if nothing matches, the caller is told so explicitly. The LLM is used only as a query-understanding proxy and a conversational explainer — never as a source of facts.
What this project is¶
A zero-fabrication knowledge-base API for semiconductor manufacturing equipment. Documents are retrieved verbatim from Elasticsearch; the system never generates document text. The LLM appears in exactly two roles:
- Query-understanding proxy (
POST /api/v1/extract) — turns a free-text question into structured search parameters. - Conversational search assistant (
POST /api/v1/chat) — extracts params, searches the KB, and answers strictly from the returned documents.
Stack: FastAPI · Elasticsearch 8.x (IK analyzer plugin) · pydantic-settings · httpx · DashScope Embeddings API (optional).
The three guarantees¶
-
Zero fabrication
Search responses contain verbatim document sections or nothing. The LLM is forbidden from inventing parameters, steps, or alarm codes.
-
Graceful degradation
No LLM key → search and indexing still work (AI chat returns 503). No embedding key → keyword-only BM25 search, no kNN. The server always boots.
-
Taxonomy enforcement
projectandequipmentvalues are validated againstconfig/taxonomy.yamlat index time. Unknown values are rejected rather than silently stored.
Where to go next¶
| If you want to… | Read |
|---|---|
| Run the stack and try it out | Getting Started |
| Understand the big picture | Architecture → Overview |
| Understand the chat/extract endpoints | Architecture → AI Chat Search |
| Understand how files become documents | Architecture → Import Pipeline |
| Understand the search ranking & status contract | Architecture → Search & Ranking |
| Tune settings / add a provider | Configuration |
| Call the HTTP API | API Reference |
| Wire up metrics & logs | Observability |
| Rebuild the system from scratch | Reference → Build from Scratch |
| Look up every field & ES mapping | Reference → Data Model |
| Look up every setting & env var | Reference → Configuration Reference |
| Deploy, back up & harden | Operations → Deployment |
| Run the tests / develop | Operations → Testing & Development |
| Diagnose a failure | Operations → Troubleshooting |
| Understand the security posture | Operations → Security |
At a glance¶
flowchart TD
UI["Upstream chat / UI layer"] -->|SearchRequest| API
subgraph API["FastAPI (kb.main)"]
search["POST /api/v1/search"]
chat["POST /api/v1/chat · /extract"]
ingest["POST /api/v1/ingest/*"]
docs["POST /api/v1/documents/*"]
end
API --> ES[("Elasticsearch 8.x<br/>BM25 + kNN")]
API -.optional.-> EMB["DashScope Embeddings<br/>text-embedding-v3 (1024-dim)"]
API -.optional.-> LLM["LLM (OpenAI-compatible)<br/>extract · segment · explain"]
Structured filters narrow the candidate set first, then hybrid BM25 keyword search and dense-vector similarity re-rank results. The caller never sees AI-generated text — only verbatim document sections.