feat: documents contribute to the knowledge graph
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 28/100
Hướng nghiên cứu
Start by reading ExtractKnowledgeUseCase, InferenceScheduler, PromptBudget, and RagPipeline to understand the existing note extraction and retrieval paths. Work out how document identity and long inputs should be handled before implementation; the issue leaves both open. Done means a document is extracted once per document, participates in graph expansion, and long inputs are handled without silent truncation.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Notes participate in a knowledge graph — e tags are edges, t tags are topic nodes, and ExtractKnowledgeUseCase pulls entities and relations that feed graph expansion during retrieval. A document's chunks participate in none of it. They are retrieved by vector similarity alone, then explicitly skip graph expansion and memory lookup, because a chunk is not a graph node (RagPipeline).
So a PDF that is entirely about a topic the user has notes on contributes nothing to the graph around that topic, and a question answered from the graph never reaches the document.
What to build
Let a document contribute to the graph — one extraction pass per document, not per chunk.
Per-chunk extraction is the wrong shape and worth stating plainly: a long PDF is dozens of chunks, each pass is an LLM call on a device already contending for the model with chat and Gana, and chunk boundaries cut mid-argument so the extracted relations would be worse than from whole text. Document-level extraction is one call over the joined text, which is also what the existing note path already does.
Pointers:
ExtractKnowledgeUseCaseis the existing extraction path; the question is whether it generalises or needs a document-shaped siblingInferenceSchedulerhas a T2 extract tier — document extraction belongs there, not on the chat pathPromptBudgetcaps what one call can carry; a long document will not fit in one pass on the smallest local model, so this needs a real answer for long inputs rather than silent truncation
Open questions
- What is a document's node identity in the graph? The attaching note, or the document itself? A document can be attached to more than one note.
- Does a not-searchable scan get any graph presence at all?
Part of #228 · Feature it follows from: #226
Status: backlog (2026-10-13)
Not feasible to do well with on-device compute today, so this is parked. The reasoning is in the comment below; the short version: local models cap one call at 1k-8k tokens (PromptBudget), a PDF is 10k-100k+, and every workaround (truncate, per-chunk calls, map-reduce) is either wrong or too expensive on a phone that is already contended. Revisit when local context and throughput improve, or when UNIUN Cloud is the default for extraction.
Options to consider later (no LLM call, not built)
- Attachment edge. A document is already attached to a note. Treat that as a graph edge so expansion reaching the note brings its document's top chunks. Zero cost; overlaps with #236.
- Vector-derived related edges. At index time compare a document's chunk vectors (or centroid) to existing note vectors and store the top matches as note-document edges. A few dot products, no model call.
- Non-LLM topic nodes. RAKE or TF-IDF keyphrases over the already-extracted text become topic nodes, the way
ttags do for notes. - Cloud-only extraction, opt-in. A single full-document pass is realistic only with a large cloud context window. Gate on
LlmBackendType.uniunCloud; needs a privacy note since document text leaves the device.
Still to answer before building any of these: is a document's node identity the attaching note or the document itself (it can be attached to several notes), and does a not-searchable scan get any graph presence?
- Ngôn ngữ chính
- Dart
- Star
- 2
- Fork
- 2
- Merge trung bình
- 1 ngày 35 phút
- Pull request đã merge (30 ngày)
- 36
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của basictech01/uniun
-
bug good first issue
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
basictech01/uniun#300 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug good first issue
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 52/100
basictech01/uniun#301 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
enhancement good first issue P2-Medium
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
basictech01/uniun#296 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug good first issue P2-Medium
Độ khó 4/5 1-2 ngày Mức phù hợp với người mới 22/100
basictech01/uniun#293 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug P1-High
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 18/100
basictech01/uniun#286 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của basictech01/uniun
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày
-
good-first-issue P3
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
flutter/dart-intellij-third-party#758 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Bug: Incorrect location coordinates on logged Sound Meter dataCó thể đã có người làm @Jashan32 đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
area/archive bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
DarkFlippers/qUnleashed#374 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
agent:in-progress agent:ready feature P2 · 中 区域: 悬浮窗
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
ASDW51/DanmuFloat#178 ·
Maintainer thường phản hồi trong vòng 1 ngày