Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request / Question: Allow configuration to connect only to notes and not blocks #544

Open
ramarivera opened this issue Apr 16, 2024 · 3 comments

Comments

@ramarivera
Copy link

One thing I noticed is that the plugin created multiple connections to the same note, since it was connecting to actually different blocks.

For example,

This makes it that when I chat with note A, I get multiple times the same context from note B, which "takes connection space" from other notes I would love to be included in the context (e.g. I would like to have connections to C and D, but since B is taking multiple connection slots, I cannot).

WDYT about allowing only notes to be connected, thro a config param?

@brianpetro
Copy link
Owner

Hey @ramarivera

Adding filters to the Smart View will be added in a later version. I imagine one of the filters would be something like "exclude blocks."

In the meantime, you could try setting "Blocks Embedding Model" to "None" in the settings. This will limit the Smart View to showing links to notes only.

🌴

@ramarivera
Copy link
Author

Interesting suggestion! I will give it a try :)

@chrisfurlong-aiwyn
Copy link

I agree with the request in this note. I don't want to exclude blocks, as a block should be prioritized over a note as it's more narrowly focused and less likely to bloat the context.

I just don't want duplicate content.. Each block should know it's parent, right? If a block is going to be included, then any other "chunk" that has the ID of the parent should be eliminated from consideration.

I'd even go as far as to say I prefer the opposite. I'd rather focus on more on just blocks than notes. Short notes probably aren't an issue, but lengthier notes are decomposed into blocks for good reason and we should leverage them accordingly. For a particularly lengthy note, the embedding will blur the meaning and even if retrieved, potentially trigger the 'needle in a haystack' problem

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants