Substitua as abordagens tradicionais de PNL por engenharia imediata e modelos de linguagem grande (LLMS) para classificação de texto de tickets do Jira. Um exemplo de código passo a passo
Lembra-se da quadra em que qualificar texto significava embarcar em uma jornada de estágio de máquina? Se você já está no espaço de ML há tempo suficiente, provavelmente já testemunhou pelo menos uma equipe desvanecer na toca do coelho na construção do sistema de classificação de texto “perfeito”. A história geralmente é mais ou menos assim:
- Mês 1: “Vamos treinar rapidamente um padrão de PNL!”
- Mês 2: “Precisamos de mais dados de treinamento…”
- Mês 3: “Isso é bom o suficiente”
Durante anos, a classificação de texto caiu no domínio do ML clássico. No início da minha curso, lembro-me de treinar uma máquina de vetores de suporte (SVM) para classificação de e-mail. Muito pré-processamento, iteração, coleta de dados e rotulagem.
Mas cá está a diferença: estamos em 2024 e os modelos generativos de IA podem “geralmente” classifique o texto fora da caixa! Você pode edificar um sistema robusto de classificação de tickets sem coletar milhares de exemplos de treinamento rotulados, gerenciar pipelines de treinamento de ML ou manter modelos personalizados.
Nesta postagem, veremos porquê configurar um sistema de classificação de tickets Jira usando grandes modelos de linguagem no Amazon Bedrock e outros serviços AWS.
ISENÇÃO DE RESPONSABILIDADE: Sou arquiteto GenAI na AWS e minhas opiniões são minhas.
Por que qualificar tickets do Jira?
Uma pergunta geral das empresas é entender porquê as equipes gastam seu tempo. O Jira possui recursos de marcação, mas às vezes pode falhar devido a erro humano ou falta de granularidade. Ao fazer leste tirocínio, as organizações podem obter melhores insights sobre as atividades de sua equipe, permitindo decisões baseadas em dados sobre alocação de recursos, investimento em projetos e interrupção.
Por que não usar outras abordagens de PNL?
Os modelos tradicionais de ML e transformadores menores porquê o BERT precisam de centenas (ou milhares) de exemplos rotulados, enquanto os LLMs podem qualificar o texto imediatamente. Em nossos testes de classificação de tickets Jira, uma abordagem de engenharia imediata igualou ou superou os modelos tradicionais de ML, processando mais de 10 milénio tickets anuais por aproximadamente US$ 10/ano usando Claude Haiku (excluindo outros custos de serviços da AWS). Aliás, os prompts são mais fáceis de atualizar do que os modelos de retreinamento.
Esse repositório do github contém um aplicativo de modelo que se conecta ao Jira Cloud, classifica tickets e os gera em um formato que pode ser consumido por sua instrumento de quadro favorita (Tableu, Quicksight ou qualquer outra instrumento comportável com CSVs).
Aviso importante: leste projeto implanta recursos em seu envolvente AWS usando Terraform. Você incorrerá em custos pelos recursos da AWS usados. Esteja cônscio dos preços de serviços porquê Lambda, Bedrock, Glue e S3 em sua região AWS.
Pré-requisitos
Você precisará ter o terraform instalado e a AWS CLI instalada no envolvente do qual deseja implantar leste código
A arquitetura é bastante simples. Você pode encontrar detalhes aquém.
Lanço 1: Uma função AWS Lambda é acionada em um cron job para buscar tickets do jira com base em uma janela de tempo. Esses tickets são portanto formatados e enviados para um bucket S3 sob o /não processado prefixo.
Lanço 2: Um trabalho de colagem é acionado /não processado objeto coloca. Isso executa uma tarefa de desduplicação do PySpark para prometer que nenhum ticket geminado chegue ao quadro. Os tickets deduplicados são portanto colocados no /encenado prefixo. Isso é útil para casos em que você carrega tickets manualmente e também depende da procura automática. Se você puder prometer que não há duplicatas, poderá remover esta lanço.
Lanço 3: Uma tarefa de classificação é iniciada nos novos tickets chamando o Amazon Bedrock para qualificar os tickets com base em um prompt para um padrão de linguagem grande (LLM). Em seguida a classificação, os resultados finalizados são enviados para o /processado prefixo. A partir daqui, você pode obter o CSV processado Sua visita nos ajuda a continuar oferecendo o melhor para você! qualquer instrumento de quadro que desejar e que possa consumir um CSV.
Para principiar, clone o repositório github supra e vá para o diretório /terraform
$ git clone https://github.com/aws-samples/jira-ticket-classification.git$ cd jira-ticket-classification/terraform
Execute o terraform init, planeje e aplique. Certifique-se de ter o terraform instalado em seu computador e a AWS CLI configurada.
$ terraform init$ terraform plan
$ terraform apply
Depois que a infraestrutura for implantada em sua conta, você poderá velejar até o AWS Secrets Manager e atualizar o sigilo com suas credenciais do Jira Cloud. Você precisará de uma chave de API, URL base e e-mail para ativar o pull automático
Sua visita nos ajuda a continuar oferecendo o melhor para você! c" width="700" height="191" loading="lazy" role="presentation"/>E é isso!
Você pode (1) esperar que o Cron inicie uma procura automática, (2) exportar os tickets para CSV e carregá-los no prefixo do bucket S3 /unprocessed ou (3) acionar manualmente a função Lambda usando um teste.
Aguarde a procura:
Jira fetch usa uma função Lambda com um evento cron Cloudwatch para acioná-lo. O Lambda extrai o sigilo da AWS e usa uma solicitação get em um loop while para restabelecer resultados paginados até que a consulta JQL seja concluída:
Sua visita nos ajuda a continuar oferecendo o melhor para você! no np ra rb rc bp rd bb bk">def fetch_jira_issues(base_url, project_id, email, api_key):
url = f"{base_url}/rest/api/3/search"# Calculate the date 8 days ago
eight_days_ago = (datetime.now() - timedelta(days=8)).strftime("%Y-%m-%d")
# Create JQL
jql = f"project = {project_id} AND created >= '{eight_days_ago}' ORDER BY created DESC"
# Pass into params of request.
params = {
"jql": jql,
"startAt": 0
}
all_issues = []
auth = HTTPBasicAuth(email, api_key)
headers = {"Accept": "application/json"}
while True:
response = requests.get(url, headers=headers, params=params, auth=auth)
if response.status_code != 200:
raise Exception(f"Failed to fetch issues for project {project_id}: {response.text}")
data = json.loads(response.text)
issues = data['issues']
all_issues.extend(issues)
if len(all_issues) >= data['total']:
break
params['startAt'] = len(all_issues)
return all_issues
Em seguida, ele cria uma representação de string de um CSV e a carrega no S3:
def upload_to_s3(csv_string, bucket, key):
try:
s3_client.put_object(
Bucket=bucket,
Key=key,
Body=csv_string,
ContentType='text/csv'
)
except Exception as e:
raise Exception(f"Failed to upload CSV to S3: {str(e)}")Trabalho de cola
Um evento S3 no prefixo /unprocessed inicia um segundo lambda que inicia um trabalho do AWS Glue. Isso é útil quando há vários pontos de ingressão pelos quais os tickets do Jira podem entrar no sistema. Por exemplo, se você quiser fazer um preenchimento.
import boto3 # Initialize Boto3 Glue client
glue_client = boto3.client('glue')
def handler(event, context):
# Print event for debugging
print(f"Received event: {json.dumps(event)}")
# Get bucket name and object key (file name) from the S3 event
try:
s3_event = event['Records'][0]['s3']
s3_bucket = s3_event['bucket']['name']
s3_key = s3_event['object']['key']
except KeyError as e:
print(f"Error parsing S3 event: {str(e)}")
raise
response = glue_client.start_job_run(
JobName=glue_job_name,
Arguments={
'--S3_BUCKET': s3_bucket,
'--NEW_CSV_FILE': s3_key
}
)
O próprio trabalho do Glue é escrito em PySpark e pode ser encontrado no repositório de código cá. A epílogo importante é que ele faz um tenente junte-se usando os IDs de problema nos itens no novo CSV em relação a todos os IDs nos CSVs /staged.
Os resultados são portanto enviados para o /encenado prefixo.
Qualificar tíquetes do Jira:
É cá que fica interessante. Acontece que o uso da engenharia imediata pode ter um desempenho igual, se não melhor, do que um padrão de classificação de texto usando algumas técnicas.
- Você pode definir as classificações e suas descrições em um prompt,
- Peça ao padrão para pensar passo a passo (Ergástulo de Pensamento).
- E portanto produza a classificação sem precisar treinar um único padrão. Veja a solicitação aquém:
Reparo: É importante validar sua solicitação usando um subconjunto de tickets classificados/rotulados com curadoria humana. Você deve executar esse prompt no conjunto de dados de validação para prometer que ele esteja desempenado com a forma porquê você espera que os tickets sejam classificados
SYSTEM_PROMPT = '''
You are a support ticket assistant. You are given fields of a Jira ticket and your task is to classify the ticket based on those fieldsBelow is the list of potential classifications along with descriptions of those classifications.
ACCESS_PERMISSIONS_REQUEST: Used when someone doesn't have the write permissions or can't log in to something or they can't get the correct IAM credentials to make a service work.
BUG_FIXING: Used when something is failing or a bug is found. Often times the descriptions include logs or technical information.
CREATING_UPDATING_OR_DEPRECATING_DOCUMENTATION: Used when documentation is out of date. Usually references documentation in the text.
MINOR_REQUEST: This is rarely used. Usually a bug fix but it's very minor. If it seems even remotely complicated use BUG_FIXING.
SUPPORT_TROUBLESHOOTING: Used when asking for support for some engineering event. Can also look like an automated ticket.
NEW_FEATURE_WORK: Usually describes a new feature ask or something that isn't operational.
The fields available and their descriptions are below.
Summmary: This is a summary or title of the ticket
Description: The description of the issue in proveniente language. The majority of context needed to classify the text will come from this field
* It is possible that some fields may be empty in which case ignore them when classifying the ticket
* Think through your reasoning before making the classification and place your thought process in
* Once you have finished thinking, classify the ticket using ONLY the classifications listed above and place it in
USER_PROMPT = '''
Using only the ticket fields below:
{summary}
{description}
Classify the ticket using ONLY 1 of the classifications listed in the system prompt. Remember to think step-by-step before classifying the ticket and place your thoughts in
When you are finished thinking, classify the ticket and place your answer in
'''
Adicionamos uma classe facilitar que encadeia as chamadas para Bedrock para apressar as coisas:
import boto3
from concurrent.futures import ThreadPoolExecutor, as_completed
import re
from typing import List, Dict
from prompts import USER_PROMPT, SYSTEM_PROMPTclass TicketClassifier:
SONNET_ID = "anthropic.claude-3-sonnet-20240229-v1:0"
HAIKU_ID = "anthropic.claude-3-haiku-20240307-v1:0"
HYPER_PARAMS = {"temperature": 0.35, "topP": .3}
REASONING_PATTERN = r'(.*?) '
CORRECTNESS_PATTERN = r'(.*?) '
def __init__(self):
self.bedrock = boto3.client('bedrock-runtime')
def classify_tickets(self, tickets: List[Dict[str, str]]) -> List[Dict[str, str]]:
prompts = [self._create_chat_payload
Tags:
Crédito: Manadeira Original
Adriano Pina
Análise de Sistemas | SEO e Google Ads | Fundador da Loja Script PHP Aqui & Marca Shoslh de tecnologia
Especialista em transformar ideias em soluções digitais e acelerar o crescimento online.
