Conversation
pcdeadeasy
requested review from
DanielRosenwasser,
hillary-mutisya and
steveluc
| #.vscode | ||
| #**/.vscode/* |
There was a problem hiding this comment.
I don't want these removed - if you need an exception for the root .vscode/launch.json, I'd add that.
.vscode/launch.json
Outdated
| ], | ||
| "compounds": [ | ||
| { | ||
| "name": "Debug All Projects", |
There was a problem hiding this comment.
I don't think this is a realistic task to have. I'd get rid of it.
| "version": "0.2.0", | ||
| "configurations": [ | ||
| { | ||
| "name": "sentiment-wsl", |
There was a problem hiding this comment.
Why do we need wsl-specific tasks here? People should just enter the directory from within WSL if that's what they want.
There was a problem hiding this comment.
It's makes it easier to debug from the root. You need a separate config for WSL if you are debugging in that environment using VSCODE.
There was a problem hiding this comment.
Wait, really? Even if you're using the WSL extension?
There was a problem hiding this comment.
So I tried this out locally - my experience is that externalTerminal didn't seem to work at all, regardless of whether I was running in WSL or not. Instead, only integratedTerminal worked across both.
So I think that matches what I recommended elsewhere - that all the WSL-oriented tasks should be the defaults, and there shouldn't be any sort of variant. If that's not matching your experience, we can jump on a call and run through it.
There was a problem hiding this comment.
Yes, let’s sync on Monday. I want to check the configuration on windows.
| // Process requests interactively or from the input file specified on the command line | ||
| processRequests("🤗> ", process.argv[2], async (request) => { | ||
| const initClasses: string = JSON.stringify(classes, undefined); | ||
| const fullRequest: string = `Classify "${request}" using the following classification table:\n${initClasses}\n`; |
There was a problem hiding this comment.
A few things about the classification example feels off.
First, this seems far too similar to the sentiment example. The biggest difference is the custom prompt - but it very well may be the case that a custom prompt needs a custom translator.
Then there is the fact that we're effectively doing a look-up - but if you have that information, then why do you need things like a description anyhow?
If you have a fixed set of items, you could describe that directly in the schema, right? Or you would just use embeddings to fetch the most similar one?
There was a problem hiding this comment.
The way I look at it is the sentiment example is a special case of the classifier example. Another way of doing this would be to use a custom translator but we do not need it as the translate method has a promptPreamble parameter.
Yes, I could also describe it in the schema as well but that idea is to keep the data (classes) separate from the schema. What do you think?
2 participants
Added a new example to support classification using a simple schema file and pre-defined classes.