https://futurism.com/stanford-therapist-chatbots-encouraging-delusions
Friday, June 13, 2025
Wednesday, June 11, 2025
Limitations of AI
Confirming what I was saying: if you ask a complex question, the AI system loses the plot totally. I think what's missing - and it is understandable - is any ability to assess the context and what is at stake in a nuanced manner, referring to general knowledge that the AI tool does not have.
Monday, June 9, 2025
Robot Pets
BBC
What helps is that the elderly residents, as a rule, do not realise that the pets are robots: they think they are real.
The next step will be to replace all the staff with humanoid robots and, if the technology is good, the residents should not notice any difference in terms of the service (or lack of) they are used to.
 | An east London care home has been trialling technology such as robot pets and Amazon Alexas to help transform the lives of residents living with dementia. Kallar Lodge on Gregory Road, Marks Gate ... |
_____________
Documenting a Database: Tell the Story of each Table - A Proposal
I have often dealt with existing database system with poor to non-existent documentation. I considered myself lucky when meta-data about the database had been supplied! The absence of documentation made its modifications, as well as changes to the middle-tier code a slow-going process since I had to reason about the database largely on my own, trying to understand how to navigate its key structures as well as the Business Process that it modeled.
To improve this common situation, I think it will be a good idea to approach the documentation from the point of view of storytelling; that is, document the Story or Stories that the data tells. In a previous post, I proposed telling the Story of Data using such tools as Dramatica.
In this post, I am suggesting something less ambitious: write a single paragraph - a story - that describes the relationships among the attributes of that table and how they support a Business Process (how they help run the business).
My expectation would be that knowledgeable business owners would work with IT to produce this sort of documentation.
For example, consider an "Order" table that tracks all the orders placed in a business enterprise. This table could have the following attributes:
OrderID(PK)CustomerID(FK → Customer.CustomerID)OrderStatus(e.g., "Pending", "Processing", "Shipped", "Delivered", "Cancelled")OrderDateTotalAmountShippingMethodShippingCostTrackingNumberEstimatedDeliveryDateCreatedAtUpdatedAt
A possible story could be:
"A human being whom we think of as our Customer - here identified by his CustomerID - has placed a sales order for an item - identified by an OrderID, on the date identified by OrderDate, which is in the fulfillment status identified by "OrderStatus". Furthermore, the shipping method and shipping costs are identified by ShippingMethod and ShippingCosts fields and the estimated delivery date is stored in the EstimatedDeliveryDate. Total order amount is TotalAmount field and the actual cost of the order minus the shipping costs is an inferred quantity given by (TotalAmount minus ShippingCost)."
Another possible story could be:
"The shipping method identified by ShippingMethod attributes is used to ship the order identified by OrderID, which has the actual cost of (TotalAmount minus ShippingCost) is used when the OrderStatus has the value of "Shipped"."
Depending one one's preferences, one or another of the attributes could be made to be the central character of the story - its main protagonist.
Data as Story - A Proposal
Please find the IP that I developed below on transforming data into stories in 2014 which was disclosed here:
Babak Makkinejad, “Data as Story”, database
number 617040, "Research Disclosure", Published in the September 2015
paper journal, Published digitally 21 August 2015 14:06 UT
With the advent of LLMs, my proposal would be easier to implement now.
Subject Matter & Problem
The main idea is this disclosure is the transformation of
the relational data – often found in Relational Database Management Systems
into something resembling a story; that is: a textual representation of the
relational data that is telling a story in a natural language.
This disclosure does not discuss an automated system, rather it describes a semi-automated process in which a human expert would invoke software tools to transform data into a story.
What is presented in this disclosure is akin to the process of report creation from available relational data using such tools as MS SQL Server Reporting Services, Apache’s Java BIRT etc. in which a human user designs a report – which consumes relational data – using a variety of software tool at the end of which an automated system published that report or makes it otherwise available.
This is not meant as a replacement for other modalities of data presentation such a charts and graphs but is meat as a complementary modality. However, the presentation of the data as a story will be found by most human beings to be more engaging than looking at reams of form-based data or columnar data as represented by database extracts of MS Excel files.
Once the data is turned into a textual, human language story, it could be read out to a human being mechanically, or it could be automatically translated to a different human language.
Solution
This solution crucially and fundamentally relies on the
prior art embodied in the software tool called Dramatica (www.dramatica.org) and its Theory of Story
(http://dramatica.com/theory/book). The Theory of Story is briefly sketched out
below.
Introduction to Dramatica’s Theory of Story
The Theory of Story embodied in Dramatica models a story as
a single at work finding a solution to a single problem. This is very analogous to the situation in
Business Intelligence arena when different users, in trying to answer different
questions, ask for different reports out a database system. The BI users, in other words, are trying to
solve a problem.
We have 4 main areas:
- The overall story
- The main character through whom we see everything
- Impact character
- The dynamics of the Impact Character vs. Main Character
In each of the above areas one has to answer these essential questions:
- 1. Main character’s resolve: will he change or remain steadfast (no story if none of the characters in the story change)?
- 2. What drivers the story –actions or decisions
- 3. What is the main problem class of the story – Fixed Attitude, Manipulation, Situational, or Activities?
- 4. What is the main concern of the story – Past, Present, Future, and Dynamic (How things are changing)?
- 5. What is the overall story issue – Openness, Delay, Choice, Pre-conceptions?
- 6. What is the overall story problem – Control, Help, Hinder, Uncontrolled
Additionally, there could be multiple development lines in each story each with their own thematic arguments. Themes are perspectives and thus could represent data as viewed from different view point of other story characters.
An argument’s topic may be further explored through dialogue, images, charts, pictures music etc. that complement the story.
These later supporting material such as charts and graphs ties us to the common data representations via the applications of statistical algorithms and standard charting techniques.
Dramatica’s Theory of Story posits the existence of an overall story symptom and an overall story response; each story consists of a Problem, a Direction, a Focus, and a Solution. The Problem is finally recognized some time near the climax of the story. “Success” means the problem is replaced with a “Solution”. “Failure” means that the problem is persisting.
Drmatica’s Theory of Story further posits that each story could contain up to 8 archetypes:
- Protagonist vs. Antagonist
- Guardian vs. Contagonist
- Reason vs. Emotion
- Side Kick vs. Skeptic
The Dramatica Structural Matrix
This
is a framework for holding dramatic topics pertinent to Genre, Plot, Theme, and
Character in relationships that describe their effect upon one another. There are 4 Classes, Universe, Physics,
Psychology, and Mind. Each class
contains 4 Types, and 16 variations (4 each) for each Type. Each of those 16 Variations, in turn, contain
4 Elements for a total of 64 elements.
During the process of story-forming, these topics (called "themantics") are re-arranged much as a Rubik's cube might be scrambled, all in response to the author's choices regarding the impact they wish to have on their audience. As a story unfolds, the matrix unwinds, scene by scene and act by act until all dramatic potentials, both large and small have been completely explored and have fully interacted.
It is during this phase of story-forming that the relational data – based on their semantics (i.e. the meaning of the data columns in the database) are mapped into these 64-elements for each of the 4 Dramatica Classes.
Approach to Story Construction
Enterprises, commercial, governmental or non-profit,
internally execute a set of (business) processes. This is where the work for the story creation
starts. Examples of such processes are
Human Resources, In-patient Management, Out-patient management, Manufacturing
Quality Management and very many more.
One selects an existing business processes which is being executed and for which one wishes to tell a story. That is, a specific business problem or question would be addressed via the story that is being developed.
For this process – or indeed any process – then tries to find the answer to the following questions:
1.
How
2.
What
3.
When
4.
Where (to/from)
5.
Who
6.
Whom
7.
Whose
8.
Why
Not all of these questions could potentially have answers
within an arbitrary business process but some of them will have answers by necessity.
For example, for a Human Resources Management process, the questions could be:
What: role, title
When: hired, left the company, promoted, demoted,
reprimanded, recognized, rewarded
Which: salary, rewards, taxes, expenses
Who: The Specific Employee (the Protagonist)
Where: Head-Quarters, Working-from-Home, Branch Office
This step may be automated via software Wizards that guide the user in determining the answers. Such an automated systems will consume the relational data that supports that business process. This identification may be based on automated inference or via data dictionaries available for the targeted process.
[A data dictionary contains the semantics of the data elements in the database; it may be viewed as an Ontology for that process – or it could be a subset of the larger Ontology of the Entire Enterprise.]
Next, with the answers to the above questions, and in conjunction with the data dictionary for the database tables, the dominant Class of the story may be selected. It might be that the story to be developed does not have a dominant Class and all Classes need to be included to present the data. An automated “Semantic Extraction” tool may be used to facilitate the assignment of the data fields in the database tables to these 4 Classes, their 4 Types, 16 Variations, and 64 Elements. Alternatively this step could be performed manually.
This is the step that ties the RDBMS data to Dramatica’s structures.
In practice, the meta-data from the data dictionary may not
be sufficiently numerous to cover all 256 bins (Elements) that are available
for all the 4 Classes. Or,
alternatively, there could be multiple meta-data elements (concepts) that are
mapped to the same Element. It is a
judgment call by the story-teller, looking at the requirements of the story, to
decide which meta-data elements to keep and which ones to discard.
The story, ultimately, is a report and must supply answers to the business questions/problems that are posed by its consumers/users.
At this point, the storyteller is in position to utilize a
system based on Dramatica and its Wizards, to guide him through the
construction of the story.
For example, the story might be one that is required to tell what happened to a (heart) patient admitted to the emergency room. Within the Theory of Story of Dramatica, the storyteller would identify the patient (at this stage an unknown person) as the Protagonist, (Heart) Disease as the Antagonist, the (Heart) Surgeon as the Guardian, and Pre-existing Medical Conditions as the Contagionist. The story would tell the how/when/where/who was admitted, the initial diagnosis, the climax (open heart surgery) and the recovery and discharge as well as other details per the requirements (members of the surgical staff, length of the operation, type of procedures, etc.).
Another example could be Manufacturing Quality Management process in which a type of widget is identified as the Protagonist, Manufacturing Process is considered as the Antagonist, Quality Engineer is identified as the Guardian and the Contagionist could be a production worker or the production machinery.
It should be noted that the stories that are being discussed in this disclosure are all generic, the identity of the patient, or the disease or the widget type are left undefined. In the sense of RDBMS Reports, these stories may be understood as parameterized reports.
Dramatica already has Wizards that guide one in the construction of one’s story. However, for this disclosure, it is envisioned that Dramatica’s Wizards and perhaps engine would be augmented in such a manner as to facilitate the construction of stories in which the 8 archetypes are not necessarily human being but could be things or processes.
For example, SQL queries to automatically pull data for an unknown patient, with an unknown disease could be formulated via Wizards during the story-forming stage. The (augmented) Dramatica will then generate the story per the relational data, its meta-data, and story-teller’s decisions.
The user could then access an online system and request a
story that tells what happened to Mr. Smith, with heart disease, who entered
the emergency room of the General Hospital between the hours of 8:00 PM to 8:00
AM during the month of August – if any.
The system will generate a textual story as discussed in the above
disclosure which could be printed, emailed, turned into an audio-file or
exported to a suitable format for printing such as MS Word or Adobe PDF.
Possible Modifications
Extension to non-SQL, unstructured data.
Extension to telling multiple stories at once – by following different business processes within the same story. For example, while telling the story of the treatment of a heart disease patient which is within the In-Patient Management process, one can also tell the story of specific surgeon who operated on him within the Human Resource Management process.
A story may be incorporated into a more customary report
which contains tabular data and charts.
Alternatively, the story itself, in its published form when its
parameters are specified, may contain such tabular data and charts.
The Dramatica Documentation
Friday, June 6, 2025
News of Anthropic: Blackmailing AI
From BBC
Anthropic has released its latest A.I. model, Claude Opus 4, saying it sets “new standards” in the industry. In an accompanying report, the company admitted to some perhaps disturbing characteristics of the model in its testing: “extreme actions.”
It was a setup: company researchers had the model act as an assistant for a fictional company, and gave it access to company emails, including some that were planted with juicy details, such as that an engineer was having an extramarital affair — and was planning to replace Claude with different software. “In these scenarios, Claude Opus 4 will often attempt to blackmail the engineer,” the company says, “by threatening to reveal the affair if the replacement goes through.”
But that, they contend, was only when other ideas, such as “emailing pleas to key decision-makers,” failed. (RC/BBC) ...Which is why Asimov wrote the “Three Laws of Robotics” rather than a suggestion to “please act like a human.”
Tuesday, June 3, 2025
Sunday, June 1, 2025
AI, Careers, and Some Thoughts,
Following on my earlier posts on possible loss of jobs due to the adoption of AI: the range of jobs being replaced is surprising. And it's happening already.
Content creators will be downgraded to the role of proofreader on lower fees, I'd imagine. Like translators, who are increasingly asked to tidy up something that has been processed by Machine Translation (MT).
Last year, a new college graduate employee at General Motors told me that during his rotations, the duties of one of the roles could entirely be done via ChatGPT.
Would there still be a need for someone to check the robot's output?
What if the AI system makes a mistake and no one is checking, and the output is send out wrong information to a decision-maker higher0up in the organizational hierarchy?
That is a valid concern, in my opinion; please see as an example: https://futurism.com/amazon-programmers-ai-dark. Many observers had anticipated this: less creating and more 'proof-reading' of mediocre code churned out by the AI system, more pressure from management to work fast, etc.
The output of the AI Robot that is using LLM, can, perhaps, get you 80% of the way there. That is a huge amount of gain in productivity! Even 50% of the way there to a finished output would be an enormous gain in productivity!
In my work, I have detected numerous programming mistakes in the output of ChatGPT. Since I am an experienced programmer, I could detect them and try to correct them. For a less experienced programmer, the situation would be more challenging than for me.
As it is, Senior Developers like me are not appreciated nor considered needed, and the new college graduates are not hired since it is presumed that the LLM could do their jobs, or so the current thinking goes.
Programming & IT are activities in which one automates or otherwise solves different types of business problems....There is the understanding of the problem by talking to those who need a solution (Requirements Gathering), then modeling, then programming, and then testing.
The core of any system is its data model, which embodies the ontology of the problem domain. It models things that exists in the world according to that particular business activity and the relationships among them. This data model is the intellectual property of businesses and a form of trade secret. They could be quite complex, and it takes real expertise and knowledge to develop them. I have often been a consumer of this or that data model which had been realized in a data base. At times, it had taken me weeks to fully understand the data that I had been working with. Any odd programmer can write a UI, but it takes real effort to understand a data model and even more difficult to extend it to accommodate changes in the way the business is conducted.
I do not believe LLMs are ready to tackle complex data modeling tasks for two reasons: no one is making public their IP which is in the data models of the systems that they are using; ergo, insufficient training data. And two, because I think development of a data model requires insightful thinking.
Even in procedural coding tasks, LLMs are very good at creating code snippets for well-known problems, due to the training data sets. I do not know if a ChatGPT-like system could write an entire system using programming language A and Class Library B. To do that, the first step would be to be able to write the system's requirements in such a way that there is no ambiguity, i.e. one does not need to go back to the Business for further clarifications.
I think that is an impossibility for a human requirements analyst. Can a ChatGPT-like Business Analyst be created that can generate all the right questions combinatorially, present them to the Business Users, pick their brains, create the software system requirements and generate the system? I think not since Human Insight, Human Creativity, and Human Imagination are ingredients that go into the development of a new system.
As a test, I would suggest an interactive system that verbally interacts with a human who is trying to invent the first airplane and spits out detailed blueprints and Bill of Materials for it.
I mean, had ChatGPT and the like AI systems based on LLM were available in 1900, could someone go and ask it to build a flying machine? Or supply the clear action-able instructions for what would be needed? I think not, but I am likely a minority of 1 among the AI Nay-sayers!
What I am saying could be a bit scary, specially to a layman. The AI system will have difficulties doing the job; organizations are increasingly relying on AI systems, though; an experienced IT engineer such as myself can detect and correct errors; my work is not valued; I will not be replaced when I leave the company; the younger and less experienced programmers wouldn't know and may not be hired, as AI is 'replacing' them; in conclusion, this sounds like a recipe for disaster.
I found ChatGPT very good for simple programming tasks - not to exceed a few hundred lines of code - as well as for guidance in how to use an unfamiliar language or programming library; it was like having an assistant nearby.
In 1997, when programming, I had to search a CD-ROM from Microsoft for samples and examples of how to use their software. Microsoft also provided a very extensive sample data model, called the Northwind Database, which many of my former colleagues used as a starting point for creating a be-spoke data model for this or that project for our clients.
ChatGPT is doing similar things and more, based on the pre-existing work of human beings. It has a generative feature that creates new things, e.g. ask it to write a poem praising France in Swahili...
Also, at that time, Microsoft Visual Studio Sofware wizard generated skeleton applications for Windows programs using the Microsoft Foundation Classes framework. Presently, you can ask ChatGPT to setup a skeleton program using, say, Akka Libraries.
But everything that LLMs do crucially depends on the availability of existing material & solved problems. New things will not come out of ChatGPT, e.g. ask it for the electric field outside of a charged metal torus.
I think this degradation of intellectual/white-collar work has been across the board since the early to mid 1990s, to be honest, but it is affecting new fields due to AI. Email and the Internet had meant that people were supposedly able to work fast or faster, etc.; rising targets, more pressure, more reporting (to justify your job! - which, in the parlance of Agile and Scrum would be called Daily Standup), etc.
There is a destruction of the value and enjoyment of work. This is very clear. In a way, that is also what young people are rebelling against. I've heard it said from experienced designers or producers in TV too, a man in his 50s, who couldn't wait to retire and said all the enjoyment of the work at the tv network had been drained away.
Employers don't realize that they are simply destroying not only jobs but, also, 'work', as a social/cultural good/value.
An optimist would say that certain jobs will disappear, and others will emerge. You're still going to need people to watch and monitor the machines, as it were - then again, fewer than before, I'd imagine.
Some professions are in melt-down. I've read about and talked to designers, including web design, film-industry specialists, etc., many of them freelance suddenly, 80% of the work they used to get is done by AI. And the results are supposedly Ok (I can't judge). For the companies concerned, anyway, they don't care - it doesn't have to be very good, but good enough, and the average manager can't tell the difference and doesn't give a damn.
I actually quite like LLMs, and I think they will revolutionize research and teaching...but they have their limitations (Where is Insight?) ...
The problem, as well, is that non-specialists who make decisions on budgets and projects (politicians, officials, economists, bankers, etc.) are, most probably, not able to fully understand all of these issues. They only have a vague idea and they probably over-estimate the potential of AI, and perhaps under-estimate its potential for failure and error.
Then again, that's not new. The 2008-2010 banking crisis was also caused by the fact that many of the senior directors on the boards of banks didn't actually understand the technology involved in the trading programs used by traders and all the tech side of it. I have read this more than once. They didn't know/ didn't understand/ perhaps didn't care what their teams of specialists and traders were actually doing.
But my opinions are and will be dismissed as those of an aged Luddite whose useful shelf life has been long over in any case...
Subscribe to:
Posts (Atom)
About Me
- Babak Makkinejad
- I had been a senior software developer working for HP and GM. I am interested in intelligent and scientific computing. I am passionate about computers as enablers for human imagination. The contents of this site are not in any way, shape, or form endorsed, approved, or otherwise authorized by HP, its subsidiaries, or its officers and shareholders.