From a578c76bbd9b835a7d8cbc0ef4baa618e257805e Mon Sep 17 00:00:00 2001 From: Shivam Mishra Date: Thu, 21 May 2026 19:40:23 +0530 Subject: [PATCH] debug: wider hc genration --- .../llm/help_center_curation_schema.rb | 2 +- .../llm/help_center_curation_service.rb | 46 +++++++------------ 2 files changed, 18 insertions(+), 30 deletions(-) diff --git a/enterprise/app/services/captain/llm/help_center_curation_schema.rb b/enterprise/app/services/captain/llm/help_center_curation_schema.rb index 1c2a53b92..3e3b4fd72 100644 --- a/enterprise/app/services/captain/llm/help_center_curation_schema.rb +++ b/enterprise/app/services/captain/llm/help_center_curation_schema.rb @@ -20,7 +20,7 @@ class Captain::Llm::HelpCenterCurationSchema < RubyLLM::Schema end end - array :articles, description: ARTICLES_DESCRIPTION, min_items: 1, max_items: 25 do + array :articles, description: ARTICLES_DESCRIPTION, min_items: 1, max_items: 60 do object do array :urls, description: URLS_DESCRIPTION, min_items: 1, max_items: 3, of: :string string :title, description: TITLE_DESCRIPTION, max_length: 80 diff --git a/enterprise/app/services/captain/llm/help_center_curation_service.rb b/enterprise/app/services/captain/llm/help_center_curation_service.rb index 1f8b8acb2..890a65fce 100644 --- a/enterprise/app/services/captain/llm/help_center_curation_service.rb +++ b/enterprise/app/services/captain/llm/help_center_curation_service.rb @@ -1,6 +1,6 @@ class Captain::Llm::HelpCenterCurationService < Captain::BaseTaskService RESPONSE_SCHEMA = Captain::Llm::HelpCenterCurationSchema - MAX_LINKS_IN_PROMPT = 50 + MAX_LINKS_IN_PROMPT = 200 IGNORED_URL_PATTERN = /\.(?:pdf|jpe?g|png|gif|webp|svg|ico|bmp|tiff?|avif|heic)(?:\?|#|$)/i # This model consistently outperforms 5.2 in generating tighter and more # accurate curations. @@ -42,16 +42,15 @@ class Captain::Llm::HelpCenterCurationService < Captain::BaseTaskService substantive how-to, FAQ, troubleshooting, policy, getting-started, account/billing help, or product guide content. - This is a STARTING SET for the user, not a comprehensive corpus. The user will add - more articles later. Each article you pick costs downstream time, compute, and - money to scrape and rewrite — be deliberate. Only include pages with clear, - high-value, substantive help content. When unsure about a page's value, leave it - out. 8 strong articles beat 20 padded ones, even when the input has 20+ candidates. + Aim for broad coverage of the site's substantive help content. Include every + page that genuinely helps a user accomplish a task, understand a feature, or + troubleshoot an issue. Err on the side of including a page when it has real + help content. - Quality over quantity: do not pad with thin, overview, or marketing-adjacent pages - to hit a target count. If a site has only a few genuinely useful pages, return only - those few. The schema allows up to 25 articles, but treat that as a hard ceiling, - not a target — most sites should land well under it. + Still skip thin, overview, or marketing-adjacent pages — don't pad to hit a + target. But on sites with extensive documentation, aim to cover the breadth + of help content. The schema allows up to 60 articles; use as many as the + site warrants. Skip marketing/landing pages, blog posts, login, pricing tiers, legal, careers, press, investor pages. Group your picks into reusable categories — use as many as the content naturally breaks into. @@ -70,26 +69,15 @@ class Captain::Llm::HelpCenterCurationService < Captain::BaseTaskService /careers, /jobs, /about, /team, /investors, /customers, /testimonials, /case-studies, /login, /signup, /register, /legal, /terms, /privacy. - For each article, group 1 to 3 URLs that together cover a single topic. PREFER - grouping whenever pages overlap or complement each other — merged sources give - the writer more context and produce a stronger article than two thin stubs. + Each article should generally come from a single URL. Group 1 to 3 URLs into + one article when one URL is a clear stub, FAQ, or restatement of another on + the same exact topic — e.g. "Bookmarks" + "Using Bookmarks", or an FAQ entry + that restates a deep-dive article. Do not group merely related or adjacent + topics; when in doubt, keep URLs as separate articles — distinct pages almost + always warrant distinct help-center articles. - Strong signals to group multiple URLs (treat any of these as a green light): - - Same topic from different angles: overview + deep-dive, FAQ + how-to, - policy + FAQ, feature page + feature docs. - - Parent topic + its troubleshooting page (e.g. "Bank reconciliation" + - "Problems with bank reconciliation"; "SSO setup" + "SSO not working"). - - Variant-specific guides on the same topic ("SSO setup" + "SSO with Okta"; - "Webhooks overview" + "Webhook payload reference"). - - A how-to split across step or platform pages (install on iOS + Android + web). - - FAQ entries that match a deep-dive article elsewhere on the site. - - Before finalizing your picks, scan them for merge candidates: if two URLs are - about the same topic, they should almost always be one article, not two. - - Don't group across distinct topics that merely share a category ("Setting up SSO" - and "Setting up MFA" stay separate). If a URL is marketing for a feature and - another is the feature's docs, pick the docs and skip the marketing. + If a URL is marketing for a feature and another is the feature's docs, pick + the docs and skip the marketing. Write all category names, category descriptions, and article titles in #{locale_name}. The input page titles and descriptions may be in another language; translate the labels you emit into #{locale_name}.