{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidy6oq3cfhtkexttoe7l6qgljuqreokapdnbkohxhizrep6o55sje",
    "uri": "at://did:plc:pgryn3ephfd2xgft23qokfzt/app.bsky.feed.post/3mmst62a75kb2"
  },
  "path": "/t/need-generative-model-high-quality-description-generation/176230#post_4",
  "publishedAt": "2026-05-27T05:41:57.000Z",
  "site": "https://discuss.huggingface.co",
  "textContent": "Thanks for the detailed guidance — this is very helpful. I agree with your main point: for our use case, the hard part is not finding one “best” model, but designing a reliable pipeline around structured operator data.\n\n**Our setup**\n\n  * Stack: PostgreSQL + Java (Spring Boot) + React/Node.js, hosted on AWS\n\n  * We’re in production, and the app/web is running successfully. This is a stage-2 upgrade where we’re adding AI for content generation.\n\n  * For cost reasons, we’ll likely start with an API-based approach (free tier or OpenRouter), not self-hosted models.\n\n\n\n\n**What we’re generating**\nWe have operator pages. The UI is fixed and shared across all operators. The problem is the content: bio, service areas, location, services offered, FAQ, etc. These must be:\n\n  * Unique\n\n  * Factually accurate (locked to operator inputs)\n\n  * SEO-friendly\n\n  * Scalable to 1,000+ existing operators and all future registrations\n\n\n\n\n**Our workflow (with REST API)**\n\n  1. User clicks **Create Profile** in the frontend.\n\n  2. Frontend sends operator data to Spring Boot.\n\n  3. Spring Boot saves the raw operator record in PostgreSQL with status `PENDING`.\n\n  4. Spring Boot pushes a generation job into a queue/worker system.\n\n  5. Worker reads the operator data and calls OpenRouter.\n\n  6. OpenRouter returns structured content JSON.\n\n  7. Worker validates the JSON and stores the generated content in PostgreSQL.\n\n  8. Status changes to `READY` or `PUBLISHED`.\n\n  9. Frontend fetches the content and renders it in the fixed UI sections.\n\n  10. If something fails, status becomes `FAILED` and only that case goes to retry or manual review.\n\n\n\n\nThis takes about 1–2 minutes, which is acceptable for the operator experience.\n\n**On duplicates and bots**\nWe’re aware that bots and duplicate/near-duplicate content are real risks at scale. We’re considering either:\n\n  * **Human-in-the-loop** , or\n\n  * **Human-on-the-loop** (post-generation review),\n\n\n\n\ndepending on feasibility. If we go with human-in-the-loop for profile creation, it could take 1–2 days per profile, which may cause operator dissatisfaction and negative rumors about the platform.\n\nOur compromise is:\n\n  * Generate the profile in 1–2 minutes automatically.\n\n  * Later, after verification (e.g., within a week), add a **verified tag** to the profile.\n\n\n\n\nThis balances customer trust and operator experience.\n\n**On the generation layer**\nYour suggestions about the generation pipeline are completely valid: risk of hallucinations, unsupported claims, and generic SEO filler are real concerns. Your point that “one API endpoint: input row → prompt → final paragraph → publish” is too fragile for scale is exactly what we’re trying to avoid.\n\nWe’re already considering:\n\n  * Prompt optimization so the model performs accurately and stays within allowed facts.\n\n  * A pipeline that owns normalization, fact restrictions, validation, duplicate checks, and publishing rules in the application layer, while the model mainly handles wording.\n\n  * Structured outputs from OpenRouter, with validation before publishing.\n\n\n\n\nHonestly, for the generation layer, I’m really glad for your help and guidance throughout this process. One last thing I wanted to ask — how would you personally approach building this system from scratch? Like, from which point would you start, and how would you structure the generation flow for scalability and SEO quality?",
  "title": "Need generative model, high-quality description generation"
}