Feature Request: Tagging and Source Prioritization

[kursataktas]

As suggested by @costas80 on the Discord thread, Gurubase could have a feature to tag sources and prioritize them based on it. This would allow certain sources to be prioritized when working with different documentation sets.

Key Points:

• Tag sources
  • Likely we need to let users tag webpage data sources rather than all pages within a domain.
• Prioritize sources based on context or tags on answer generation.
• Optionally, create a Sub Guru logic for better control.
  • The idea is that users can create sub Gurus by selecting data sources from the parent Guru.

This is still in the idea stage and open for discussion. Due to high development time, I’m considering this low priority until there is more interest from others.

[kursataktas]

The outlines of this task have started to become generally defined.
Here are the nearly completed requirements and usage presented by @costas80.

---

• What is the goal: To apply different weighting of sources when determining the best answer depending on a question's optional context.
• Backend implications: Allow a Guru admin to define zero or more supported contexts (aka tags). For each of these the admin can adapt the relative weights of sources, effectively prioritizing more relevant sources/codebases over others. I don't think its necessary to have different sets of sources altogether given that instead of removing irrelevant sources the admin could just assign very low weights. In fact having a single set of sources will likely be easier maintenance-wise as we would not have to reindex the same sources multiple times whenever there is a change. Finally, the admin should be able to apply also a default weighting (i.e. all sources belong to a default/hidden context).
• Frontend implications (widget): The widget config foresees a configurable callback function returning a string that is called before each question is asked. The value returned from this is the context (aka "tag"), that is signaled to the backend. This could be as fine-grained as the Guru admin wants, ranging from no value (i.e. default context applied), to a fixed value per documentation set, to even a value for specific pages/sections (as long as the relevant context is supported in the backend - the default being applied if not).
• Frontend implications (Gurubase.io): Given that we don't have the benefit of the widget with its callbacks here, we could allow the user to select a specific context from a dropdown list (or something similar) presented as e.g. suggested topics. For this purpose we could foresee that these contexts could be configured by the admin as visible or not on Gurubase.io, along with a user-friendly label (assuming a key and not a full label is used internally and when signaled by the widget).