@summarisation/summarise/dist/src/default.yaml.d.ts

cli for summariser

export declare const defaultYaml = "directories:\n  inputs: knowledgearticles/inputs\n  tika: knowledgearticles/tika\n  text: knowledgearticles/text\n  summary: knowledgearticles/summary\n\ntika:\n  type: jar\n  jar: tika-app-2.9.2.jar\n\nai:\n  type: openai\n  url: https://api.openai.com\n  model: gpt-3.5-turbo\n  token: OPENAI_TOKEN\n#   type: sagemaker\n#   url: https://runtime.sagemaker.us-west-2.amazonaws.com/endpoints/summarize\n#   model: mystral.sdflkj.dfgklj\n#   token: SAGEMAKER_TOKEN\n\nnonfunctionals:\n  throttlingPerHour: 1000 # 1000 requests per hour\n  concurrent: 100 # No more than 100 concurrent requests\n  retry:\n    initialInterval: 5000\n    maximumInterval: 20000\n    maximumAttempts: 10\n    nonRecoverableErrors:\n      - Not Found\n      - Bad Request\n\nreport:\n  categories: [ \"description\", \"detection\", \"resolution\", \"validation\", \"summary\" ]\n  fields:\n    value:\n      type: enum\n      enum: [ \"Red\", \"Amber\", \"Green\" ]\n#    example:\n#      type: number\ntransform:\n  type: onePerFile # or onePerPage\n  prompt: |\n    I want you to evaluate a Knowledge Article for an ITSM issue using the following four areas\n    \n    description: Do we have a clear description of what the issue is that this KEDB is about? To be good it should describe the symptoms, the cause and the impact\n    detection: Do we have a clear technical mechanism to determine that the issue exists. For example sql calls, api calls and so on\n    and if we do, do we have enough information. For example with sql we need database connection details. For apis we need the urls\n    resolution: Do we have a clear technical mechanism to resolve the issue. Same example issues (ie. sql needs conneciton issues)\n    validation: Do we have a clear technical mechanism to validate that we have resolved the issue\n    \n    Note that traffic light colours are Red, Amber, Green\n  \n    The results will be used in RAG, so please provide a json object  with the name of the section (the description, detection, resolution and validation)\n    each section is an object having two fields called 'value' and 'summary'. The first is  a  traffic light value, and the second a summary of why that value was chosen.\n    In addition create a final object called 'summary' with the same two fields which score the whole based on the traffic light values, and give a summary about the quality of the KEDB entry.\n    \n    Please do not repeat the description in the summary: we want just a json object with the four sections and the summary\n    \n    The knowledge article is\n    {text}\n  schema: # The json returned has to match this schema\n    type: inline\n    value: true\n";