Project
A project that connects natural-language questions to a RAG-style search flow and renders streaming responses with search results in a chat UI.
Existing government welfare sites are menu-navigation focused, making it hard for users to quickly find the benefits they want. CiviChat connects natural-language questions through condition extraction, RAG retrieval, LLM summary streaming, and result rendering into a single conversational flow. I designed and built the AI response rendering, vector search interface, accessibility, and performance optimization end-to-end.
Question input, conversation history, result-card rendering
Sends search-result events first, then streams LLM summary chunks over SSE
Pure TypeScript search/condition-extraction logic separated from React
pgvector vector search, tsvector keyword search, RRF combination, then re-ranking by conditions/region/keywords
Summarizes search results into plain language and streams the response
Typewriter summary, result cards, virtual-scroll height estimation
Business logic is isolated in src/core as pure TypeScript with no React/Next.js dependency. The CLI and API routes share the same functions; new features get validated in the CLI first, then wired up to the UI.
Initially, vector search alone surfaced irrelevant results at the top even for explicit queries like "Seoul youth grants". I added keyword search (tsvector) and combined rankings with RRF, then layered on re-ranking by conditions, region, and keywords so semantic search and exact match work together.
Strong regional filters made central-government or nationwide services disappear from candidates for queries that named a region (Seoul, Busan, etc.). I started fetching regional and unfiltered nationwide candidates together, then deduplicated and applied a regional boost/penalty to balance recall and precision.
Search logic tangles regex, vector search, keyword search, and post-filters together, so a small change can degrade other queries. I built an eval query set and promoted it to a Vitest-based search-quality test so the quality bar gets checked on every push to main.
Originally the UI showed result cards only after the LLM summary stream finished, which made the perceived response feel slow. I changed the server to emit search-result events first and stream summary chunks after, so users perceive a successful search and the candidate results sooner.
AI summaries vary in length each time and are rendered incrementally by a typewriter, so measuring height after inserting into the DOM triggers a reflow every step. I switched to measuring width off-DOM with Canvas measureText and computing line breaks via binary search, reducing scripting cost during streaming by 85% (getBoundingClientRect 1,282ms → Canvas 193ms). I also wrote about this in a blog post and a playground demo.
Vector search alone was weak for exact matches like region or statute names. Keyword search alone could not handle descriptive questions. I combined the two results with RRF, then re-ranked by service-name/body keywords, district/province/nationwide flags, and applicant conditions like job-seeker, pregnant, small-business owner, single-parent, low-income.
Welfare/legal search, condition extraction, and summary logic live in src/core so the CLI and API routes call the same functions. This lets me validate search quality from the terminal before wiring up UI, and lets a team — frontend and backend/ML — work independently against the same core functions.