Altinn / ai

Generative AI exploration
MIT License
0 stars 0 forks source link

Document known issues with docs.altinn.studio as training dataset #20

Open bdb-dd opened 10 months ago

bdb-dd commented 10 months ago

Description

Before attempting to fix specific quality issues related to the documentation training dataset, we should document them and perform a cost-benefit analysis together with the relevant teams.

## Issues identified
- [ ] Change log moved from docs.altinn.studio to Github Releases
- [ ] Architecture documentation is usually not relevant for Studio Designer users
- [ ] Some backend services, such as Storage, are not directly relevant for Studio Designer users
- [ ] Information that is relevant for both target audiences (Studio Designer users, backend app devs) should be clearly tagged
- [ ] Important functional areas are currently only available in Norwegian, while others are only in English. This should be fixed before introducing any AI-enabled content pipelines
- [ ] Translating documentation using AI may require additional metadata in order to achieve desired results. I.e. tagging sections as AI-generated and in need of review
- [ ] Integrating documentation display and search within Altinn Studio itself could improve relevancy significantly as we can automatically set certain search facets based on data available in the app repository, such as version
- [ ] Dual navigation components can encourage documentation writers to group content in a way that is well suited to RAG
- [ ] Documentation written in the style of "user guides" are particularily relevant for generative AI
- [ ] Interleaved Altinn II and Altinn 3 documentation can result in unpredictable output
- [ ] "Launched app examples" should probably have special treatment by the query understanding RAG pipeline
- [ ] The "Community" section is mostly irrelevant for a user in "active development" mode
- [ ] Currently, it is difficult to answer the common question "What has changed since ..."
- [ ] It is not clear whether our documentation should reflect that certain parts of the architecture have significantly different behaviour across versions
- [ ] A specialized RAG pipeline could make our roadmap highly accessible to a non-technical audience
- [ ] Categorizing release notes by type (bug fix, new functionality, breaking change, removal) can make it easier to suppy relevant to to the RAG pipeline