bobbruno

Isn’t the EFF that (or it’s intention,at least)?

In most cases, the ones who do sue are neither - they’re companies themselves, with shareholders of their own, or funds with specific regulations (which amount to much the same, if not more specifically profit-oriented).

These are not people, they don’t think morally the way people do. These are not demons, they are not evil themselves - these are more like machines, algorithms tuned to maximize profit. This structure is our paper-clip optimiser, already in place much before the AI revolution. If there is a devil, they are the ones behind setting up this entire system, not a player in it.

That thinking is one reason why I left engineering and I don’t see myself coming back to it anytime soon. I don’t like being on-call, I’m not qualified to do Ops-like decisions and I haven’t seen this as the practice in most other industries - Boeing doesn’t have staff flying planes for the airlines, for one.

Compliance is a set of stories/tickets/requirements like any other, with a priority to be assigned and eventually worked and reworked at some point in the process. There’s nothing wrong with not addressing it as the first thing - it just blocks release. With that, it will eventually get worked on, hopefully at the time where the pieces that need it are understood and the work to reach it is understood.

How can that fly if the operate in Europe, if GDPR provides the right to be forgotten? If you won’t even be acknowledged, that blocked account may contain private information about you that you must be allowed to request deletion of.

You can find an article on Bloomberg stating that Databricks’ annual revenue has grown by 60%, which sort of backs the SaaS hypothesis it bets on. Do you have data on your PaaS hypothesis that is bigger than that?

Source: https://www.bloomberg.com/news/articles/2023-06-13/databrick...

I’m a solution architect at Databricks, so feel free to skip if you think I’m too biased - just know that I worked with Databricks before working for them, and I liked the platform then as well.

While Databricks definitely started with Spark, and it’s still a significant foundation, there’s done much more on top and around it. For instance:

- MLFlow for ML lifecycle management from experiments to real-time ML serving;

- Delta Storage format, extending parquet to leverage cloud storage and enable efficient updates and very fast access;

- SQL Warehouses, which expose Databricks as a SQL engine for Analytics;

- Jobs/Workflows, which is one of the most used orchestration engines in the world;

- Unity Catalog, which will replace (at least in Databricks) Hive Metastore for metadata, access control, lineage and data governance tooling in general.

And now LLMs, on top of the data and ML capabilities mentioned above, much extended by the Mosaic deal (still to be approved).

The interesting thing is that yes, Databricks can do the whole “Data Warehousing” thing, but it can also do very large scale streaming, machine learning, process unstructured data like text, audio or images, support BI applications, etc - all accessing the same data with compatible tooling. So, it’s a full blown multi-workload data platform for any kind of use case and company size.

One can argue that most components are open-source and can be deployed independently - and Databricks has open-sourced Spark, MLFlow and Delta. It’s just that most companies simply don’t have enough (if any) staff with skills to deploy and operate all these things, let alone as one integrated platform. With Databricks, I’m used to deliver a demo where it takes me about 20 minutes from having a new cloud account to be running data workloads against a cluster or SQL, with all the functionality above.

Are you sure? If you look at plagiarism in music, you'll find a number of cases where the defendant makes a compelling point about not remembering or consciously knowing they heard the original song before. For legal purposes, it is not the point, but they feel morally wronged to be charged as guilty. The case here is that they internalized the music knowledge, but forgot about the source - so they can't make the distinction you claim anymore. Natural selection shaped our brains to store formation that seems useful, not is attribution.

LLMs are also not usually trained to remenber where the examples they were trained on came from, the sourcing information is often not even there (maybe they could, maybe they should, but they aren't). Given that and the way training works, one could argue that they're never copying, only re-expressing or combining (which I think of as a form of "generating something original"). Just memorizing and copying is overfitting, and strongly undesirable, as it's not usable outside of the exact source context. I agree it can happen, but it's a flaw in the training process. I'd also agree that any instance of exact reproductions (or of material with similarity to the original content over some high threshold) is indeed copyright infringement, punishable as such.

So, my point is, training a model on copyrighted material is legal, but letting that model output copies of copyrighted material beyond fair use (quotations, references, etc - that make sense in the context the model was queried on) is an infringement. And since the actual training data is not necessarily known, providers of model-as-a-service, such as OpenAI with GPT, should be responsible for that.

In cases where a model was made available to others, it falls on the user of the model. If the training data is available, they should check answers against it (there's a whole discussion on how training data should be published to support this) to avoid the risk;if the training data is unknown, they're taking the risk of being sued full-on, without any mitigation.

On a first read, I could agree with most, if not all, of the author’s arguments. But there are two aspects that were simply left out that I have to consider when doing MLOps, which can prove too complex for just saying “It’s an extension of tooling that data engineering already has”.

First, there’s the matter that ML introduces a significant stack and complexity into what was already a relatively complex framework. I mean, managing storage, quality, data processing, streaming, scheduling/orchestration, transformation logic and SLAs requires a lot of tools, whichever combination pleases you the most. Even full platforms offered by some of the players in this market can get quite complex, and it’s very hard to set everything right and handle all the cases. Specialised tooling or skills is probably a good idea to focus on the things that matter to Ml and that go beyond what DE already covers. Think of all the frameworks, the statistical libraries, the different nature of the logic for ML features when compared to regular reporting needs, the different quality requirements and structure that ML expects, managing versions of raw, labelled and test datasets, etc. (there are many more, the discussion already covered quite a few).

Which brings me to the second thing - the knowledge stack required to run ML. Besides some of the usual DE stack (developing, data manipulation, quality, etc), a whole new set of skills, related to several branches of math, parallelism, very complex and costly infrastructure management, research skills, experiment design, specific algorithms and approaches (does the regular DE need to understand neural network patterns, how data and model-parallel training works, the statistics behind setting up and running drift measures, what all the metrics behind model performance mean, etc.?). I find this a better reason for specialisation than any other - there’s just so much one person can hold in their heads, and ML development and operations is just getting more complex by the day.

So, my point is, from a very simplified and abstract perspective, the author seems right. But, in practice, you won’t be able to just stack that on top of data engineers and not expect them to become specialized - and that’s where the ML Engineer and MLOps engineer roles are emerging. They’re not completely new, but they’re no longer your regular data engineer or data scientist.

I find it strange that so many people in this area get concerned about becoming obsolete. Back in college, I clearly remember a discussion we had (me and colleagues) about how our job was exactly to get us obsolete as soon as possible, so we could go do the next order of things.

I wish most of my real life work were exactly like that, it'd be much more fun.

And won’t it be nice when that happens that you will then be able to jump from app to app because they are required by law to interoperate?

I’m taking the leap that you’re from the US - if you’re not, then the first comment may not apply to you.

> bodies like the EU (led by appointment, not elected politicians) decide on technical standards

The president of the United States is not directly elected.They are voted by the electoral college, which introduces all the problems of gerrymandering. EU council are appointed - by politicians from each country, directly elected. You could argue it is less problematic.

> will force a lowest-common-denominator implementation on independent private companies who, up to this point, Havel all been innovating in this space

I prefer to see this as “they will mandate a minimum interoperaability standard on a public, regulated, communications service, which is conceded by the nations. And colouring bubbles green or blue is not innovation. Neither is refusing to work with others that have at least as good implementations just to keep your walled garden. > the EU desperately wants to compromise end to end encryption

Not “the EU”, some council members. A sufficiently large number of EU countries are adamantly against that proposed legislation, it has more chance of not passing at this point.

As stated above: the nation that nominated the commissioner can recall its commissioner.

You can justify post facto the move you made. Can you write down the logical process (probably a combination of strategy, move generation, analysis and selection) that would replicate the moves you picked from the beginning of the game? I don’t even need the brain chemistry (the implementation), but I don’t think even writing down the logic that generates those moves (in contrast with a logic to justify each move after it was generated) is something humans can do in most cases.

That is not true. The dataset is needed, the same way that examples are used by a person learning to draw. But the dataset alone is not capable of producing images not derived from any part of it (and there are many examples of SD results that seem so far to be wholly original), so you can’t reduce stable diffusion to being only derived from the dataset. It may “remember” and generate parts of images in the dataset - but that is a bug, not a feature. With enough prompt tweaking, it may even generate a fairly good copy of pre-existing work - which was what the prompt requested, so responsibility should lie on the prompt writer, not on SD.

But the fact that it often generates new content, that didn’t exist before, or at least doesn’t breach the limits of fair use, goes against the argument made in the lawsuit.

Can you draw Biden without ever having seen him or a picture of him? So,why is it that you are not deriving but SD is?

That. The legislation is not forcing the choice on any consumer, it’s giving them their choice back by forcing Meta to ask the question in clear terms and allow users to clearly tell Meta they are not allowed to spy.

Now, if Meta can’t make a viable business model without denying users the choice, doesn’t that mean that their model is flawed? The thing is, for users to understand what they are choosing, they need to understand their right to privacy and why it matters. It took the EU at least a decade (possibly more) to reach the point where they are starting to apply this legislation.

> without even a vote I’m not sure I follow what kind of “vote” you mean here. The legal framework behind the decision has been in discussion since at least 10 years ago, and most EU countries and the EU parliaments are democratically elected. The lawmaking progress in the EU parliament also is very open to public scrutiny and feedback, and the privacy laws went through it. This all supports the idea that the right to privacy online is pretty much a core value supported by most of the EU population, one which they have been supporting through their votes and participation in the law-making for many years.

And if your implied suggestion was that the business model of company X (and whatever benefit they may provide through this model) is a more important vote than the basic value of privacy, or that the issue of cost was not brought to the table enough times for people to understand the trade-offs, then I guess my understanding of how democracy works is different than yours.

I’m not so sure. My observations are certainly not statistically significant, but I’m a Brazilian who moved to Germany. One of the things I noticed when using email here is that the amount of people who have an email not @gmail.com, but whatever German provider that has to follow GDPR is much higher than what I saw back in Brazil. This suggests that the population in general in Europe is indeed more privacy-conscious.

This may be difficult for an American to understand, but a driver's license is not a core document, and many people may not have it. In most places it'd not come to mind in a discussion about digital ID.

Have you heard of the southern hemisphere? All those Brazilians, Argentinians, even Mexicans? Quite similar time zones to much of US…

Removing the possibility of financing phones and calls through ads changes the entire market dynamic. I can’t say for sure that the ad-free prices wouldn’t drop because they were suddenly the only option available and scale gains (or a survival need) would drive costs down.

Companies won’t lower their prices if they don’t have to, but they will go to great lengths to survive…

Having done both sides of the work, I totally understand the author’s perspective. Modelling and coding production are certainly two different skillsets, and many people will prefer one or the other, but not both. Now, there is one thing I guess the author doesn’t get (or he gets but doesn’t like) and a thing that most companies don’t get.

The former is that companies don’t care enough about what the individuals they hire prefer - especially not if it doesn’t address their need. They don’t need a beautifully crafted model that can’t be run - they want actionable results that hit the bottom line, and in the energy forecasting model that means generating new forecasts at every cycle (months, days, hours, minutes - whatever). A great model that can’t be put in production and run efficiently has about the same value as no model, and an average model in production will have much more impact.

The latter is that companies don’t usually understand that ML is not software development. Putting ML in production is, but finding the right model is research work, and code is mostly a discardable tool for research. Its goal is not to go live, it is to validate a hypothesis (in this case, that algorithm X, when presented with data Y, generates a model with enough predicting power to be useful to the business). This validation requires code to gather Y, clean/join/analyze/reshape/featurize it into a more informative and clean representation (clean from the algorithm’s perspective, not necessarily a human’s), run X, run inference with the generated model and run some test of the results against additional data.

If this test is negative, some or all the code written above is useless, and we go back to the drawing board. Given the very coupled nature of this process (a new data source has to be joined to the rest - coupling; a new data transformation changing a feature changes the data schema downstream - coupling; a new algorithm needs a different data input - coupling, and so it goes). If you have an experience like mine, you may actually be able to write in a way where you can reuse some of it, but I have 28 years of experience with data, there are simply not enough people in the market with that level of background or the interest in learning all this. Companies must accept that they will not always get this perfect candidate with all the skills they want, and start thinking of pairing the right people in teams.

Some who have been around for a while may remember the Venn diagram of the perfect Data Scientists - it usually was an intersection of business, math and programming skills (also often communication skills and a few others). My thoughts since I first saw this diagram were: “Even if there are people out there with all these skills, why would they want to work for others?”

This, more than anything else, is my guess at the core reason why so few companies are successful in putting ML in production.

The idea that creating a model can be a “user story written in math” seems to me a variation on a common misunderstanding about what model creation, particularly the role of coding in it is. Data scientists, statisticians, modellers, don’t go in knowing what the model is and just coding or specifying it. They use code as a exploratory tool to test several hypotheses until they find one that seems to hold - the code, the data, the algorithm, the statistical test, the exploration and the reasoning are all tools in the process of discovering the right model. It simply can’t be specified in advance, it has to be run and tested.

Having som spaghetti code is a natural consequence of this exploratory, iterative process. Applying good SW engineering practices to this exploratory endeavour is just a natural consequence of the process when you don’t know if your code will be of any use before you finish running and checking the test results. Why would you bother modularising and doing test coverage on something that is very likely to be thrown away after one or 2 runs?

I say this from 28 years of experience both as a data engineer and data scientist. I am a good python developer, and I can write production grade code. But I won’t refactor my code into that until I know that is the code that generates the right model. And I certainly can’t specify this particular code before writing some dirty version of it, testing it and confirming that the model it trains passes some statistical tests, at least.

Basically, the code is not the product - the product is the result of applying some transformations on data and running that through some ML or statistical algorithm to generate a model. Transformations and algorithm being unknown to be useful until tested, hence specification being unknown until coded, run and tested.

While I tend to agree with most of the arguments that DS code is usually of low quality, and that DS are not well-trained in good development practices, I wonder if making them better coders is an attainable goal, or even a proper one. My reasons for that questioning: - Data science requires a significant stack of knowledge beyond coding - in fact, to be a useful DS in a company, you already have to learn about maths, business domains, keep up with the latest algorithms, know how to manipulate data, present, run experiments, analyse them, know deep statistics and some others I am probably forgetting. Adding the SW dev skills on top of that and expecting them to become good developers is a tall order, and only a small percentage of the DS community will achieve it. With the level of demand for ML, I don’t know if this will deliver on the market needs - it’s not that it’s not attainable, I think it’s not scalable; - People coming from a SW dev background tend to think DS is the same, just done by people who don’t code well. That is not true: code is the final product of software development, while it is but a tool for reaching the goal of finding a good ML approach for a DS. The consequence here is that SW dev has a much stronger reason for wanting good quality, maintainable code than DS does. When researching for a solution, many iterations of code written by DS will be discarded without ever having to go to production, and I don’t know if the overhead of keeping good tests, structuring the code, making small commits, etc., is justifiable in this scenario - the goal is not to have maintainable code, it is to see if the model+features has potential for solving the problem. - Evolution and maintenance are also a problem, because the structure that’s good for operations doesn’t help the job of research - it’s not common for a DS to work in a pipeline structure (which seems to be the emerging pattern for MLOps), and forcing them to use that structure on all iterations after the first will have significant productivity issues, to the point of putting success at risk;

I don’t have a solution for the points above, and I understand that, once a promising approach has been found, the code starts to matter much more, because Ops will require it to be automated and executed in a reliable way. For now, what I do is to do the research in a very loose way, not caring about good SW practices. When I find something good, I start refactoring the code to meet the Ops expectations. But I’m a CS major with decades of experience in coding and ML - it’s not reasonable to expect the entire DS community to develop the same skills, it takes too long.

Any ideas out there?

That is the reason why I still have a cellar full of books and over 1000 CDs. I refuse to let someone else take control over the content I buy after I’ve bought it. I’d be happy to pay for digital content, but if it comes with DRM, it’s a non-negotiable “No, thank you sir.”

I can suggest an idea, considering that the “AI program” is the model, not the training algorithm.

A program gets written by an entity (usually a person) and is executed to generate the desired output according to a deterministic mathematical function it expresses. A training algorithm is a program that gets written to train a model (the model being the “AI Program”) when presented to some training data inputs, to implement a function that is not the training algorithm function itself, but another one, generalising over a problem domain beyond just the original examples fed to the training algorithm.

The output model is not the training algorithm or the training data (or an encoding of it) and exists as its own artefact, independent of both.

True and valid. But all those clauses, AFAIK, were written with the mindset of ïf you want to run this code (particularly, but not limited to, for profit), you have to at least attribute it”. Copilot allegedly doesn’t run that code - it claims to read it, understand how it works and then generate its own code that does an equivalent function if requested. It’s up to the lawsuit to decide if that’s what it actually does, but my point is that the licenses simply did not cover this usage pattern, as much as no open source license requires any kind of action from someone who’s just reading or studying the code.

If I read 10 or 20 books about a topic and then go teach that topic to others, do I have to attribute each thing to all the authors from where I learned it? And what if I come up with my own interpretation of a topic, do I have to trace it back to all interpretations of all the authors that influenced it? Even more, do the previous authors also have to do that and do I have to quote all the chain of references? If not, why an ML model that is supposed to learn how coding works, not memorize pieces of code verbatim, should have to “because of copyright laws”?

Last I checked this was very much a gray area. I’d expect at least a long investigation into the amount of work and testing put into validating that the self-driving algorithm operates inside reasonable standards of safe driving. In fact, I expect that, as the industry progresses, the tests for minimal acceptable self-driving safety get more and more standardised.

That doesn’t answer the question of who’s responsible when an accident happens and someone gets hurt or dies - but then, there was a time when animals would be judged and sentenced if they committed a crime under human law. That practice is no longer deemed valid, maybe we need to agree that, if the self-driving car was built with reasonable care, accidents can still happen and it’s no one’s fault.

I believe this is the core point of the lawsuit - is Copilot really creating code from what it learned (which happens to, by some weird glitch, mimic the source code) or is it just a big overfitting model that learned to encode and memorize a large number of answers and spit them out verbatim when prompted?

I think that losing this lawsuit has much more serious consequences for Copilot than just having to connect to a list of millions of potential copyright owners - it would mean the model behind it is essentially a failure.

Personal opinion: the real situation lies somewhere in the middle. From what I’ve seen, I think Copilot has some ability to actually generate code, or at least adapt and connect unrelated code pieces it remembers to respond to prompts - but I also believe it just “remembers” (i.e., has a close-to-lossless encoding of the input) how to do some operations and spits them out as part of the response to some prompts.

I hardly think the lawsuit will really explore this discussion, but it sounds like a great investigation into what DL models like transformers actually learn. For all I know, it might even give insight into how we learn. I have no reason to believe that humans don’t use the same strategy of memorising some operations and learning how to adjust them “at the edges” to combine them.