It looks like the default mode is renamed to "refine"
It does, I was reading the source code lol
1 out of 2, not bad π₯²π
hmm. how odd. with change to 'refine', still not working.
does everything else i am doing seem right..?
as i say my company is using this so i sort of need to get it back up & running...
Still not working with the same error?
error now is 'UnicodeEncodeError: 'latin-1' codec can't encode characters in position 7-57: ordinal not in range(256)'
...
(Side note, I highly recommend versioning your python libraries to avoid them automatically updating and breaking production apps π)
Uhhh what haha do you have a longer traceback? To me that looks like it's trying to read a document that's in a weird encoding...
π₯² If prod is broken, you can downgrade pip install=0.5.27
, or setting the version in your requirements file π«‘
Wow that's a weird error. It's deeeeep past langchain lol
It seems like somehow some text in the index is not encoded with utf8? Or something like that?
And this worked before with the same documents?
(removed my prompt as has company info)
Hmmm I don't think so... it's erroring out when connecting to openai actually... at least I think, trying to follow the traceback lol
Can you maybe try with some super short dummy documents? Maybe it's how you have your key set? π€
yes 2 secs. altho the key was fine before
altho tbh in my console I am printing the documents & they look normal..
is there something i am not importing for the new updates?
That looks fine to me π€ I think a small dummy sanity test is the way to go
ok i will do the dummy test with diff docs
but i reset my openai key and it is now not showing the error but is just not responding when i ask my question from slack
anyway. i will do the dummy test and update..
ok with just 1 document as opposed to 40, it works
OK, sanity has been checked π«‘
But also, that doesn't make debugging any easier π₯²
So for your index, you are pulling from notion it looks like?
Something is causing urllib to make a request using Latin-1 encoding, which is not correct...
Maybe you need to re-encode the doc texts before adding them to the index?
I have a feeling some doc has a weird token... that's the only thing that makes sense lol
So I have been going thru the docs quite paintstakingly & all seem to be fine.
I am now not getting an error message but taking an INFINITE time to get a response
Is this because I am using "refine"?
Before I was using mode = embedding & response_mode = default
Now I am using retriever_mode = embedding & response_mode = refine
But perhaps that is a mishap?
I mean this is really taking a long time. Has this happened to anyone else when updating from 0.6.2 to 0.6.4?
From 0.6.2 to 0.6.4 I wouldn't expect that... π€ refine is the same as the old default mode too.
Tbh, if you are always using emebddings, is there a reason to use a list index? You could use GPTVectorStoreIndex instead? The setup is a lot more straightforward... maybe there is a mistake I'm not seeing with the current list index π€
Ok. Vector Store Index works well, actually...
So, interesting. I tried vectorstoreindex with response mode = refine. And I found that it was getting things wrong quite a bit. It would input nodes giving info about two product features and then confuse one feature with another. Interesting because this was not at all happening with refine mode in the list index.
With response mode = compact, things seem to be working as they were before, and at similar (if not faster) speed.
Thanks @Logan M for your help.
I'd nevertheless be interested to understand better the differences I am seeing...
I agree... I'm glad switching worked but some things to investigate there for sure