[Feature]: Issue 45 | Content Classification (Contextual Tagging)#313
[Feature]: Issue 45 | Content Classification (Contextual Tagging)#313TylerB24890 wants to merge 64 commits intoWordPress:developfrom
Conversation
…on buttons are attached to the panel visibility.
… and function calls with pre-loaded objects.
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## develop #313 +/- ##
=============================================
+ Coverage 57.85% 58.07% +0.21%
- Complexity 615 679 +64
=============================================
Files 46 49 +3
Lines 3165 3513 +348
=============================================
+ Hits 1831 2040 +209
- Misses 1334 1473 +139
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
|
@jeffpaul -- Thanks for the feedback! I've resolved 1, 2 & 4 -- see below regarding 3 & 5;
That might be a little challenging with this UI being in the sidebar. We might be better off going with a dedicated modal if we're to support that. Is that something we would want to do as opposed to the sidebar UI?
Clicking the suggestion (outside of the 'X') will automatically create (if new) & assign the post to the term -- but I would have expected the Save button for the post to re-appear, since we changed the post state 🤔 I'll have to see what's going on there.
Personally I feel "Regenerate" makes more sense because the initial button says "Generate", but happy to update it if you prefer. |
dkotter
left a comment
dkotter
left a comment
There was a problem hiding this comment.
Handful of suggestions / comments / concerns, happy to talk through any of those as needed.
Would also be great to get some E2E tests here prior to this getting merged.
I'm fine holding off for that now as the current implementation is good.
For me clicking the term and not the
Except the initial buttons say 
|
…or the json response.
…d terms. Update system instructions and unit tests accordingly.
Took care of the existing terms being sent to the LLM. We no longer restrict the number of suggestions it will return and instead filter suggestions in post-processing as needed. We do still pass the currently assigned terms, though. I feel this provides it additional context and prevents redundant suggestions. @dkotter I rebased the |
I am seeing image generation/edit code in this PR that shouldn't be here. Wondering if you just need to merge the latest changes from |
…enation, code references, directories, etc...
|
@dkotter Added some E2E tests in the latest commit. This is ready for another code review when you're able. EDIT: Not sure why the other E2E tests are failing here, but the ones I've added are passing. |
| } | ||
|
|
||
| // Fetch existing terms for post-processing (matching, not for the prompt). | ||
| $existing_terms = $this->get_existing_terms( $taxonomy ); |
There was a problem hiding this comment.
We only need existing terms if the strategy is STRATEGY_EXISTING_ONLY, correct? If so, I'd suggest setting this to an empty array if that isn't the strategy to avoid querying for terms we'll never use
| - Do not suggest duplicate or near-duplicate terms. | ||
| - Do not suggest terms listed in <assigned-terms> — they are already applied to this post. | ||
| - Prioritize specificity and relevance over breadth. | ||
| - Sort suggestions by confidence, highest first. |
There was a problem hiding this comment.
I would remove this. We can easily sort ourselves after the fact and LLM's often struggle with following these types of instructions
| * @param int $max_suggestions The maximum number of suggestions to generate. | ||
| * @return int The filtered max suggestions. | ||
| */ | ||
| return apply_filters( 'wpai_content_classification_max_suggestions', $max_suggestions ); |
There was a problem hiding this comment.
Since we only support from 1-10, we may want to validate that here since someone could use this filter to return a negative number or a number greater than 10. I do think if that happens the Ability itself will return an error and maybe that's good enough but if we want to be more error-proof, we could validate things here after the filter and return a default if it doesn't match that range
| $post_id = isset( $args['post_id'] ) ? absint( $args['post_id'] ) : null; | ||
|
|
||
| if ( $post_id ) { | ||
| $post = get_post( $args['post_id'] ); |
There was a problem hiding this comment.
| $post = get_post( $args['post_id'] ); | |
| $post = get_post( $post_id ); |
| return new WP_Error( | ||
| 'post_not_found', | ||
| /* translators: %d: Post ID. */ | ||
| sprintf( esc_html__( 'Post with ID %d not found.', 'ai' ), absint( $args['post_id'] ) ) |
There was a problem hiding this comment.
| sprintf( esc_html__( 'Post with ID %d not found.', 'ai' ), absint( $args['post_id'] ) ) | |
| sprintf( esc_html__( 'Post with ID %d not found.', 'ai' ), $post_id ) |
| continue; | ||
| } | ||
|
|
||
| // For existing_only strategy, skip terms that don't exist. |
There was a problem hiding this comment.
So I know this contradicts some of my earlier feedback and leaving this more as a discussion than something we have to change. But in testing, if I'm in the existing_only strategy, I often don't get terms from the LLM that match my existing terms and thus I'll get no results.
Wondering if there's a middle ground here where we get the top 100 terms (by count) and send those to the LLM when in the existing_only strategy? This would avoid prompt bloat but would still give the LLM something to look at and more likely give results.
3 participants
What?
Closes #45
This PR introduces Content Classification (Contextual Tagging) to the AI Experiments plugin. It allows for one-click AI-powered suggestions for post tags and categories based on a comprehensive analysis of the post's content (as well as title and excerpt). It helps authors apply a relevant and consistent taxonomy, improving content organization, discoverability, and on-site navigation.
Why?
Properly categorizing and tagging content is fundamental to an effective content strategy. It helps readers find related articles and signals relevance to search engines. However, this process is often inconsistent and subjective. This feature removes the guesswork by providing intelligent, context-aware suggestions, leading to a better-organized and more interconnected website.
How?
ContentClassificationExperiment.editor.PostTaxonomyTypeand inject the Experiment UI (buttons, suggestions)wpai_content_classification_content- Filter content before AI processingwpai_content_classification_suggestions- Filter suggestions after AI processingwpai_content_classification_strategy- Filter the strategy settingwpai_content_classification_max_suggestions- Filter the max suggestions settingUse of AI Tools
Testing Instructions
postpost type and confirm the Suggest Categories and Suggest Tags buttons are available in the term selector panels.Screenshots or screencast
Settings UI:
Suggestion UI (block editor):
New Term Suggestions:
Existing Term Suggestions:
Additional Notes
ai_contextual_tagging_strategyfilter, but an inline UI to do so is possible.categoryandpost_tag)