Operating MyHyetaek RAG — Making 11,600 Government Policies Searchable

MyHyetaek turns a difficult public-data problem into a practical assistant: users ask eligibility questions in natural language, and the service has to retrieve reliable policy records before the AI writes an answer.

Why this matters for GRAXEL

The hard part is not only storing thousands of policies. Each policy contains eligibility, region, agency, deadline, and exception language that is written for administrators, not ordinary users. A useful RAG system has to preserve the source record while still returning a short answer that a user can act on.

GRAXEL separates policy search from answer generation. The retrieval layer narrows the candidate set with keyword and vector signals, then the response layer explains the result with the original record still in mind. This is why the portal links MyHyetaek as a flagship service instead of presenting it as a generic chatbot.

Operational notes

• Keep the user-facing promise narrow enough that the service can be verified in a browser.
• Document the boundary between automated AI output and source-backed data so reviewers can understand the workflow.
• Link the implementation back to the public trust pages: About GRAXEL, Contact, and the platform overview.

For a small SaaS portfolio, trust comes from showing the real operating system behind the product: what runs, why it exists, and how it is maintained.

What changed in practice

The result is a service that demonstrates real utility for AdSense reviewers and users: it is not an empty catalog page, but a working public-data workflow with a clear purpose. The same pattern now influences how the portal presents public services: planned ideas stay out of the main catalog, while usable beta services and documented operating notes receive stronger internal links.

When this article is read together with the monorepo operations note and the zero-cost infrastructure note, it gives a more complete view of how GRAXEL turns small service ideas into maintained products.

Official references

• PostgreSQL full-text search
• Supabase vector documentation

What makes the benefit search trustworthy

For MyHyetaek, the retrieval pipeline is only useful if users can understand why a result appeared. I store source metadata with each indexed benefit: title, provider, collected date, original URL, and the normalized text used for retrieval. When a user searches for support based on age, region, visa status, or employment status, the system should surface the relevant evidence rather than presenting a confident but context-free answer.

My evaluation set includes direct program names, vague everyday questions, and negative cases where the user should not qualify. That matters because a RAG system can look accurate when tested only with easy queries. I also separate freshness checks from ranking checks. A result can be ranked correctly but still be outdated if the source page changed. For operational safety, I prefer answers that say “check the official page before applying” and link back to the source. The goal is not to replace public institutions; it is to reduce the search burden and help users ask better questions before they apply.