[scielo-tools-18] Adicionar app ia#25
Conversation
pitangainnovare
left a comment
There was a problem hiding this comment.
- Sugiro que algumas alterações de arquitetura sejam feitas, se houver tempo. Por exemplo:
- Em lugar de ter prompts hardcoded, poderia haver um modelo Django/Wagtail para registrarmos e associar isso aos campos/grupos de dados
- PromptField
- prompt (o prompt em si)
- language (o idioma do prompt)
- target field (o campo alvo, por exemplo, title, author name, etc).
- target group (back, body, end)
- PromptField
- Em lugar de ter prompts hardcoded, poderia haver um modelo Django/Wagtail para registrarmos e associar isso aos campos/grupos de dados
- Sugiro também que o uso de um modelo de IA seja configurável globalmente ou por documento ou por grupo ou por campo
- Podemos querer usar para um mesmo DOCX o modelo mais poderoso para obter metadados, o mais simples para obter os títulos das seções, etc.
| @@ -0,0 +1,34 @@ | |||
| Preciso criar uma sequencia de issue no github como tarefa. | |||
There was a problem hiding this comment.
Sugiro remover este arquivo do PR, pois é uma instrução específica para LLM gerar código ou ajustar o repositório.
| @@ -0,0 +1,26 @@ | |||
| MESSAGES = [ | |||
There was a problem hiding this comment.
Sugiro ter no lugar deste arquivo (back.py) um modelo Django para administrar prompts por:
- Idioma
- Campo
- Grupo (front, body, back)
| @@ -0,0 +1,113 @@ | |||
| import json | |||
There was a problem hiding this comment.
Sugiro ter no lugar deste arquivo (front.py) um modelo Django para administrar prompts por:
- Idioma
- Campo
- Grupo (front, body, back)
| @@ -0,0 +1,62 @@ | |||
| VISION_TASKS = [ | |||
There was a problem hiding this comment.
Sugiro ter no lugar deste arquivo (vision.py) um modelo Django para administrar prompts por:
- Idioma
- Campo
- Grupo (front, body, back)
| logger = logging.getLogger(__name__) | ||
|
|
||
|
|
||
| def extract_text_from_docx(docx_path, limit_chars=30000): |
There was a problem hiding this comment.
Isso é um utilitário que recebe um .DOCX e entrega todos os conteúdos textuais (w:t). Usa etree exclusivamente a partir de word/document.xml, que é o principal arquivo onde há coisas de conteúdo do Word.
É preciso avaliar se é a melhor estratégia ou se falta algum campo que não estamos enxergando (texto dentro de caixas de texto, texto em rodapé, etc). Se quiser extrair também cabeçalho, rodapé, notas e comentários, aí precisa ler outros arquivos do .docx, não só word/document.xml.
Seria interessante ter testes unitários para isso (que avaliam a extração de textos desses campos)
| logger = logging.getLogger(__name__) | ||
|
|
||
|
|
||
| def ollama_tags(request): |
There was a problem hiding this comment.
Tem mais cara de view (poderia estar em views.py)
| ROOT_DIR = Path(__file__).resolve(strict=True).parent.parent.parent | ||
| # core/ | ||
| APPS_DIR = ROOT_DIR / "core" | ||
| LLAMA_MODEL_DIR = ROOT_DIR / "ia/download" |
There was a problem hiding this comment.
Sugiro que o diretório de modelos seja ia/models/*
| @@ -0,0 +1,8 @@ | |||
| JSON_INSTRUCTION = ( | |||
There was a problem hiding this comment.
Aqui tem uma espécie de prompt. Sugiro que seja removido (em favor de um modelo no banco que guarde prompts, campo alvo, formato de resposta, etc).
| logger = logging.getLogger(__name__) | ||
|
|
||
|
|
||
| class LocalProvider: |
There was a problem hiding this comment.
Pelo que entendi, esse aqui é o modelo HuggingFace, certo? Talvez precisemos ajustar os nomes
- Gemini
- Ollama
- HuggingFace (apesar de que isso aqui é uma plataforma).
E de certo modo, Ollama tbm é local, por isso, LocalProvider pode não ser o termo correto aqui.
| @@ -0,0 +1,63 @@ | |||
| from ia.utils.normalizers import stz_language | |||
|
|
|||
There was a problem hiding this comment.
Sobre esse arquivo blocks.py, olhando apenas o código, não fica clara a utilidade disso. Lembro que em alguma versão, nós tinhamos blocos de texto no Wagtail:
- Parágrafo
- Parágrafo com Idioma
- etc.
Mas talvez isso deva ser um modelo (com que achava que fosse vendo a aplicação funcionar).
|
@pitangainnovare grato, vou analisar os comentários. |









O que esse PR faz?
Adiciona o app Django
iade forma autônoma e reusável, com modelos de configuração de provedores (Gemini, Ollama, HuggingFace), serviço de orquestração LLM, tarefas de download, exceções de domínio, utilitários e integração com Wagtail Admin. Mantém o grupoIA Modelsno menu de Settings do Wagtail para preservar o comportamento padrão de navegação do admin. Também expõeIA Modelsno menu principal, sem ocultar entradas padrão já existentes no admin. Remove o filtro global de menu emcore/wagtail_hooks.pyque mantinha apenassps_package_validation, restaurando a navegação padrão completa do Wagtail.Onde a revisão poderia começar?
ia/models.py,ia/wagtail_hooks.py,ia/service.py,config/settings/base.py,config/urls.py.Como este poderia ser testado manualmente?
pip install -r requirements/local.txt.python manage.py migrate.python manage.py check./admin/e confirmar o grupoIA Modelsem Settings com snippets HuggingFace, Ollama e Gemini.Settings > IA Models > HuggingFace.Model name:hugging-quants/Llama-3.2-3B-Instruct-Q4_K_M-GGUFModel file:llama-3.2-3b-instruct-q4_k_m.ggufHuggingFace token: token pessoal de leituraDownloadingno admin).Downloaded.Settings > IA Models > Ollama.http://localhost:11434.Fetch models, selecionar um modelo e validar preenchimento decontext_limit.from ia.service import LLMServicepara validar import.Settings > IA Models > Geminipara validar seleção de provider por prioridade.Como este poderia ser testado automaticamente?
pytest ia/tests.ia.models;LLMService;admin/ia/;IAAdminModelForm.save_allpara criação e atualização;IADatabaseRoutercom e semia_db;mark_referenceemark_referencescom sucesso e erro inesperado.Algum cenário de contexto que queira dar?
O app foi estruturado para funcionar sem dependências de
core.modelsecore.forms, permitindo reuso em outros projetos Django/Wagtail. Foi incluídoIADatabaseRouterpara cenários com banco dedicadoia_db.Screenshots
N/A
Quais são tickets relevantes?
N/A
Referências