- Pi-C.A.R.D é um assistente de voz com IA que roda de forma totalmente local no Raspberry Pi, um projeto que implementa funções de LLM conversacional no hardware do Raspberry Pi
- Há duas formas de interação: por wake word com
main.py e por botão GPIO com main_button.py; durante a conversa, não é preciso repetir a wake word
- O histórico da conversa pode ser ajustado em
config.py, e reduzir o tamanho da memória pode trazer respostas mais rápidas
- Para ser rápido e leve, usa implementações em C++ como whisper.cpp e llama.cpp, e para decidir quando acessar informações externas usa o
tool-bert2, um BERT ajustado
- Recursos baseados em câmera aparecem em vários trechos do README com instruções de configuração, mas há um aviso de que eles foram removidos temporariamente por causa de mudanças no suporte a vision model no llama.cpp
O que o Pi-C.A.R.D faz
- Pi-C.A.R.D é um assistente baseado em IA que roda no Raspberry Pi e tem como objetivo processar localmente tarefas que LLMs padrão, como o ChatGPT, executam em um ambiente de conversa
- O nome é a sigla de Raspberry Pi - Camera Audio Recognition Device
- O projeto continua em desenvolvimento, e informa que issues e pull requests são bem-vindos
- Diz que o novo suporte a Docker deve facilitar a configuração e as modificações
- Ainda não há vídeo de apresentação, mas ele será disponibilizado no futuro
Como funciona
-
Modo wake word
- Ao executar
main.py, o sistema escuta a wake word e inicia a conversa
- As wake words padrão são
"raspberry", "barry", "razbear"
- Depois que a conversa começa, não é necessário repetir a wake word a cada vez
- Dizer algo como
"stop", "exit", "goodbye" encerra a conversa
- A wake word e os comportamentos relacionados podem ser alterados em
config.py
-
Modo botão
- Usando protoboard, fios e um botão, é possível iniciar a conversa com um botão GPIO
- O fluxo é pressionar o botão e depois falar o comando, apresentado no README como uma forma de interação mais fluida
- A configuração do botão segue as instruções de
main_button.py
- Na versão com botão, é possível iniciar a conversa com o botão ou interromper o assistente a qualquer momento
-
Memória da conversa
- O chatbot tem memória de conversa configurável
- Isso permite fazê-lo repetir falas anteriores ou tratar com mais detalhes um tema anterior
- Se quiser respostas mais rápidas, é possível definir um valor de memória menor em
config.py
Objetivo e limitações da execução local
- O objetivo do projeto é verificar quão eficiente pode ser um assistente de voz totalmente offline em um hardware relativamente barato como o Raspberry Pi
- Como todo o processamento é feito localmente, ele não é tão poderoso nem tão rápido quanto sistemas baseados em nuvem
- O README avalia que houve grandes avanços em modelos LLM pequenos no último ano, e que este projeto também pode melhorar junto com isso
- O motivo de não ter sido feito como app é que a parte mais difícil foi justamente fazer um assistente de voz totalmente offline rodar rapidamente no Raspberry Pi
- Explica que, se essa abordagem funciona, sistemas semelhantes podem rodar mais rápido em hardwares mais potentes
Execução e configuração
- Depois de baixar o repositório e concluir os requisitos e a configuração, execute com o comando abaixo
python main.py
- A versão com botão é executada com o comando abaixo
python main_button.py
- A execução com Docker é apresentada como a forma recomendada e usa os comandos abaixo
sudo docker-compose build
sudo docker-compose up
- O suporte a Docker foi adicionado recentemente e pode não funcionar perfeitamente
- O modo com Docker funciona apenas na versão com wake word, e ainda não está claro como repassar o acesso ao GPIO para o contêiner
Software e ferramentas usados
- Para criar um sistema rápido e leve, são usadas implementações em C++ sempre que possível
- A transcrição de áudio usa whisper.cpp, e a configuração deve seguir o guia de início rápido
- O README explica que usa llama.cpp para o recurso de visão, mas o aviso no topo informa que a câmera foi removida temporariamente porque o llama.cpp não dá mais suporte ativo a vision model
- Para que o assistente funcione mais como um assistente de verdade, ele oferece alguns recursos de acesso a ferramentas
- A decisão de acessar ferramentas é feita por meio do tool-bert
- O
tool-bert2 é um BERT ajustado que decide quando acessar informações externas
- O método para criar esse modelo é explicado no repositório do tool-bert
- Para ativar o acesso a ferramentas, é preciso verificar as chaves e secrets necessários em
.env.example
Estado da câmera e dos recursos de visão
- No corpo do README, o projeto é apresentado como capaz de tirar fotos com uma câmera conectada ao Raspberry Pi, descrever o que aparece e responder perguntas sobre a imagem
- A configuração do recurso de visão é feita alterando
vision_model para vlm em config.py
- O modelo mencionado para uso é o Qwen2-VL-2B-Instruct
- Como o tamanho dos tokens de imagem de entrada é dinâmico, reduzir o tamanho da foto capturada pode diminuir o tempo de inferência
- Porém, segundo o aviso no topo do projeto, o recurso de câmera está removido temporariamente no momento
Hardware necessário
- A configuração básica de hardware é Raspberry Pi 5 Model B, microfone USB e alto-falante
- O microfone USB e o alto-falante são conectados às portas USB do Raspberry Pi
- A câmera é conectada à porta de câmera do Raspberry Pi
- Os componentes usados no README são os seguintes
- O Raspberry Pi 5 usa uma nova porta de câmera, então é necessário um novo conector de câmera
- O conector de câmera é opcional, mas precisa ser comprado caso queira usar o recurso de câmera
- Informa que a parte inicial deste tutorial ajudou na configuração do botão GPIO
- O projeto foca em funcionar no Raspberry Pi 5, mas explica que também pode funcionar em outros dispositivos
Roadmap e andamento
- Os itens marcados como concluídos incluem funções básicas de conversa, recurso de câmera, benchmark de tempo de resposta, testes de overclock e exploração de formas de reduzir o tempo do whisper
- Também aparecem como concluídos a função de interromper o assistente e fazer uma nova pergunta, o uso de custom tuned model e melhorias no
tool-bert, que é o modelo de funções de serviços externos
- Testes com alimentação portátil e a dockerização para mais testes em mais dispositivos também estão marcados como concluídos
- Entre os itens restantes estão um tutorial e vídeo melhores, geração opcional de modelo com entropix, testes com outros idiomas e adição de mais serviços externos
- O quadro do Notion para acompanhar o progresso ainda não está concluído, e o link é fornecido
1 comentários
Opiniões do Hacker News
Eu queria criar um assistente de voz totalmente offline, que não precisasse de nenhuma conexão com a internet, para proteger a privacidade do usuário e impedir que os dados fossem enviados a servidores de terceiros.
Boa iniciativa, obrigado
Fico curioso se isso roda apenas no Pi5 ou também em outras placas que não sejam Raspberry Pi
Falando sério, o nome chamou minha atenção, e depois de ler a apresentação pensei: “se for uma Alexa que não faz upload de tudo que eu digo para a Amazon, talvez seja útil para mim também”.
Se a palavra de ativação padrão for “hey assistant”, eu sugeriria “Computer” :) claro que a voz teria que soar como https://en.wikipedia.org/wiki/Majel_Barrett
O que eu preciso é de um assistente de voz que dê conta de rodar em um RPi 4, integre com o HomeAssistant e seja somente offline, sem enviar meus dados para lugar nenhum.
Comparado com o que vi até agora, este projeto parece atender a quase todos os requisitos, então parece muito bem feito.
Além disso, se alguém tiver recomendações de microfones compatíveis com RPi para um uso tipo Alexa, gostaria de saber
É difícil rodar um modelo de linguagem grande de forma prática no 4B, mas não precisa necessariamente ser baseado em um modelo de linguagem grande.
Na comunidade do Rhasspy, é comum o padrão de fazer a detecção barata e leve da palavra de ativação localmente em dispositivos satélite com microfone — para isso um 4B deve bastar — e transmitir a gravação real pela rede local para um hub central, para obter resultados melhores
Dá para encontrar no eBay por cerca de 15 a 20 dólares
A NabuCasa contratou o principal desenvolvedor do Rhasspy para trabalhar nesse recurso, e ele continua melhorando a cada atualização
“Por que Pi-card? Raspberry Pi - Camera Audio Recognition Device”: parece que perderam a oportunidade de usar LCARS.
Poderia ser LLM Camera Audio Recognition Service e, claro, responder à palavra-chave “computer”. Se rodar também fora do Pi, poderia virar LCARS
Lê-se 100% como Picard e é mais fácil de reconhecer que LCARS
Estou ansioso para testar isso.
Pelo que sei, ainda há uma grande falta de assistentes de voz abertos, estáveis, flexíveis e centrados em privacidade, então espero que este projeto ganhe força.
Há cerca de um ano, minha família queria muito colocar uma Alexa em casa, mas eu não queria ter um dispositivo de vigilância do Bezos dentro de casa, então os convenci a tentar criar o nosso. Escolhi o Mycroft em um Pi 4, mas não funcionou bem; a detecção da palavra de ativação era inconsistente, faltavam integrações e, naquele momento, o projeto parecia basicamente abandonado. Tentei contribuir com o projeto e com as integrações nas quais eu estava travando, mas a vida ficou corrida e nunca consegui voltar a isso; felizmente, minha família também esqueceu a Alexa
Não lembro se era nano ou pico; de qualquer forma, era uma placa mais ou menos do tamanho de um SO-DIMM. Não havia palavra de ativação; ao apertar o botão iluminado em branco, ele mudava de cor duas vezes: uma para confirmar o pressionamento e outra para indicar que estava ouvindo. Quando você terminava de falar, a cor mudava de novo e ele dizia a resposta.
No backend usava alguma coisa do Google, e era realmente frustrante configurar e manter funcionando, mas funcionava. Eu tinha dois desses dispositivos e estava esperando algo que me permitisse auto-hospedar algo parecido
Pretendo trabalhar mais nisso. Há alguns vídeos curtos de demonstração no YouTube que dão uma ideia da qualidade atual: https://www.youtube.com/watch?v=OryGVbh5JZE
Fico curioso se isso pode ser executado em uma máquina Linux comum.
Ou se alguém conhece um projeto parecido que permita isso.
Já pesquisei antes, mas essa área é complexa e as restrições eram sutis
No geral, o Pi-C.A.R.D parece usar Python e C++, então imagino que não haja grandes problemas para rodá-lo em qualquer lugar onde seja possível executar e compilar Python e C++
Há cerca de 3 anos tentei fazer algo assim em uma geração inicial do RPI 4, mas esbarrei nas limitações do hardware e do meu próprio conhecimento.
Ver algo funcionando de verdade agora é muito legal
Seria legal se existisse um raspi hat em que desse para encaixar uma GPU, mas não sei bem se isso seria prático ou possível
As placas de vídeo de hoje são o lixo eletrônico de amanhã, então talvez elas pudessem ganhar uma segunda vida reforçando esse tipo de projeto DIY com raspi
Se você acoplar uma GPU/adaptador/fonte de alimentação para aproveitar núcleos CUDA baratos, há uma boa chance de ficar pior em energia, preço e tamanho do que soluções melhores com SoC ou x86 NUC
Não sei que tipo de mágica existe no PCIe, mas pelo menos uma placa comercial, a Atomic Pi, tinha uma interface PCIe “exposta”
De todo modo, a GPU ficava em uma pequena PCB, e essa PCB era conectada por um cabo USB3 a uma PCB menor no slot PCIe da placa-mãe. A questão é que, seja lá o que for PCIe, dá para fazê-lo chegar à GPU por um cabo USB3 e fazê-la trabalhar
Vejo um alto-falante na lista de hardware, e fiquei curioso se ele também responde falando
No momento ele usa https://espeak.sourceforge.net/, então não é exatamente muito agradável de ouvir
Além disso, como as respostas do modelo de linguagem grande são transmitidas em streaming, não demora muito para receber uma resposta. Como o processamento é feito em chunks, às vezes ele chega a pronunciar brevemente só parte de uma palavra. Claro que o tempo de espera também varia conforme o modelo usado e o tamanho do contexto
Por que Picard sempre precisa especificar até a preferência de temperatura do chá Earl Grey?
Uma IA tão inteligente assim já não deveria ter aprendido o gosto dele?
Na série, muitos personagens dão instruções mais flexíveis ao replicador. “Tea, Earl Grey, Hot” parece ser um hábito do Picard, talvez vindo de algum aparelho de comida e bebida mais primitivo do que o replicador da Enterprise-D
Será que processos judiciais ainda existem num mundo pós-escassez? Provavelmente
A maioria das pessoas da Starfleet parece não saber usar bem os replicadores. Mesmo tendo um aparelho tão inteligente, usam como um eletrodoméstico comum cujo manual nunca leram, deixam passar 90% dos recursos e depois reclamam que a comida replicada tem gosto ruim
https://i.redd.it/hluqexh3oqc91.jpg
Fiquei curioso sobre como a palavra de ativação funciona
Ele fica ouvindo o tempo todo e ignora se não houver uma palavra ou frase de ativação nos últimos segundos?
Mais precisamente, ele armazena vários chunks de áudio e descarta os mais antigos; ou seja, é uma janela deslizante (rolling window)