This is a submission for the Hacktoberfest x Open Source AI Challenge — Side Hustle.
What I Built
Member Assistant is a production-grade AI assistant for shopping-mall mini-programs. Members ask questions in natural language — "How many points do I have?", "How does parking work?" — and get instant, cited answers over an SSE stream.
Under the hood:
- Real vector RAG — multilingual sentence-transformers embeddings + FAISS index over the mall's knowledge base (parking rules, points rules, coupons, floor guide)
- Read-only member tools — points / coupons / orders, served from SQLite opened in read-only mode; the assistant can only call a closed registry of preset tools, never raw SQL
- Hard safety constraints in code — identity comes only from the auth header (never the request body), low-confidence answers fall back to a human agent
-
FastAPI + Docker —
/healthz, JSON structured logging, env-based config, one-command deploy
Demo
Live demo: https://8001-agqutsuuudc2eonxfv2xrllzpq.instabox.tech
Try it (replace with any header value; M10001 has sample data):
curl -N -X POST https://8001-agqutsuuudc2eonxfv2xrllzpq.instabox.tech/chat \
-H "X-Member-Id: M10001" \
-H "Content-Type: application/json" \
-d '{"question": "我的积分有多少?"}'
Code
https://github.com/497900963/member-assistant
How I Built It
The whole stack is open source — no closed model APIs anywhere in the loop:
-
Knowledge base → chunked Markdown docs →
paraphrase-multilingual-MiniLM-L12-v2embeddings → FAISS cosine index (scripts/build_index.py) -
Request flow →
X-Member-Idheader auth → RAG top-k retrieval → optional preset tool call (member_id injected server-side) → streamed answer with citations -
Safety by construction — SQLite opened with
mode=ro, so even a bug can't write; tool registry is a closed dict, unknown tools are rejected - Tested — 16 pytest cases covering retrieval relevance, read-only enforcement, 401/422 paths, and identity-spoofing attempts
The companion piece in the same project, Ops Assistant (ops-assistant/), is a CLI for on-call engineers: ask "why did coupon redemptions fail yesterday?" produces a structured incident report (symptoms / root cause / stop-the-bleed + permanent fix / risk / verification), and monitor does P0/P1 health checks with WeCom alerts. It follows the same read-only philosophy: a command filter rejects anything resembling a write, and analysis is pure Python — no shell to escape from.
Why Does Open Innovation Matter
A mall's member data is sensitive — points balances, coupons, order history. With a closed API:
- Privacy: every member question (and its personal data) leaves the building
- Cost: per-token billing on thousands of daily member queries adds up fast
- Lock-in: the day the vendor changes pricing or terms, your assistant stops working
With open models and open code:
- Data stays on-prem — the embedding model and vector index run on the company's own machines; nothing about any member ever leaves the intranet
- Zero marginal cost — a 120M-parameter embedding model on CPU answers retrieval in milliseconds, forever free
-
Auditable safety — the "read-only" guarantee isn't a promise in a terms-of-service, it's
mode=roin the source code anyone can read
Open isn't just cheaper here. For member data, it's the only architecture I'd sign off on.
My First User
Me. I'm a backend engineer at a shopping-mall company, and our mini-program's member support is currently humans answering the same five questions about points and parking, all day.
I dogfooded this against our actual rule docs. The moment it answered "前2小时免费" with a citation to the parking rules doc — correctly, in Chinese — I knew the RAG pipeline was real. Next step: point the LLM client at our internally deployed model (it's already env-configurable) and wire the X-Member-Id header to our existing *-api auth gateway. The Java 8 system doesn't change at all; this service sits beside it.
Would I pay for it? I'm already paying in the form of support hours it saves. If this saves our CS team even 30 minutes a day, it's paid for itself many times over.
Prize Categories
-
Best Use of Render — the demo is containerized and deployable to Render as-is (
Dockerfileincluded) - Overall quality — production structure, 27 passing tests across both assistants, and safety constraints enforced in code rather than documentation
Top comments (0)