Feat/update llm schema #45
Conversation
| createdat :: timestamp as created_at, | ||
| referenceid as reference_id, | ||
| referenceid :: uuid as reference_id, |
There was a problem hiding this comment.
É uma convenção colocar o ID do KR nesse campo na sumarização, mas não é uma constraint. Ou seja, pode ser que outros casos de uso do LLM (ou até esse mesmo caso) no futuro salvem dados em outros formatos aqui. Recomendo manter o referenceId :: text.
There was a problem hiding this comment.
Entendi, mas me parece estranho não termos uma convenção de usar a mesma tecnologia para criação de id's.
Vou alterar aqui para ser o mais genérico possível.
Depois vou estudar um pouco boas práticas, pq quando esse momento chegar nessa tabela (de termos id's que não são uuid), minha vontade é separar nas dimensions e refazer o casting para uuid lá
Exemplo:
action: X1, entity: Y1, id: uuid -> criar uma dim__llm_actionX1_entityY1 -> fazer casting com uuid
action: X2, entity: Y2, id: mongoid -> criar uma dim__llm_actionX2_entityY2 -> fazer casting para text
Só que não sei se é best practice, mas funciona.
There was a problem hiding this comment.
É que este é um caso de ID diferente de uma chave primária, mas também é normal existirem diferentes tipos de ID em uma mesma aplicação, porque esse formato também atende a um caso de uso (ex: UUID vs Snowflake tem aplicações diferentes).
De resto, o que você propôs parece fazer sentido sim e é mais ou menos a ideia que eu tinha para lidar com estes casos. Dentro do domínio de OpenAiCompletion, o referenceId é genérico por design. Porém, dentro de cada subdomínio ele segue uma convenção específica, então é perfeitamente válido tratar isso para análises que contemplem o escopo action-entity. Tudo é uma questão de caso de uso e, para cada um deles, podemos criar as abstrações que precisarmos.
| ), | ||
|
|
||
| final as ( | ||
| select | ||
| SPLIT_PART(id, '.', 3) :: text as id, | ||
| input, | ||
| SPLIT_PART(id, '.', 3) :: uuid as id, |
There was a problem hiding this comment.
Não sei se eu entendi o motivo de você estar fazendo isso, mas acho que rolou uma confusão sobre o formato do id. As duas primeiras partes dele são a action e a entity, mas a terceira não é um UUID. Na verdade, é um hash calculado a partir do input/prompt da completion em questão, e ele é construído dessa forma para garantir idempotência de uma forma fácil e rápida.
Além disso, recentemente eu adicionei a versão do prompt no final usando o formato @<version>.<patch>, então talvez quebre essa função. Fiz isso para garantir que uma completion vai ser gerada novamente quando uma nova versão do prompt é liberada.
Resumindo, o formato do id é:
id = `${action}.${entity}.${objectHash(input)}@${promptVersion}`
// Exemplo
id = '[email protected]'Sendo assim, recomendo manter o mapeamento dessa coluna "as is" (em text e sem split), pois não vai ter nenhuma informação muito útil que pode ser extraída dele a não ser o id em si.
There was a problem hiding this comment.
Mas, se realmente for necessário ter IDs em formato UUID, recomendo que você faça uma conversão utilizando o UUID v5 e um namespace fixo qualquer (ex: 00000000-0000-0000-0000-000000000000):
There was a problem hiding this comment.
Got it, vlw pela explicação!
igoromote
force-pushed
the
feat/update_llm_schema
branch
from
bb2b4dc
to
ebad845
Compare
☕ Purpose
A brief summary about the purpose of this PR.
🧐 Checklist
🐞 Testing
A brief description about how the reviewer can test my PR.
# don't forget to insert cli commands🍩 Further details
Anything that the reviewer should know before approving it.
🔗 Related PRs
This PR is related to some other PRs in different services, they are:
project#PR_NUMBER