Find answers from the community

s
F
Y
a
P
Updated 2 years ago

Is there any advice on good ways to

Is there any advice on good ways to compose indices? The documentation shows a list index on top of tree indices, but not sure if that's the best way. In my case, I have two types of documents. I have about 200 documents of each type, about 20 pages each on average. I was thinking of wrapping each document in it's own list index to force the model to use the entire document. Then, I'd probably put all the documents into two vector or tree indices (one for each type), and then a list index on top of the two vector/tree indices to force the model to look at both types of documents. Any thoughts on better ways to compose would be greatly appreciated.
j
f
13 comments
hey out of curiosity which documentation shows composing a list index on top of tree indices?
for your use case a list index per document makes sense (as long as each doc isn't too long!). and then a vector index on top of the list indices makes sense too
what are the type sof documents that you have?
what you're describing makes sense at a high-level - i would just watch out for speed/cost, because the more connections you make, the larger the latency
This page shows a list on top of a tree
The documents are legal cases, and scholarly articles
That's why I want to separate them into two vector indices
ahhh got it i see. yeah that's mostly for illustrative purposes
makes sense! if you don't care about whether we only synthesize information from one source or multiple, put them into one vector index. if you explicitly want to synthesize information across indices, list index on top of two vector indices makes sense
What do you think about wrapping each document in a list index? Cost issues aside, would this improve performance?
i think so! you can try setting response_mode="tree_summarize" when querying the list index - it'll explicitly go through every node
Add a reply
Sign up and join the conversation on Discord