zlacker

[return to "Cyc"]
1. catpol+Zz[view] [source] 2019-12-13 18:04:58
>>mdszy+(OP)
I worked for Cycorp for a few years recently. AMA, I guess? I obviously won't give away any secrets (e.g. business partners, finer grained details of how the inference engine works), but I can talk about the company culture, some high level technical things and the interpretation of the project that different people at the company have that makes it seem more viable than you might guess from the outside.

There were some big positives. Everyone there is very smart and depending on your tastes, it can be pretty fun to be in meetings where you try to explain Davidsonian ontology to perplexed business people. I suspect a decent fraction of the technical staff are reading this comment thread. There are also some genuine technical advances (which I wish were more publicly shared) in inference engine architecture or generally stemming from treating symbolic reasoning as a practical engineering project and giving up on things like completeness in favor of being able to get an answer most of the time.

There were also some big negatives, mostly structural ones. Within Cycorp different people have very different pictures of what the ultimate goals of the project are, what true AI is, and how (and whether) Cyc is going to make strides along the path to true AI. The company has been around for a long time and these disagreements never really resolve - they just sort of hang around and affect how different segments of the company work. There's also a very flat organizational structure which makes for a very anarchic and shifting map of who is responsible or accountable for what. And there's a huge disconnect between what the higher ups understand the company and technology to be doing, the projects they actually work on, and the low-level day-to-day work done by programmers and ontologists there.

I was initially pretty skeptical of the continued feasibility of symbolic AI when I went in to interview, but Doug Lenat gave me a pitch that essentially assured me that the project had found a way around many of the concerns I had. In particular, they were doing deep reasoning from common sense principles using heuristics and not just doing the thing Prolog often devolved into where you end up basically writing a logical system to emulate a procedural algorithm to solve problems.

It turns out there's a kind of reality distortion field around the management there, despite their best intentions - partially maintained by the management's own steadfast belief in the idea that what Cyc does is what it ought to be doing, but partially maintained by a layer of people that actively isolate the management from understanding the dirty work that goes into actually making projects work or appear to. So while a certain amount of "common sense" knowledge factors into the reasoning processes, a great amount of Cyc's output at the project level really comes from hand-crafted algorithms implemented either in the inference engine or the ontology.

Also the codebase is the biggest mess I have ever seen by an order of magnitude. I spent some entire days just scrolling through different versions of entire systems that duplicate massive chunks of functionality, written 20 years apart, with no indication of which (if any) still worked or were the preferred way to do things.

◧◩
2. dmix+bF[view] [source] 2019-12-13 18:39:53
>>catpol+Zz
Two easy ones for you:

1) How did they manage to make money for so long to keep things afloat? I'm guessing through some self-sustainable projects like the few business relationships listed in the wiki?

2) What's the tech stack like? (Language, deployment, etc)

◧◩◪
3. brundo+wH[view] [source] 2019-12-13 18:56:26
>>dmix+bF
Current Cycorp employee here.

1) One-off contracts, sometimes with ongoing licenses, from various large organizations who have use cases for inference. We did a lot of government contracting for a while; now we mostly stay in the private sector.

2) An in-house dialect of Common Lisp that compiles to Java (it predates Clojure). Deployment is still fairly ad-hoc, but we build Containers.

◧◩◪◨
4. elwell+yi1[view] [source] 2019-12-13 23:28:34
>>brundo+wH
> Common Lisp that compiles to Java

To Java bytecode or to Java code?

◧◩◪◨⬒
5. catpol+Bj1[view] [source] 2019-12-13 23:38:58
>>elwell+yi1
Java _code_. It's madness, though I'm assured it made sense at the time.
◧◩◪◨⬒⬓
6. dogma1+5n1[view] [source] 2019-12-14 00:16:46
>>catpol+Bj1
It makes more sense than generating bytecode since your “compiler” doesn’t need to comply to runtime changes other than high level API compatibility and you can leverage the performance improvements of which ever Java compiler is used to produce the final bytecode.
[go to top]