Feat/embedding

[jtrecenti]

Adiciona feature de auto label. Por enquanto apenas com OpenAI, mas seria legal usar alguma ferramenta mais geral para lidar com outros modelos

Por exemplo, usando o llm do simonw, que o guilherme recomendou:

import llm, json
from pydantic import BaseModel

class Dog(BaseModel):
    name: str
    age: int

model = llm.get_model("gpt-4o-mini")
response = model.prompt("Describe a nice dog", schema=Dog)
dog = json.loads(response.text())
print(dog)
# {"name":"Buddy","age":3}

Obs: não precisa dar merge ainda, vamos conversar antes

[Copilot]

Pull Request Overview

This PR introduces an automatic labeling feature leveraging the OpenAI API to generate and refine cluster labels. Key changes include:

• The addition of utility functions for generating and refining cluster labels in utils_auto_label.py.
• Integration of the auto-labeling feature into the cluster module.
• An update to the Python version requirement and dependency revisions in pyproject.toml.

Reviewed Changes

Copilot reviewed 5 out of 6 changed files in this pull request and generated 1 comment.

File	Description
src/cluster_facil/utils_auto_label.py	New utilities for generating and refining cluster labels using the OpenAI API.
src/cluster_facil/cluster.py	Added an auto_label_cluster method to integrate automatic labeling into the clustering workflow.
pyproject.toml	Updated the python version requirement and added/updated dependencies including openai and python-dotenv.

Files not reviewed (1)

• .env.example: Language not supported

[bdcdo]

Acho que uma boa ideia seria usar o langchain, porque ele tem muito mais suporte e funções que o llm do simonw.
A função que encaixaria melhor pra gente seria essa: https://python.langchain.com/docs/how_to/chat_models_universal_init/

Única coisa meio chatinha é que ela envolveria incluir uma dependência a mais para cada provedor, o que acrescenta uma dificuldade adicional para quem não programa, mas quer utilizar a biblioteca. No entanto, como eles já vão ter que ir atrás de uma chave de API de qualquer jeito, não vejo grande problema nisso.

[bdcdo]

Achei que a implementação ficou ótima. Vou depois testar pra ver como ficou. Estou bastante curioso pra ver se com esses prompts simples já funciona, ou se pra ficar algo menor precisamos construir um agente.

[bdcdo]

Tava na minha lista de tarefas pensar em que versão de python vamos colocar como mínima. Imagino que trocou para 3.10 por conta do uso do list. O ideal é só identificar qual o menor valor que não quebra o nosso código, certo? Se sim, tudo certo.

[bdcdo]

Tive também problema com isso e acabei solucionando trocando no arquivo utils como o STOPWORDS_PT está definido. Troquei de tupla pra lista e já fiz o push pra main. Acho que podemos deixar essa redundância. O que acha?

[bdcdo]

O random_state padrão tá como 42 em outros lugares. Acho que vale padronizar em um só valor.

[bdcdo]

Considerando que esse é um método de um objeto da classe ClusterFacil, acho que não precisa incluir "cluster" no nome.
Podemos também abrasileirar para "auto_classificar" ou algo do tipo.

[bdcdo]

Acho que o default pode ser menor para economizar tokens. Estamos usando 10 para analisar manualmente e tem funcionado bem.

[bdcdo]

Estou me referindo ao cut_limit

[bdcdo]

Mencionei acima a sugestão de padronizar em 42.
Numa nota mais de desenho da biblioteca, acho que o ideal seria controlar todas as aleatoriedades possíveis para tornar os resultados de cada pesquisador reprodutíveis.

[bdcdo]

E aqui ao random_state

[bdcdo]

Langchain nos ajudaria também a garantir que todos os provedores nos forneçam respostas parseadas em json

[bdcdo]

Se isso vai se repetir, acho que, na hora de generalizar para poder receber outras APIs, podemos criar uma função que lida com as chaves e a armazena junto ao cluster_facil.

[bdcdo]

Tenho a impressão de que para essa revisão um llm de raciocínio funcionaria melhor. Podemos testar ter como padrão o o4-mini-low.

[bdcdo]

Suggested change

	prompt = (
	"Dado o seguinte conjunto de textos, gere um rótulo curto (tema) que represente o cluster. "
	"O rótulo deve ser claro, conciso e descritivo."
	)
	prompt = (
	"Dado o seguinte conjunto de textos, gere um rótulo curto (tema) que represente o cluster. "
	"O rótulo deve ser claro, conciso e descritivo.\n"
	"Se não for possível identificar um padrão claro entre as decisões, responda "falta_coesão".
	)

Uma parte importante das rodadas de clusterização é entender quais clusters estão coesos e quais não estão. Acho que precisamos indicar isso explicitamente como uma possibilidade, para que esses casos possam ser novamente clusterizados.

Nesse sentido, seria interessante eventualmente incluir a possibilidade de que uma segunda rodada de auto_label seja automaticamente aplicada apenas nos casos considerados não coesos. E, a médio prazo, poderiamos automatizar seguidas rodadas de reclusterização.

Ligado a isso, registro aqui algum ceticismo em relação a se modelos menores vão ser capazes de fazer essa decisão de falta de unidade. Acho que os modelos menores vão se sentir mais pressionados a dizer que há algo em comum, pelo que já tive de experiência em outros casos.

[bdcdo]

Eu me sentiria confortável até em reduzir para metade os clusters que aparecem aqui.

Acho que vale incluir também algum tipo de conferência de tamanho dos tokens nessa chamada, para evitar passar do limite em casos limite.