Looking under the hood of this feature
Introduction
In Skill Kit, when creating a custom Skill or updating a cloned one, you may have noticed the ability to add pre-processor and post-processor scripts.
The purpose of this article is to shed light on the feature, underlying mechanism, participating entities and share example use cases and tips.
Use Cases: Practical Examples
The feature is useful when having unique data restriction requiring customization (example: Anonymization) or specific data items requiring transformation for the LLM handling (example: Unique organizational terminology).
Skill Kit Feature: Overview and capabilities
This feature can be found in the ‘Skill settings’ tab when the provider is selected.
This feature enables you to handle the payload, via a script (validator) before it is sent to the LLM (‘Provider preprocessor’) and when the LLM response is received, before the subflow returns the output to downstream steps (‘Provider postprocessor’).
You may use an existing validator or create your own.
Tips:
-You may add one or more pre and post scripts. When there’s more than one script, notice the order, the top script will be executed first.
-To understand the payload structure, you may capture is in the syslog in run time:
By adding a command such as : gs.info("Payload is: " + JSON.stringify(payload));
Review the payload in any JSON editor of your choice (Ex: https://jsoneditoronline.org/ ).
This will enable you to navigate within the payload when tailoring the script to your needs.
Example:
if (payload?.relatedlists_data) {
var relatedlists = payload.relatedlists_data;
When logging payloads for debugging, ensure sensitive data is not exposed in production environments.
Behind the Scenes- Tables’ Structure and Entity Relations:
‘sys_one_extend_capability_definition’ table: One of the Generative AI Controller tables, Defines the capbaility’s implementation (In this context the Skill’s) and its execution via Workflow subflows. For the skill it is the sub-flow calling the LLM (Example: ‘Now LLM Integration’).
‘sys_generative_ai_validator’ table (requires ‘maint’ access). Stores the Script.
The validator is defined as a separate entity as the same validator can be associated to multiple capabilities.
‘sys_generative_ai_request_validator’ and ‘sys_generative_ai_response_validator’ (also ‘maint’ access) hold the association of the capability (Skill) in ‘document_id’ and the related validator. The ‘order’ field holds the execution order in case of more than one validator (See screenshot).
All this is to shed light- These records are created automatically when saving the processor via Skill Kit.
It all comes together when the selected LLM provider for the skill executes the associated LLM sub-flow which executes the pre and post processors (See next section).
Tip:
-If you do not want to open Skill kit every time you update the script, you may call a script include from the validator script and maintain it ‘outside’ the tool.
- The validator script itself will reference the Script Include
- You cannot directly bind Script Includes as validators; validators must remain script records
-As the execution is part of a sub-flow, It is Important to maintain payload structure integrity to prevent sub-flow failures (see next section).
Behind the Scenes- Triggering Mechanism:
In the capability definition table ‘sys_one_extend_capability_definition’ you’ll find the API associated to your capability, which is an LLM Integration sub-flow.
Open the sub-flow in Flow Designer to review the steps which execute Pre and Post processing.
The LLM integration sub-flow calls two flow actions:
‘GenAI Preprocessor’ execute the related validators, request validator as preprocessor. ‘GenAI Response Postprocessor’ executes the response validator as post processor.
Tip:
-While debugging, you may use the sub-flow’s execution to review the actual processing of the validator.
