FMI: Zona Euro ainda sem ganhar gás, Portugal só tem pequena aceleração

[MarcoAntonio]

Eu considero as LLM atuais mais que suficientemente inteligentes para ajudar um ser humano a fazer ou a melhorar uma prompt, aliás o termo Metaprompting descreve (conceptualmente) um conjunto de técnicas existentes para pôr a LLM a colaborar ativamente no processo de prompting.

Concordo mais com o que referes relativamente à questão da não frustrar os utilizadores que procuram respostas objetivas, ou pecar por excesso de paternalismo.

Efetivamente é um problema de UX (User Experience) que não é possível de resolver e remete-nos para a velha máxima "não é possível agradar a gregos e troianos".

No entanto há também a questão dos custos de inferência. Se as LLM questionassem constantemente TODAS as prompts de TODOS os utilizadores, iriam, no mínimo, duplicar os tokens usados em cada conversação, duplicando também os custos de inferência.

Mas isso só vem reforçar a minha ideia. Se os Chatbots de IA não assistem o utilizador nas suas prompts (dado que isso é uma opção de desenho arquitetural) então aprender "engenharia de prompts" é uma "habilidade" essencial quando se pretende iteragir com qualquer LLM.

No meu caso, que uso o Chat GPT desde o seu lançamento, confesso que só este ano me dediquei extensivamente a estudar de "engenharia de prompts" e foi um "banho de humildade" pois eu achava-me expert no tema (só porque tinha uma ideia, relativamente aprofundada, de como as LLM funcionavam internamente).

Com o conhecimento adquirido tripliquei a eficiência das minhas prompts e deixei de obter respostas insatisfatórias das LLM (a menos nas vezes que sou preguiçoso com as minhas prompts, mas nesse caso tenho bom remédio, é deixar de ser preguiçoso ).

Certo, mas as duas coisas podem ser verdade simultaneamente. O que estás a descrever, é o modelo (essencialmente) explicar como é que ele entende melhor (o que não significa que, se ele fosse mais capaz, não precisasse da ajuda adicional de ter o utilizador a escrever prompts desenhadas para aumentar a eficiência do modelo). Mas estamos a falar, fundamentalmente, de uma limitação dos modelos e não de uma limitação dos utilizadores (pensando aqui no uso genérico). A verdade é que nós, humanos, precisamos de menos prompt engineering para nos entendermos uns aos outros. Há lugar a desentendimento, claro. Mas é menos pronunciado dado que nõs conseguimos incorporar mais informação no acto de entender a mensagem. Os modelos eventualmente chegarão lá ou aproximar-se-ão mais dessa fasquia.

O prompt engineering actual fará sentido enquanto o paradigma dos modelos se mantiver, tornar-se-á obsoleto (ou largamente obsoleto ou desnecessário) se o paradigma dos modelos mudar. Seja como for, penso que faz sentido incorporar nos programas pelo menos nos domínios especialmente técnicos.

[Rolling_Trader]

Eu considero as LLM atuais mais que suficientemente inteligentes para ajudar um ser humano a fazer ou a melhorar uma prompt, aliás o termo Metaprompting descreve (conceptualmente) um conjunto de técnicas existentes para pôr a LLM a colaborar ativamente no processo de prompting.

Concordo mais com o que referes relativamente à questão da não frustrar os utilizadores que procuram respostas objetivas, ou pecar por excesso de paternalismo.

Efetivamente é um problema de UX (User Experience) que não é possível de resolver e remete-nos para a velha máxima "não é possível agradar a gregos e troianos".

No entanto há também a questão dos custos de inferência. Se as LLM questionassem constantemente TODAS as prompts de TODOS os utilizadores, iriam, no mínimo, duplicar os tokens usados em cada conversação, duplicando também os custos de inferência.

Mas isso só vem reforçar a minha ideia. Se os Chatbots de IA não assistem o utilizador nas suas prompts (dado que isso é uma opção de desenho arquitetural) então aprender "engenharia de prompts" é uma "habilidade" essencial quando se pretende iteragir com qualquer LLM.

No meu caso, que uso o Chat GPT desde o seu lançamento, confesso que só este ano me dediquei extensivamente a estudar de "engenharia de prompts" e foi um "banho de humildade" pois eu achava-me expert no tema (só porque tinha uma ideia, relativamente aprofundada, de como as LLM funcionavam internamente).

Com o conhecimento adquirido tripliquei a eficiência das minhas prompts e deixei de obter respostas insatisfatórias das LLM (a menos nas vezes que sou preguiçoso com as minhas prompts, mas nesse caso tenho bom remédio, é deixar de ser preguiçoso ).

[MarcoAntonio]

Bom, se o sistema fosse realmente inteligente, não seria preciso (tanto) prompt engineering. A necessidade de prompt engineering aponta para as limitações destes modelos e serve de panaceia para um problema mais fundamental. O mesmo de que já temos estado a falar aqui no tópico...

A diferença está em que nós (humanos) detectamos melhor a nuance, preenchemos lacunas com pistas adicionais ou conhecimento prévio via informação contextual, o que no nosso caso é bem mais robusto, abrangendo uma série de vectores. Por exemplo, aprendemos rapidamente como o nosso interlocutor fala/escreve, inferimos da linguagem corporal quando disponível, etc. Grande parte desta capacidade diz respeito a aquilo que conhecemos por "Teoria da Mente" (Theory of Mind). Além disso, tendemos a pedir clarificações de forma directa ou indirecta quando sentimos necessidade - por vezes de forma fluída, não necessariamente impertinente - o que será mais difícil de calibrar num LLM, que tenderá a assumir que entendeu o que o utilizador pretende (em lugar de questionar o interlocutor o tempo todo). Por exemplo, no lançamento do GPT-5 alguns utilizadores queixaram-se de múltiplos ciclos de prompts e clarificações até o modelo produzir o resultado final. Os exemplos partilhados mostravam situações que, na comunicação humano-humano, não justificaria tanta necessidade de clarificação. Se o modelo prioritizar demasiado a precisão, pode tornar-se rapidamente inconveniente, se "afrouxar" corre o risco de fornecer respostas desalinhadas com a intenção do utilizador. 

Embora isto ocorra também na comunicação humano-humano, se um ouvinte precisa/pede esclarecimento o tempo todo ou interpreta sistematicamente outra coisa que não o que interlocutor quer, ainda que a linguagem seja imprecisa, então provavelmente há um problema também do lado do ouvinte/receptor. Ou seja, apesar da ambiguidade e da "baixa largura de banda" da linguagem natural - que na verdade, na prática, permite comunicação mais eficiente - em condições típicas conseguimos ultrapassar bem esses aparentes obstáculos, dado que somos mais do que meramente um modelo linguístico.

Naturalmente que prompts bem formulados mitigam o problema. Mas este não estará tanto nos utilizadores não saberem pedir o que querem, mas no de os sistemas não conseguirem deduzir (com o mesmo grau de eficiência, fluidez e adaptação que nós interlocutores humanos) o que o utilizador quer...

[Rolling_Trader]

(...)
No fundo, a letter de cima serve para sublinhar a pertinência de técnicas adequadas (fine-tuning e técnicas avançadas de reasoning) para que os modelos sejam minimamente robustos para aplicações sérias em medicina. Também serve, na minha opinião, como mensagem de cautela sobre a utilização de LLMs vanilla para aconselhamento médico, mesmo que os modelos mais recentes não estejam cobertos. Um dos pontos da letter é como a resposta do modelo pode variar significativamente mediante alterações na prompt.

Tirando por momentos o enfoque nas questões médicas, a tua última frase revela o maior problema com que os utilizadores se deparam ao usar uma LLM genérica (e o problema não está na LLM).

A maior parte das pessoas formula más prompts, sem contexto, sem direcionar a futura resposta de encontro ao objetivo que pretende, depois queixa-se de más respostas e "põe as culpas" no modelo.

Fazendo uma analogia com o meu contexto profissional, de desenvolvimento de software à medida, posso dizer que, nos meus 25 anos de carreira, sempre me deparei com mesmo problema: "Os clientes nunca sabem bem o que querem".
Mas o desenvolvimento de software aborda bem esse problema e existem inúmeras técnicas e metodologias provadas para levantamento de requisitos, que ajudam na clarificação das reais necessidades e desejos do cliente, técnicas essas que são essenciais para mitigar o risco de frustração do cliente com o produto final.

Infelizmente, as LLM genéricas não lêem o pensamento dos utilizadores nem estão treinadas para fazer "levantamento de requisitos" para perceberem exatamente o que o utilizador pretende.

A incontornável verdade é que é da responsabilidade do utilizador da LLM fazer boas prompts e se não o fizer terá más respostas (por más entenda-se vagas, genéricas e desadequadas da pretensão efetiva).

Arriscaria dizer que 90% dos utilizadores de LLMs genéricas (a nível mundial) nunca sequer ouviu falar de prompt engineering e esse é o principal requisito para se conseguir as melhores respostas por parte das LLM, seja qual for o domínio específico do conhecimento humano constante na prompt.

Até acho que a "engenharia de prompts" devia ser incluído nos curriculos do ensino secundário

[MarcoAntonio]

Uma nota: trata-se de uma research letter e não de um research paper. Na comunicação científica não são a mesma coisa: uma letter é uma comunicação breve (que, por vezes, dá lugar a um paper completo mais tarde). Uma situação frequente, por exemplo, é a letter servir para partilhar um resultado preliminar mas considerado relevante per se. Em publicações peer-reviewed, o processo não é tão intensivo quanto para um research paper (o mesmo é dizer que a fasquia de exigência nem sempre é a mesma; muito embora isto varie também com a publicação, um paper tende a ter mais peso académico).

Sobre as observações, sim, concordo (eles próprios citam limitações). Focam-se em LLMs genéricos (não cobre os modelos mais recentes tão pouco) e não inclui RAG ou fine-tuning. Partilho a lista dos modelos incluidos: "DeepSeek-R1 (model 1), o3-mini (reasoning models) (model 2), Claude-3.5 Sonnet (model 3), Gemini-2.0-Flash (model 4), GPT-4o (model 5), and Llama-3.3-70B (model 6)".

Já agora, partilho esta revisão sistemática disponível no arxiv que cobre uma série de questões, incluindo as diversas técnicas de reasoning que têm sido exploradas nesta área.

No fundo, a letter de cima serve para sublinhar a pertinência de técnicas adequadas (fine-tuning e técnicas avançadas de reasoning) para que os modelos sejam minimamente robustos para aplicações sérias em medicina. Também serve, na minha opinião, como mensagem de cautela sobre a utilização de LLMs vanilla para aconselhamento médico, mesmo que os modelos mais recentes não estejam cobertos. Um dos pontos da letter é como a resposta do modelo pode variar significativamente mediante alterações na prompt.

[Rolling_Trader]

Não inclui os modelos mais recentes como o GPT-5 ou Gemini 2.5 pro, mas aqui fica:

(...)

Our findings reveal a robustness gap for LLMs in medical reasoning, demonstrating that evaluating these systems requires looking beyond standard accuracy metrics to assess their true reasoning capabilities.6 When forced to reason beyond familiar answer patterns, all models demonstrate declines in accuracy, challenging claims of artificial intelligence’s readiness for autonomous clinical deployment. A system dropping from 80% to 42% accuracy when confronted with a pattern disruption would be unreliable in clinical settings, where novel presentations are common. The results suggest that these systems are more brittle than their benchmark scores suggest.

While our study has limitations, including a small sample size and evaluation limited to 0-shot settings without exploring retrieval-augmented generation or fine-tuning techniques, our findings suggest 3 priorities for medical artificial intelligence: (1) development of benchmarks that distinguish clinical reasoning from pattern matching, (2) greater transparency about current reasoning limitations in clinical contexts, and (3) research into models that prioritize reasoning over pattern recognition. Until these systems maintain performance with novel scenarios, clinical applications should be limited to non autonomous supportive roles with human oversight.

Bem, na minha modesta opinião, esse "research paper" parece-me falível mesmo nas próprias conclusões que tira.

Parece um pouco discussão com o BearManBull. Não se pode querer que um "foundation model" generalista esteja extremamente otimizado para uma área ou sub-área especifica como a do diagnóstico clínico, sem ter um fine-tuning extensivo.

Um dos principais "problemas" que encontro nesse paper é o facto de eles não terem comparado a performance dos modelos com a dos médicos reais quando deparados com o mesmo questionário (fica assim a dúvida razoável se os médicos humanos são melhores ou piores que os modelos testados, face ao benchmark subjacente).

Mas ainda sobre este tópico e transpondo o tema para os novos modelos GPT-5, encontrei este paper, com o título "Capabilities of GPT-5 on Multimodal Medical Reasoning" e cujo resumo executivo transcrevo abaixo, assinalando, a sublinhado o que considero relevante e a bold o que considero notável:

In "Capabilities of GPT-5 on Multimodal Medical Reasoning"

Abstract

Recent advances in large language models (LLMs) have enabled general-purpose systems to perform increasingly complex domain-specific reasoning without extensive fine-tuning. In the medical domain, decision-making often requires integrating heterogeneous information sources, including patient narratives, structured data, and medical images. This study positions GPT-5 as a generalist multimodal reasoner for medical decision support and systematically evaluates its zeroshot chain-of-thought reasoning performance on both text-based question answering and visual question answering tasks under a unified protocol.

We benchmark GPT-5, GPT-5-mini, GPT-5-nano, and GPT-4o-2024-11-20 against standardized splits of MedQA, MedXpertQA (text and multimodal), MMLU medical subsets, USMLE self-assessment exams, and VQA-RAD. Results show that GPT-5 consistently outperforms all baselines, achieving state-of-the-art accuracy across all QA benchmarks and delivering substantial gains in multimodal reasoning.

On MedXpertQA MM, GPT-5 improves reasoning and understanding scores by +29.26% and +26.18% over GPT-4o, respectively, and surpasses pre-licensed human experts by +24.23% in reasoning and +29.40% in understanding. In contrast, GPT-4o remains below human expert performance in most dimensions.

A representative case study demonstrates GPT-5’s ability to integrate visual and textual cues into a coherent diagnostic reasoning chain, recommending appropriate high-stakes interventions.
Our results show that, on these controlled multimodal reasoning benchmarks, GPT-5 moves from human-comparable to above human-expert performance. This improvement may substantially inform the design of future clinical decision-support systems. We make the code public at the GPT-5-Evaluation

Os nossos hospitais privados de referência (Luz, Cuf, Lusíadas, Trofa, Joaquim Chaves) já deviam estar a caminhar para o diagnóstico assistido por IA, a passos largos, mas será que já moveram sequer uma palha nesse sentido?

Enquanto arquiteto de software e investidor de bolsa sei que o investimento num centro de excelência de IA, na área da Saúde, traria um ROI muito elevado.

Porém (e globalmente falando) o investimento na área de IA, por parte das empresas, ainda é feito muito a medo e com desconfiança (nada que a humanidade não tenha também passado durante a revolução industrial).

[MarcoAntonio]

Não inclui os modelos mais recentes como o GPT-5 ou Gemini 2.5 pro, mas aqui fica:

Fidelity of Medical Reasoning in Large Language Models (JAMA)

(Research Letter)

Discussion

Our findings reveal a robustness gap for LLMs in medical reasoning, demonstrating that evaluating these systems requires looking beyond standard accuracy metrics to assess their true reasoning capabilities.6 When forced to reason beyond familiar answer patterns, all models demonstrate declines in accuracy, challenging claims of artificial intelligence’s readiness for autonomous clinical deployment. A system dropping from 80% to 42% accuracy when confronted with a pattern disruption would be unreliable in clinical settings, where novel presentations are common. The results suggest that these systems are more brittle than their benchmark scores suggest.

While our study has limitations, including a small sample size and evaluation limited to 0-shot settings without exploring retrieval-augmented generation or fine-tuning techniques, our findings suggest 3 priorities for medical artificial intelligence: (1) development of benchmarks that distinguish clinical reasoning from pattern matching, (2) greater transparency about current reasoning limitations in clinical contexts, and (3) research into models that prioritize reasoning over pattern recognition. Until these systems maintain performance with novel scenarios, clinical applications should be limited to non autonomous supportive roles with human oversight.

[Rolling_Trader]

A Microsoft disponibilizou recentemente, para avaliação pública, dois modelos LLM, um para geração de voz (MAI-Voice-1) e o segundo um tradicional "foundation model" (MAI-1-preview), com o intuito de rivalizar com os grandes fornecedores de LLM atuais como o ChatGPT da OpenAI, Gemini da Google ou Grok da xAI.

O modelo MAI-Voice-1 está disponível para teste gratuito no copilot labs

O modelo MAI-1-preview está disponível para teste gratuito na LMArena (neste caso é necessário escolher o modelo "mai-1-preview")

A comunicação oficial pode ser encontrada neste link da Microsoft

Será finalmente a Microsoft vai conseguir libertar-se da dependência dos modelos da OpenAI que alimentam o Copilot e no processo aumentar os seus resultados em bolsa?

Para já, no leaderboard da LMArena, a coisa não está muito famosa em termos de popularidade e o modelo da Microsoft encontra-se até atrás do Grok 3, o modelo anterior da xAi, bem como atrás da versão anterior do ChatGPT e de algumas chinesas open source, não se destacando em nada segundo a opinião dos avaliadores (não é o começo mais auspicioso diria eu).

[Rolling_Trader]

Eu so queria ter uma resposta de onde é que o MCP é amplamente usado na actualdiade.

Mas lá está como o GPT nao pode responder a estas perguntas...

Sabe, eu sou da geração X, tirei a licenciatura de 1995 a 2000 e tive uma carreira de software developer de 2000 a 2021 antes do Chat GPT e... sobrevivi! A pensar pela minha cabeça e a usar coisas chamadas "livros" e "motores de busca", arcaico sim mas, apesar de tudo, ainda existem hoje. Dão trabalho de usar mas aprende-se mais do que acreditar piamente num conjunto de tokens "cuspidos" probabilísticamente por uma LLM, não preciso disso para pensar, formular teorias, ou expôr as minhas ideias.

Mas ainda quer respostas? Não leu nada do que eu citei anteriormente?
Não seja por isso, eu cito mais fontes. E já que você só conhece o Chat GPT, deixo-lhe aqui mais uns links (que provavelmente você também não vai ler):

O Model Context Protocol é usado (tal como referi) da melhor maneira possível (à data) pelo ecosistema da Open AI, nomeadamente:


No developer toolkit Open AI Agents SDK

https://openai.github.io/openai-agents-python/mcp/
https://openai.github.io/openai-agents- ... cp/server/
https://openai.github.io/openai-agents- ... /mcp/util/

Na Responses API, a API nuclear da Open AI para criar aplicações agentificadas

Na funcionalidade de "Connectors" do Chat GPT

O MCP é recente (novembro de 2024) mas a versão 5 do ChatGPT é posterior ao protocolo. Pelos links acima citados é altamente improvável que o GPT-5 não use MCP na sua agentificação interna, dado que o protocolo já é a base da Responses API e do Agents SDK. Claro está que isso não é demonstrável pelo simples facto da versão 5 do modelo ser fechada e os detalhes da sua implementação não serem do domínio público.

Gostava também que você desse uma explicação sucinta de porquê usar o MCP para atingir o objetivo que referiu. Porquê só um protocolo? E porquê o MCP em particular?

Não preciso que você escreva código, mas ou detalha tecnicamente a sua ideia e a mais valia do MCP nesse contexto, ou dá descanso ao tópico, pois o que havia para discutir sobre MCP creio que já foi aqui extensivamente esmiuçado.

[BearManBull]

Eu so queria ter uma resposta de onde é que o MCP é amplamente usado na actualdiade.

Mas lá está como o GPT nao pode responder a estas perguntas...

[MarcoAntonio]

A minha sugestão é que evitem o campo pessoal, é meio caminho andado para o tópico prosseguir sem sobressaltos de maior.

[Rolling_Trader]

O que ficou claro aqui é que nao tens patavina ideia de como se usa o MCP nem consegues dar exemplos de uso porque o GPT nao esta treinado nisso e nao sabes extrapolar essa informaçao a pensar pela tua pessoa.

Meu caro a minha lincenciatura é na área de informática de investigação, tenho mais de 25 anos de experiência em desenvolvimento de software e atualmente sou arquiteto de sistemas enterprise.

Mas, mesmo com esta experiência tenho a humildade de me remeter à minha insignificância perante os programadores e arquitetos IA de TOPO da OpenAI, Anthropic e Google.

Esta sua última resposta só vem a confirmar que você não sabe o que é o MCP, muito menos sabe sequer o que é um protocolo, senão não diria que, e cito, "o GPT não está treinado nisso".

Pior, a sua resposta prova que você nem sequer sabe usar a IA para fazer fact checking do que diz.

Experimente colocar a seguinte prompt no chat GPT

Does Chat GPT use Anthropic's Model Context Protocol? If so, describe exactly how and why

Vai ver que o próprio Chat GPT lhe podia servir para fazer fact checking antes de vir para aqui dizer asneiras

MarcoAntonio, sugiro que intervenhas aqui (porque já me conheces e sabes para onde isto se está a encaminhar).

Convém que o BearManBull dê alguma prova factual do que está a afirmar em vez de continuar nesta postura passivo-agressiva.

[BearManBull]

O que ficou claro aqui é que nao tens patavina ideia de como se usa o MCP nem consegues dar exemplos de uso porque o GPT nao esta treinado nisso e nao sabes extrapolar essa informaçao a pensar pela tua pessoa.

[Rolling_Trader]

BearManBull,

Para mim ficou claro que você não sabe o que é o protocolo MCP nem para que serve efetivamente.

Também ficou claro para mim que você se acha capaz de fazer algo que os developers e arquitetos de elite da OpenAI, Google e Anthropic não conseguiram ainda fazer, recorrendo apenas a um protocolo de integração..

É como dizer que vai descobrir a cura para o cancro com um laboratório (pois certo que vai precisar dum, mas não é o laboratório, por si só, que lhe vai resolver o problema).

[BearManBull]

Mais estranho ainda é pensar que o MCP serve para organizar informação dentro da janela de contexto.

Eu gostava era de saber de onde è que isso foi dito...

Você escreveu literalmente isso no seu post de 30/8/2025 0:41

Na generalidade os LLMs conseguem fazer em termos micro o mesmo trabalho que fazem essas pessoas falta é a capacidade de acompanhamento e enquadramento para colaborar num processo empresarial e isso é por contexto diario que vao guardando e eliminando o que nao é necessário. Falta ali ou uma context window de terabytes ou um sistema orquestrador que guarda e recupera a informaçao por exemplo por MCP.

Eu disse que se podia usar o MCP para implementar um arquitectura que emula um janela de contexto que seja suficientemente dinamica, fiavel e grande para o uso empresarial.

Nao disse que o MCP é um protocolo de context windows.

[BearManBull]

Acho estranho o BearManBull achar que o protocolo MCP não estará já a ser usado pelos fornecedores de IA mainstream (da melhor forma possível).

Ah sim, exemplifica lá isso.

Anthropic

Sendo esta empresa a criadora do protocolo é óbvio que já usa MCP.

Introducing the Model Context Protocol

Google

Google today announced that the SDK for its Gemini models will natively support the Model Context Protocol from Anthropic.

OpenAi

How OpenAI Agent Mode Uses the Model Context Protocol (MCP)

Isso nao demonstra absolutamente nada relativo ao uso do MCP.

Uma coisa é disponibilizar ferramentas, outra coisa é adoptalas em ambiente organizacional.

[Rolling_Trader]

Iniciativa de louvar, mas será que "colará", no futuro, com os restantes fornecedores de soluções de IA?

In Forbes

Perplexity’s Comet Plus – Legal Peace Offering Or New Dawn For Publishers In The AI Era?

San Francisco’s Perplexity AI recently announced a groundbreaking revenue-share model. The centerpiece of this initiative is Comet Plus, a $5-a-month subscription tier designed to deliver smarter browsing as well as channel income back to publishers whose work powers its AI.

(...)

Notably, Perplexity’s head of publisher partnerships, Jessica Chan, frames Comet Plus as a corrective to those archaic incentives. “Perplexity only succeeds if journalism succeeds. We’re really committed to building and funding more sustainable, thriving news ecosystems for the AI age,” she explained in a Digiday interview. “I think anything that supports publishers, fair compensation, transparency — we’re all open to supporting]. We’d be open to [participating].”

Será viremos a ter um modelo estilo "spotify" para remunerar (ainda que pouco que seja) a propriedade intelectual dos jornalistas e restantes publicadores, que muitas vezes alimentam os textos de IA que lemos?

[Rolling_Trader]

China Has a Different Vision for AI. It Might Be Smarter.

(...)

The U.S. is spending billions of dollars and burning gigawatts of energy in a rush to beat China to the next evolutionary leap in artificial intelligence—one so great, some boosters say, that it will rival the atomic bomb in its power to change the global order.
China is running a different race.

(...)

more actively embracing open-source models that are free for users to download and modify, making it cheaper and easier for Chinese companies to build businesses around the technology. That approach is helping Chinese AI spread globally, a trend that has shaken Silicon Valley into following suit.

E no entretanto Portugal... queixa-se do "tamanho da janela de contexto" e resigna-se a dizer que a IA é uma porcaria porque não lhe faz o trabalho todo sozinho.

Agora falando a sério, é notável como os interesses económicos que revolvem em torno das superempresas de IA americanas (Google, OpenAI, Anthropic e xAI), cujo cerne da rentabilidade reside nos modelos LLM fechados e proprietários, a China investe e promove a investigação de modelos abertos (Deepseek, Alibaba Qwen, Moonshot Kimi K2, entre outros) que são fundamentais para poderem servirem de modelos base para retreino e/ou fine-tuning noutras áreas de negócio (que não a de software).

Estando a IA a posicionar-se como a maior revolução socio-económica da história da humanidade e com o potencial de ter um impacto exponencial, será que esta proatividade da China não lhe permitirá posicionar como a maior economia do mundo num futuro próximo?

[MarcoAntonio]

China Has a Different Vision for AI. It Might Be Smarter.

With growing fears of an AI bubble, Beijing is charting a pragmatic alternative to Silicon Valley’s pursuit of artificial superintelligence


The U.S. is spending billions of dollars and burning gigawatts of energy in a rush to beat China to the next evolutionary leap in artificial intelligence—one so great, some boosters say, that it will rival the atomic bomb in its power to change the global order.
China is running a different race.

Since the release of OpenAI’s ChatGPT nearly three years ago, Silicon Valley has spent mountains of money in pursuit of AI’s holy grail: artificial general intelligence that matches or beats human thinking. Enthusiasts say it will give the U.S. insurmountable military advantages, help cure cancer and solve climate change, and eliminate the need for people to perform routine work such as accounting and customer service.

In China, by contrast, leader Xi Jinping has recently had little to say about AGI. Instead, he is pushing the country’s tech industry to be “strongly oriented toward applications”—building practical, low-cost tools that boost China’s efficiency and can be marketed easily.

(...)


Tsinghua University, China’s equivalent of the Massachusetts Institute of Technology, is rolling out an AI-powered hospital, where human doctors will be assisted by virtual colleagues armed with the latest data on diseases. Intelligent robots are being deployed to run automotive “dark factories” and inspect textiles for flaws while still on the loom.

“They see highly impactful AI applications not as something to theorize about in the future but as something to take advantage of here and now,” said Julian Gewirtz, a former National Security Council official who specialized in tech competition with China during the Biden administration.

U.S. tech companies are developing plenty of practical applications using current AI, of course. Google has wired its latest Pixel smartphones to do real-time translation, while U.S. consulting companies are using AI agents to build PowerPoint decks and sum up interviews for clients. Others are using it to improve drug discovery and food delivery.

But unlike the U.S., which largely leaves the industry to its own devices, Beijing is putting the full muscle of the state behind its vision. In January, the central government unveiled an $8.4 billion AI investment fund focused on supporting startups. Local governments and state banks have since rolled out their own funding programs, while cities have published AI development plans as part of a campaign dubbed “AI+.”

(...)

China is also more actively embracing open-source models that are free for users to download and modify, making it cheaper and easier for Chinese companies to build businesses around the technology. That approach is helping Chinese AI spread globally, a trend that has shaken Silicon Valley into following suit.

(...)

WSJ

[Rolling_Trader]

Acho estranho o BearManBull achar que o protocolo MCP não estará já a ser usado pelos fornecedores de IA mainstream (da melhor forma possível).

Ah sim, exemplifica lá isso.

Anthropic

Sendo esta empresa a criadora do protocolo é óbvio que já usa MCP.

Introducing the Model Context Protocol

Google

Google today announced that the SDK for its Gemini models will natively support the Model Context Protocol from Anthropic.

OpenAi

How OpenAI Agent Mode Uses the Model Context Protocol (MCP)

Mais estranho ainda é pensar que o MCP serve para organizar informação dentro da janela de contexto.

Eu gostava era de saber de onde è que isso foi dito...

Você escreveu literalmente isso no seu post de 30/8/2025 0:41

Na generalidade os LLMs conseguem fazer em termos micro o mesmo trabalho que fazem essas pessoas falta é a capacidade de acompanhamento e enquadramento para colaborar num processo empresarial e isso é por contexto diario que vao guardando e eliminando o que nao é necessário. Falta ali ou uma context window de terabytes ou um sistema orquestrador que guarda e recupera a informaçao por exemplo por MCP.

[MarcoAntonio]

Mas é isso que estava a identificar desde inicio que é limitador para as empresas.

No estágio actual, para projectos profissionais como o tal "assistente jurídico", o que fará mais sentido é usar a API e um wrapper orquestrador, na linha do que mencionei atrás, do que estar a depender das limitações do acesso vanilla da app/web e respectivo frontend. Aceder ao GPT-5 vanilla, ou outro modelo/serviço do género, não será provavelmente a melhor solução. Não foram desenhados/optimizados para este ou outro tipo de aplicação tão específico. Os sistemas também não chegaram ao ponto de evolução que aqui procuras/exiges (talvez um dia, quem sabe, com mais evoluções em cima ou outro paradigma; ie, a matéria que procurei discutir nos posts anteriores).

Na API, a OpenAI já oferece (para além de controlo sobre o modelo a utilizar, nível de esforço e o modo de reasoning) um contexto total um pouco maior:

https://openai.com/index/introducing-gpt-5-for-developers/

Excerto:

(...)

In the API, all GPT‑5 models can accept a maximum of 272,000 input tokens and emit a maximum of 128,000 reasoning & output tokens, for a total context length of 400,000 tokens.

(...)

Além disso, também segundo a OpenAI, a Responses API permite ainda o acesso/controlo de várias ferramentas nativas:

Responses benefits

The Responses API contains several benefits over Chat Completions:

* Better performance: Using reasoning models, like GPT-5, with Responses will result in better model intelligence when compared to Chat Completions. Our internal evals reveal a 3% improvement in SWE-bench with same prompt and setup.

* Agentic by default: The Responses API is an agentic loop, allowing the model to call multiple tools, like web_search, image_generation, file_search, code_interpreter, remote MCP servers, as well as your own custom functions, within the span of one API request.
Lower costs: Results in lower costs due to improved cache utilization (40% to 80% improvement when compared to Chat Completions in internal tests).

* Stateful context: Use store: true to maintain state from turn to turn, preserving reasoning and tool context from turn-to-turn.

* Flexible inputs: Pass a string with input or a list of messages; use instructions for system-level guidance.

* Encrypted reasoning: Opt-out of statefulness while still benefiting from advanced reasoning.

* Future-proof: Future-proofed for upcoming models.

https://platform.openai.com/docs/guides/migrate-to-responses

O que eu sugeria, construindo sobre ou expandindo a minha sugestão anterior aqui no tópico: usar api com um wrapper orquestrador que inclua coisas como um RAG para os documentos (biblioteca própria do projecto), funções separadas por tarefa (pesquisa/digestão/sumarização/citação), políticas a aplicar (para respeitar as necessidades e limites legais, a tal "constitutional ai") e gestão local do contexto ad hoc por request (isto pode ser automatizado!). Decisões de alto nível como delineação ou actualizações estratégicas também podem ter a sua própria função/gestão. Aqui função não é no sentido de código convencional, pode ser tudo feito por diferentes layers de chamada ao(s) modelo(s).

Claro que tudo isto custa dinheiro. Quer a desenvolver o sistema, quer depois a pagar pedidos por acesso/request. Também há a possibilidade de utilizar modelos opensource (eventualmente até fine-tuned). Mas continuará a haver, para além dos custos de desenvolvimento, os custos de hardware (local ou remoto) e afins...

[BearManBull]

Acho estranho o BearManBull achar que o protocolo MCP não estará já a ser usado pelos fornecedores de IA mainstream (da melhor forma possível).

Ah sim, exemplifica lá isso.

Mais estranho ainda é pensar que o MCP serve para organizar informação dentro da janela de contexto.

Eu gostava era de saber de onde è que isso foi dito...

[BearManBull]

Larga e sem degradação não é a mesma coisa. Há que entender/identificar a causa da degradação (aumentar a janela pode apenas mitigar o problema e não resolvê-lo a um nível fundamental). Isto aponta já para dois potenciais problemas e não um. Também não estou a entender muito bem a questão do reset na sequência do mesmo bullet point pois isto já passa para lá da janela de contexto em si e começa a entrar na questão do conhecimento persistente. Ou seja, um terceiro problema.

Mas é isso que estava a identificar desde inicio que é limitador para as empresas.

Para substituir totalmente o trabalho de um humano é necessário ter um sistema ser capaz de manter o contexto durante periodos longos, com grande capacidade memória, persistencia e sem perda de performance.

Vejo os agentes como algo a quem delegar tarefas, mas nao pode ser cada vez que se quer uma tarefa iniciar um prompt novo. O agente tem de "conhecer" a organizaçao seja por via de context windows extremamente longas ou outro tipo de mecanismo que emule uma context window longa.

Já agora digo delegar porque teria de ser sempre trabalho supervisionado. No fundo como acontece quando se delega trabalho numa organizaçao.

[Rolling_Trader]

Bem, "vou ser breve", porque já estamos a ir offtopic ao discutir semântica em vez de IA.

O cerne não era discutir o que significa emular e o BearManBull está deixar esta conversa num círculo vicioso que não trás nada de novo para para a discussão de IA.

Já se percebeu que o BearManBull confunde tamanho da janela de contexto com a eficiência da obtenção de informação da mesma (nada a fazer quanto a isso).

Vou rematar só com o seguinte:

Uma LLM não é o mesmo que um chatbot (ChatGPT, Claude, Gemini, Grok são chatbots baseados em LLMs como GPT-5, Claude 4.1, Gemini 2.5)

A primeira versão do ChatGPT consistia numa interface simples, não multimodal, que só recebia texto, enviava-o para o LLM subjacente, e mostrava o texto produzido pelo LLM.

As LLM subjacentes (dos fornecedores mainstream) foram sendo melhoradas:

Passaram a ser multimodais, ou seja, treinadas não só com tokens de texto, mas com tokens multimodais (áudio, imagens, vídeo, etc)
Foram dotados da capacidade de exercer um processo simulado de raciocínio (empregando técnicas como o Chain of Thought).
Os chatbots atuais (dos fornecedores mainstream) foram evoluindo desde as suas primeiras versões:

Foram dotados da capacidade de receber diferentes tipos de ficheiros, extrair o conteúdo relevante (texto, imagem, áudio) e transformá-lo em tokens para injeção na janela de contexto
foram agentificados o que os dotou da capacidade de usar ferramentas externas para complementar as respostas (por exemplo para ir buscar informação online via search ou webscraping)

Acho estranho o BearManBull achar que o protocolo MCP não estará já a ser usado pelos fornecedores de IA mainstream (da melhor forma possível).

Mais estranho ainda é pensar que o MCP serve para organizar informação dentro da janela de contexto. O MCP é apenas um protocolo para integração entre modelos e ferramentas externas.

Em suma:

Se alguém quer substituir trabalho intelectual na sua empresa (sejam advogados, seja que profissão for), dificilmente o irá alguma vez conseguir ao usar apenas a janela de prompt de um chatbot de IA genérico.

Porém já ajuda se usar as funcionalidades mais avançadas destes chatbots como CustomGPTs (ChatGPT), Gems (Gemini), Projects (Grok e ChatGPT), ou soluções que são autênticas "bestas" na inferência sobre uma vasta quantidade de documentos, como o NotebookLM da Google.

Mas o melhor mesmo seria recorrer a um workflows customizado de IA (para a empresa em causa) ou, melhor, em vez de workflow, agentificar a coisa (com n8n, Genspark, Manus, ou tools do género)

Na corrida da IA já várias empresas oferecem produtos de IA adaptados a necessidades específicas de outros negócios (advocacia ou outros), também esta seria uma alternativa a explorar (mais dispendiosa, mas que daria menos trabalho).

No extremo oposto, estaria a solução de implementar um algoritmo próprio, via low level coding (Python seria a minha linguagem de eleição para o efeito de alavancar as potencialidades de IA e das LLM atuais) (mas isto é a minha veia de software developer a falar )

[MarcoAntonio]

Disse que é um dos grandes problemas. Nao disse que era o unico.

Nao queria dizer defender completamente o caso, mas ter um modelo assessor que me permite dimitir um ou varios advogado que fariam essa tarefa.

A janela de contexto suficientemente larga (sem degradaçao) potencialmente resolvia boa parte dos problemas que impedem uma empresa de demitir pessoal. Nao se pode simplesmente fazer reset é preciso haver memória. Mas como disse também concordo que ter processos de suporte até pode ser mais fácil e exequivel.

Larga e sem degradação não é a mesma coisa. Há que entender/identificar a causa da degradação (aumentar a janela pode apenas mitigar o problema e não resolvê-lo a um nível fundamental). Isto aponta já para dois potenciais problemas e não um. Também não estou a entender muito bem a questão do reset na sequência do mesmo bullet point pois isto já passa para lá da janela de contexto em si e começa a entrar na questão do conhecimento persistente. Ou seja, um terceiro problema. Eu não estou a discordar dos problemas assinalados, estou a apontar que são vários problemas que estão a ser aglomerados no mesmo bullet point mas que, na verdade, são problemas de natureza diferente.

O que, para mim, aponta para causas mais profundas de arquitectura (não apenas de recursos), em linha com o que venho expondo.

Falta ali ou uma context window de terabytes ou um sistema orquestrador que guarda e recupera a informaçao por exemplo por MCP.

Convém também notar que aumentar a janela de contexto tem custos computacionais (de hardware, de energia, de velocidade a gerar a completion e, possivelmente até, de qualidade da propria completion). Aumentar a janela de contexto deverá ser feito judiciosamente. Caso contrário arrisca-se overkill e possivelmente criando novos handicaps. Assumindo uma capacidade intrínseca de inferência constante, se de cada vez que o modelo vai gerar a completion, tem uma janela de contexto colossal para digerir, provavelmente o resultado vai-se degradar. Se assim for, a solução é continuar a escalar os modelos. Precisamente o que tinhas alegado antes que não está a dar sinais de que dê frutos:

Por enquanto, bigger/better tem sido o foco da Google, OpenAI e companhia (o GPT5 talvez tenha já dado um quê de mudança de direcção) mas, mesmo que os principais players se foquem na capacidade bruta dos modelos, há o potencial para o resto do ecossistema para tentar retirar o melhor partido dos modelos existentes (como por exemplo, aplicações especializadas).

Esse foco tem vindo a ser demonstado que nao está a dar frutos.