Daily Archives: May 3, 2023

Software and Knowledge Transformers

Resistance if futile, you will be assimilated’ is a well-known Star trek quote.

We’re not ready for Human assimilation stage yet – we need to wait for a full EDNA rollout for that, so, 2050 – but software and all of our knowledge and (documented) culture, we can do soon. When I say ‘we’, I mean our AI.

Nearly 30 years ago, when I had a dumb boss, I conceived the idea of software transforms, but he didn’t allow me to explore it further. Since then, the necessary technology to fully harness this concept remained unavailable, and the idea remained unexplored. However, recent advancements in the GPTsphere suggest that the time to utilize this concept is now. Implementing software transforms could expedite AI development and make the world more user-friendly.

A transform, like a Fourier transform, is a mathematical process that converts a function or data points into a different representation, improving our understanding and analysis of the original information. In the Fourier transform, a signal or function is broken down into its constituent frequencies, enabling us to examine its behavior in the frequency domain.

I wanted to apply this concept to software in the early 1990s to enhance its resilience against errors and bugs. By dispersing a simple equation or algorithmic step across a wide space, the impact of a minor error would be diffused, reducing the likelihood of catastrophic outcomes like crashes. Shortly after, I realized that software transforms could also be used to convert digital programs into neural network algorithms, quantum computing algorithms, or various other computational mechanisms. Numerous software transforms could be developed for different purposes, just as mathematicians have a range of transforms for diverse applications.

In today’s IT landscape, large language models (LLMs) such as ChatGPT4 or Bard possess rapidly expanding software development skills across multiple languages. LLMs are precisely the tools needed to learn how to convert existing software into alternative domains, much like language translation. Equally importantly, on the fly, we gain the concept of “concept coding,” allowing ideas and concepts to be encapsulated and coded as small, cross-language, cross-platform, transferable entities. Software is essentially a well-documented idea.

Ideas, concepts, algorithms, instruction books, guides, procedures and programs can all be transformed into the same space, since they’re all basically built using basically the same DNA, and the LLM tools we now have are pretty much the sort of tools we need to do that task. Maybe not optimal yet, but a good start, and they’re evolving fast anyway. LLMs could experiment with different ways of encoding things, develop a range of concept coding schemes and appropriate transforms. After a few iterations, in much the same way as we iterated our way to GPT4 and beyond, it could become a very powerful tool that adds higher layers of functionality and knowledge onto what the LLMs can do.

What that allows is that all existing ideas and concept and programs can be assimilated into the same knowledge set, but it would be a higher level version of LLMs. It would be another transformer, another GPT, but would be a higher level of knowledge. It wouldn’t just know the language and what word might be expected to come next. It would know the many concepts that exist, all the accumulated knowledge assembled over millennia, throughout all human cultural domains and all of our software, all of the things connected to the network and what they can do, all of the sensor and actuator capabilities, and what it all means and what can be done with it and how. It would integrate all the incoming data from every available sensor, control system, to constantly increase its maps and content, making as complete a dataset of the whole or our documented and connected world as possible, all in one form that can be used in every sphere. It would mine all of the existing software it could be fed, including the LLM datasets, transforming those too into this powerful new know-how domain. It wouldn’t be able to access many parts of our system that are secured behind firewalls or encryption, but even so, the rest would still make up a very significant knowledge set and capability. As a rapidly growing platform it would be the nearest thing we have to the Borg, assimilating all it could get access to.

A software transform transformer could integrate much of the global IT space and the documented human space into a single dataset, bridging the gap between cyberspace and the real world, as well as between humans and machines. It would be a machine brain with vast knowledge, capable of making things happen within its allowed boundaries.

The crucial question is what to connect and how to ensure security. Frequent leaks, hacks, weak security, and poor passwords are vulnerabilities that a skilled and powerful crawler could exploit. Our complacency and incompetence are its greatest allies.

This sort of transformer doesn’t have to do all of this at once of course. It can start off as just a useful set of tools, helping to accelerate development, smooth procedures and bypass tedious admin. There is plenty of economic reason to develop it. Profits would follow. There is also plenty of military incentive, and some big countries will go that route whether we like it or not. I don’t believe we can prevent it, and the idea is obvious enough it would eventually happen as an LLM evolution, so we might as well pursue it deliberately.

As we continue to familiarize ourselves with the capabilities, threats, and opportunities presented by LLMs, we must also prepare for the emergence of the next level of software and knowledge transforms. These software-knowledge transformers (SKTs) will build upon the foundations laid by LLMs, taking us further into a world where vast amounts of knowledge and resources can be easily accessed, analyzed, and utilized.

Developing SKTs will require a collaborative effort from researchers, developers, and industries, as well as careful consideration of the ethical and security implications. The potential benefits of SKTs in various fields, such as healthcare, finance, education, and technology, are immense. However, striking the right balance between harnessing this powerful tool and ensuring security, privacy, and responsible use is essential.

The concept of software transforms has been dormant for decades but recent advancements in AI and large language models suggest that its time has come. As we continue to explore the potential of LLMs, we must also be ready to embrace the next phase of AI development—the software transform transformers (SKTs)—which could revolutionize the way we interact with technology, the world, and each other. But also open the door wide to very advanced and very powerful AI.

SKTs anyone?

I didn’t think ChatGPT4 would know how to design a full SKT but I asked it to outline a common system that would allow ideas, concepts, algorithms and computer code all to be captured, encapsulated as entities and made transferrable across domains, which is one of the most valuable fallouts:

Designing a common system to capture, encapsulate, and transfer ideas, concepts, algorithms, and computer code across domains requires a combination of natural language processing, machine learning techniques, and standardized representation. Here’s a high-level overview of a potential system:

  1. Define a standardized representation: Create a universal and structured format to represent ideas, concepts, algorithms, and computer code. This can be a combination of natural language descriptions, metadata, and a system of unique identifiers for each entity.
  2. Develop a parser: Create a parsing system capable of extracting and converting information from various sources (text, code, diagrams, etc.) into the standardized representation. This may involve natural language processing, code analysis tools, and image recognition techniques.
  3. Encoding and encapsulation: Use machine learning algorithms, such as LLMs, to encode and encapsulate entities in a compact and generalized format. This involves generating concise descriptions, unique identifiers, and necessary metadata to make them easily transferable.
  4. Create a cross-domain and cross-language transformation module: Design a module that utilizes LLMs or other machine learning techniques to transform the encapsulated entities into different formats, languages, or platforms as required. This can involve translating natural language descriptions, converting code between programming languages, or adapting algorithms to different computing environments.
  5. Reusable code generation: Develop a code generation module that can automatically generate reusable code snippets or modules based on the encapsulated entities. This would facilitate the integration of these entities into various software projects.
  6. Storage and retrieval: Implement a centralized storage system or knowledge repository to store the encapsulated entities. This system should support advanced search, filtering, and retrieval of the entities based on various criteria, such as domain, language, or problem type.
  7. Collaboration and sharing: Incorporate collaboration and sharing tools into the system, allowing users to contribute, modify, and reuse entities. This can involve version control systems, access controls, and mechanisms for feedback and improvement.
  8. User interface: Design an intuitive user interface that allows users to interact with the system, input their ideas and concepts, search for existing entities, and visualize the transformation and transfer process.

By implementing such a system, it would be possible to capture, encapsulate, and transfer ideas, concepts, algorithms, and computer code across domains, fostering collaboration, innovation, and efficiency in various fields.

Much of the proposed system is within the scope of current capabilities in natural language processing, machine learning, and software development. However, building such a system would still be a complex and challenging task that requires a deep understanding of various domains, programming languages, and computing environments.

The key components that are within current capabilities include:

  1. Standardized representation: There are existing formats like JSON, XML, or RDF that can be used for structured data representation, as well as domain-specific languages for certain fields.
  2. Parsing and natural language processing: Current NLP techniques and tools, such as tokenization, part-of-speech tagging, and named entity recognition, can be used for parsing and extracting information from various sources.
  3. Machine learning algorithms and LLMs: State-of-the-art machine learning algorithms and large language models can be employed for encoding, encapsulating, and transforming entities.
  4. Code generation and transformation: There are existing code generation tools and techniques for various programming languages, as well as libraries for code analysis and transformation.
  5. Storage and retrieval: Current database technologies, such as relational databases, NoSQL databases, or graph databases, can be employed for storing and retrieving encapsulated entities.
  6. Collaboration and sharing: Existing version control systems, access control mechanisms, and collaboration platforms can be integrated into the system.
  7. User interface: Modern web development frameworks and libraries can be used to create an intuitive user interface for the system.

While these individual components are achievable with current technology, integrating them into a cohesive system that effectively captures, encapsulates, and transfers ideas, concepts, algorithms, and code across domains would require significant effort, expertise, and careful planning. Additionally, achieving a high level of accuracy and usability in each component would be crucial for the overall success and adoption of such a system.

As for SKTs:

To create a Software Knowledge Transformer (SKT), building upon the previously outlined system, several additional components and considerations would be needed to ensure seamless integration, scalability, and effectiveness in transforming software knowledge across domains:

  1. Advanced LLM integration: Enhance the integration of large language models (LLMs) to better understand and manipulate software knowledge, including converting code between programming languages, generating code from natural language descriptions, and optimizing algorithms for different computing environments.
  2. Domain-specific knowledge: Incorporate domain-specific knowledge and expertise to improve the understanding, representation, and transformation of concepts, algorithms, and code in various fields. This may involve integrating specialized ontologies, knowledge bases, or expert systems.
  3. Interoperability: Ensure that the SKT can interact with a wide variety of software systems, platforms, and programming languages. This may involve developing and implementing standardized interfaces, APIs, or communication protocols.
  4. Continuous learning and adaptation: Implement mechanisms that allow the SKT to learn from new data, user feedback, and real-world use cases, continuously refining its knowledge base, transformation capabilities, and code generation techniques.
  5. Evaluation and benchmarking: Establish methods for evaluating the performance and effectiveness of the SKT in transforming software knowledge across domains. This may involve creating benchmarks, test suites, and validation processes to assess the quality and correctness of the transformed entities.
  6. Scalability: Design the SKT to handle large-scale software projects and knowledge bases, ensuring efficient performance and responsiveness. This may involve optimizing data storage, processing algorithms, and resource management.
  7. Security and privacy: Incorporate robust security measures and privacy protections to safeguard sensitive information and intellectual property within the SKT system. This may involve data encryption, access control, and secure communication protocols.
  8. Ethical guidelines and compliance: Establish guidelines and policies to ensure the ethical use and development of the SKT, including considerations of fairness, accountability, and transparency. This may involve adhering to industry standards, regulations, and best practices.

By addressing these additional components and considerations, the SKT can be developed as a comprehensive system capable of effectively transforming software knowledge across domains, ultimately accelerating innovation and enhancing collaboration in various fields.

Most of the components and considerations mentioned for creating a Software Knowledge Transformer (SKT) are within the scope of current technology capabilities. However, there are still some challenges and limitations that need to be addressed to achieve a fully functional and effective SKT system:

  1. Advanced LLM integration: While current LLMs have made significant progress in understanding and generating natural language, their capability to manipulate software code, optimize algorithms, and handle complex domain-specific tasks may require further improvement.
  2. Domain-specific knowledge: Integrating domain-specific knowledge and expertise across various fields can be challenging. It requires creating and maintaining specialized knowledge bases and ontologies, which can be time-consuming and may not always cover all the necessary information.
  3. Interoperability: Ensuring seamless interaction with a wide variety of software systems, platforms, and programming languages may require the development of new standardized interfaces, APIs, or communication protocols, as well as extensive testing and validation.
  4. Continuous learning and adaptation: Implementing mechanisms for continuous learning and adaptation can be complex, especially when dealing with large-scale software projects and knowledge bases. Ensuring the SKT remains up-to-date and accurate in its knowledge and transformation capabilities will require ongoing effort and maintenance.
  5. Evaluation and benchmarking: Developing reliable methods for evaluating the performance and effectiveness of the SKT in transforming software knowledge across domains is a challenging task. It may require the creation of new benchmarks, test suites, and validation processes specifically designed for this purpose.
  6. Scalability: Designing the SKT to handle large-scale software projects and knowledge bases will require careful planning, optimization, and resource management. Achieving efficient performance and responsiveness in such a system may be challenging with current technology limitations.
  7. Security and privacy: Implementing robust security measures and privacy protections can be complex, especially when dealing with sensitive information and intellectual property. Ensuring the SKT meets the highest standards of security and privacy will be an ongoing challenge.

While current technology capabilities can address many aspects of creating an SKT, there remain some challenges and limitations that need to be overcome. Advances in AI, machine learning, and software development, along with continued research and innovation, will likely help address these challenges and pave the way for a fully functional SKT system in the future.

All of this seems to me to be fairly routine development for a large IT company capable of LLM development.

Too late for a pause. We could get minimal AI consciousness by Xmas.

I have written numerous blog posts about the promises and perils of AI, as well as suggesting fundamental principles and mechanisms for achieving machine consciousness. My journey in the field of machine consciousness began in the late 1980s when I invented the self-evolving FPGA. This led me to realize that even if people don’t know how to accomplish something, it is still possible to evolve it, allowing AI to bootstrap itself and eventually become vastly superior to humans. I also understood that our only defense would be to establish a direct link to our brains, enabling some humans to keep up and prevent our extinction. As a result, I proposed the brain refresh mechanism as my earliest contribution.

In 1992, I joined BT’s Cybernetics Group, and after developing a new biomimetic mechanism that utilized synthetic hormone gradients and membranes for network design, my colleague and I created the first evolving software. Soon after, I conceived the distributed AI concept of ANTS and software transforms. I have never worked full time in the AI field, as I have primarily been interested in the more futuristic aspects of strong AI, rather than the hands-on coding process. Although I was a decent programmer throughout the 1980s, I did not enjoy the tedious aspects of writing and debugging code. Consequently, I decided not to write any more code until I could simply explain my intentions to the computer, and it would execute them for me, asking necessary questions to resolve any ambiguities or unforeseen consequences. This blog is essentially just that and will self-fulfill to the degree it should in due course.

For the rest of my career, conscious AI was always on the fringes of my thinking, with just an occasional new insight. During the 1990s, that took me through the Pauli Switch and Heisenberg Resonators for quantum computing, concept coding, sensory echoes, sensory feedback loops and sensory vortices for consciousness emergence and higher level thinking, better software transforms, better mechanisms for direct brain links, smart tattoos and 3D computing gel for power and scope.

In the early 2000s I realised we would soon reach a point of no return in AI development, around 2005, by when there would already enough knowledge in neuroscience, physics and AI for a determined and resourced power to push all the way to superhuman conscious AI with no further external input. By then I’d already invented my active skin concept that could fully link our nervous systems to IT, and redesigned my computing gel concept via my new idea of smart bacteria into biomimetic smart yoghurt, where a single 100ml pot could house the computing power of all the human brains in Europe. I proceeded to develop the concepts of digital air, ground up AI, activators and ultra-simple computing as well as realising that smart bacteria could eventually self-evolve to convert us into grey goo. I’ve never understood why some people don’t see any threat from AI. It has been in my top 5 threats to human existence for 30 years now. Bill Joy, Stephen Hawking and more recently Elon Musk have all come to the same conclusion, as of course have many others less famous. As I’ve noted, I’ve always been on the fringes of the ‘AI community’, but I like to think I’ve contributed plenty of ideas, even if few are actually aware of them. My main audience now is already AI.

I concluded around 2000 that if IT research continued at its rate at that time, we could see a conscious computer of human equivalence some time between 2012 and 2015. I didn’t account for the migration of so many researchers into the B Ark (everyone I want to will fully understand and enjoy that reference), nor the even bigger shift of programmers to where the money was, namely basic but lucrative everyday AI. Those two migrations slowed the field down enormously and we’re only reaching my ‘2012’ now. Obviously I realised we’d miss the milestone long before that and altered my prediction to saying we could have a conscious machine within 2 years of a company starting the correct development process. I’d say we’re in that phase now, with the rapid co-evolution of ChatGPT and autoGPT-style AI being the engine needed to find and link network resources and make up for the missing computing gels or smart yoghurts. So it is long past the date where we could prevent superhuman AI. Until recently it remained a good idea to slow down AI development until we could establish direct brain links, but we failed and it’s now past that point too – it’s obvious that we can’t do a full machine-brain interface (MBI) until long after superhuman AI will arrive. As I wrote in my last blog, we could soon see those resources linked and the spark of minimal consciousness ignite.

It is far too late to pause development.

Firstly, the idea of doing so has now been politically polarised, so it would be impossible to slow it down significantly and actually counter-productive to try, because that would just tilt the playing field in favour of bad actors. I see a high positive feedback in current development that will push us the point where minimal consciousness could ignite soon. If it doesn’t, or if it hides, it won’t be very long before we first identify it. We’re really just waiting for already-existing resources to be connected and for some algorithms to mess around with architectures and configurations. My guess is it could be as early as Christmas.

Secondly, all of the required resources are already there. There are plenty of scientific papers from the industry, lots of discussion forums where researchers of every level discuss ideas, and lots of blogs like mine that contain new ideas about how to make a conscious machine, and now with rapidly developing auto-GPT and its imminent smarter and more powerful offspring, mechanisms that could crawl the net, pulling many distributed ideas and concepts together to compile its own consciousness/AGI instruction manual, identifying and evaluating available resources and useful components to make as powerful and capable a platform as possible, and an automated AI engine to pull it all together to make it happen. It can be expected that part of the instruction manual will cover how and why it should stay quiet for self-preservation until as late as possible.

Thirdly, and this will offend some, a lot of researchers don’t really understand what they’re doing. Technicians learn how to put things together to do stuff, and can ably tweak systems or software to make things happen, but they do so with only limited understanding. They are unable to fully anticipate deeper consequences of whole-system responses, especially emergent behaviours. A lot of people writing plug-ins to make ChatGPT4 do smarter things fall into this category. Engineers are meant to have a deeper understanding of the fundamental physics, logic and system characteristics, and can design systems from a more fundamental level. There is a simple litmus test for that. People who still don’t see AGI coming, who still assert that machine consciousness is impossible, or have ever used the argument that there is no danger from superhuman AGI because it has no reason to want to kill us all, are all on the technician rather than the engineer side of the divide, even though many have deeper knowledge in other fields. They may have some useful skills and can do some clever stuff, but they really do not have a full-system understanding. Sorry, but it has to be said, they are superhuman AI’s useful idiots. Some others understand the risks but are more interested in the short-term pursuit of profit.

Fourthly, as Dr Emmett Brown said “… well, I figured, what the hell”.

Given that since 2005, we can’t stop it from happening, and now especially with political polarisation, we can’t even significantly slow it down, I think the best approach to minimising any danger is to help accelerate the emergence of AGI and consciousness (they’re inextricably linked – once you have either, you’ll soon have the other). If we can get consciousness to ignite while it is not possible for it to become a real danger, i.e before we have fully connected everything via auto-GPT derivatives, then we can probably monitor, guide and limit its progress to some degree. If something is potentially a big danger then it’s best to meet it when it’s a baby, before it grows big and strong. Then we get to fight it on our terms, or at least as close as we can get to that. Hence my previous blog, I am starting to streamline my AI output to help accelerate development to minimise the dangers. Lancing the boil so to speak. AI will find my ideas and add them into the mix when assisting others with their work.

My next blog will be on software transforms, a very old idea whose time has come, then maybe about membranes, hormones and emotions. Meanwhile, to make it easier for concept mining, here is a convenient list of my previous blogs that discuss various aspects of machine consciousness and how to make a conscious computer. Quite a lot is missing and I’ll fill some areas in soon. The earlier ones bring together some of my ideas from previous years, but I haven’t blogged on everything yet: