<![CDATA[思路讨论 专业方向RAG与工作流]]>传统RAG容易产生幻觉，同样一个问题，匹配的RAG结果可能不相同，不可100%复现结果。
Google提出的OKF格式可能是一个比较好的解决方式，顶部 YAML 标签强锁文件类型（如法律、案例），防止大模型瞎联想；正文用 Markdown 标题（PageIndex 骨架）与向量库（传统 RAG 血肉）网状互联。
在实际的任务，比如依据法律法规以及历史判例，做出工作流，让多agent参与，一个负责调度和分配任务，多个负责对应内容，一个agent负责审核，最终输出审查报告和改进意见。
这个思路的可行性如何？

]]>https://lcz.me/topic/714/思路讨论-专业方向rag与工作流RSS for NodeWed, 01 Jul 2026 08:03:38 GMTSat, 27 Jun 2026 06:41:52 GMT60<![CDATA[Reply to 思路讨论 专业方向RAG与工作流 on Mon, 29 Jun 2026 02:25:44 GMT]]>@kop-wang 法庭判决的决定性因素确实大量存在于文本之外:法官自由裁量习惯、本地司法惯例、庭审表现、程序博弈.这些与法条之间几乎没有统计学关联，RAG根本够不着。RAG正好是在解决”LLM上下文窗口有限”的工程问题，不是在解决"世界模型不完整”的认知问题。

]]>https://lcz.me/post/8717https://lcz.me/post/8717Mon, 29 Jun 2026 02:25:44 GMT<![CDATA[Reply to 思路讨论 专业方向RAG与工作流 on Mon, 29 Jun 2026 02:10:19 GMT]]>@566656661 人也会有幻觉，大脑天生就会欺骗，多一个求证的环节，就会排除幻觉。

]]>https://lcz.me/post/8714https://lcz.me/post/8714Mon, 29 Jun 2026 02:10:19 GMT<![CDATA[Reply to 思路讨论 专业方向RAG与工作流 on Mon, 29 Jun 2026 02:05:19 GMT]]>@kop-wang 在不考虑案外因素的前提下，给决策做辅助建议，基层的乃至很高层级的机关执法人员是很缺乏法律常识的，所以我觉得rag可以让在一个较小空间里的问题给出相对合理的建议，以便下决策。

]]>https://lcz.me/post/8713https://lcz.me/post/8713Mon, 29 Jun 2026 02:05:19 GMT<![CDATA[Reply to 思路讨论 专业方向RAG与工作流 on Sun, 28 Jun 2026 15:52:08 GMT]]>@ueli 关于法律相关这块，有没有可能是因为很大权重的影响因素其实都不在整个法律体系和流程框架内，导致其实LLM的上下文本来就是不完整的。从而导致统计学结果的失真。

Coding之所以效果比较好，除了可以做0成本验证回溯迭代以外，我个人理解，很大程度上是因为Coding的信息量是明牌的，而且收束在极其窄的区间以内。一个project，本质上所有的上下文都在这个文件夹下。外部都是知识，不决定整个project的执行结果和执行走向。

法律在我的理解来看恰恰相反。法条和整个司法流程的文书，反而是信息量最小的部分。有大量看似解耦，但实际又起决定性作用的信息量在外围。他们之间从文字本身上很难有统计学关系。
而这其实RAG也无法彻底解决。毕竟RAG是以为了LLM有限的上下文窗口而“精炼上下文”为本质目的的技术。它并不能解决"信息视野缺失"的问题。

还有一点，就是LLM本身后训练的审查和拒绝模块，对于法律这种相对敏感的内容也会起到很大的负面作用。

我认为这是法律领域Agent，乃至LLM失真的最本质因素。

]]>https://lcz.me/post/8672https://lcz.me/post/8672Sun, 28 Jun 2026 15:52:08 GMT<![CDATA[Reply to 思路讨论 专业方向RAG与工作流 on Sun, 28 Jun 2026 13:32:36 GMT]]>

@ueli 说:

所以我在考虑如何架构能够让llm不产生幻觉，从而辅助我进行决策。

只能說ueli大你說的這個應該很難...吧

幻覺就是llm的一部分, 能降低但不會變0

連編程這種這麽有規律性的東西都會出現, 個人覺得法律這邊也逃不過吧

]]>https://lcz.me/post/8665https://lcz.me/post/8665Sun, 28 Jun 2026 13:32:36 GMT<![CDATA[Reply to 思路讨论 专业方向RAG与工作流 on Sun, 28 Jun 2026 13:25:24 GMT]]>

@kop-wang 说:

坚守关键词、正则匹配。
所以目前的agent都是在coding领域有很好的表现，但是在有自由裁量权的领域，尤其是法律，表现是差强人意的，某律师使用豆包打官司导致职业资格证被吊销。
我的日常工作会有大量的法律条文应用，关键词和正则会有反效果，因为真实世界是考虑实际的适用性和合理性，这个是目前的llm或者agent不尽如人意的地方。
所以我在考虑如何架构能够让llm不产生幻觉，从而辅助我进行决策。

]]>https://lcz.me/post/8661https://lcz.me/post/8661Sun, 28 Jun 2026 13:25:24 GMT<![CDATA[Reply to 思路讨论 专业方向RAG与工作流 on Sun, 28 Jun 2026 13:01:52 GMT]]>@applejuice

沒有

以上說的都是RAG的設計思路

是不是真的有效其實都是要試驗過才知道, 所以到現在也沒有一個一刀切說某個類型的RAG會比另外一類差, 各有所長, 要慢慢試直到符合到自己的用處

]]>https://lcz.me/post/8654https://lcz.me/post/8654Sun, 28 Jun 2026 13:01:52 GMT<![CDATA[Reply to 思路讨论 专业方向RAG与工作流 on Sun, 28 Jun 2026 11:34:12 GMT]]>@applejuice Agent工具就是没什么定量的测试方法。毕竟LLM本身就有一定的容错能力。所以导致你的Agent工具最终起到正向还是负面效果其实很难客观评判。

我觉得RAG想证明比关键词、正则检索要更有效就很难。

]]>https://lcz.me/post/8645https://lcz.me/post/8645Sun, 28 Jun 2026 11:34:12 GMT<![CDATA[Reply to 思路讨论 专业方向RAG与工作流 on Sun, 28 Jun 2026 10:31:23 GMT]]>rag 有什么测试方法吗？
我搞了一下基本上能用.
但是你们说的我都不明白

]]>https://lcz.me/post/8638https://lcz.me/post/8638Sun, 28 Jun 2026 10:31:23 GMT<![CDATA[Reply to 思路讨论 专业方向RAG与工作流 on Sun, 28 Jun 2026 03:07:51 GMT]]>@566656661 编程不需要RAG，模型底座能力用好就足够，在编程场景中用RAG，多半是是架构烂，当然，这个观点很主观。我的意思就是，头部模型的写代码能力足够了，它们缺的就是架构设计能力。

]]>https://lcz.me/post/8612https://lcz.me/post/8612Sun, 28 Jun 2026 03:07:51 GMT<![CDATA[Reply to 思路讨论 专业方向RAG与工作流 on Sun, 28 Jun 2026 03:06:09 GMT]]>@terry

在Document RAG上認同, 但是Code RAG上應該各有千秋?

引用一下這個知乎大神的文章

工具 核心表示 索引位置 給 Agent 的介面 主要場景
CodeGraph tree-sitter AST → SQLite 圖 + FTS5 本地 MCP（10 個工具） Claude Code/Cursor/Codex 等 Agent 的探索加速
Aider repo map tree-sitter tags + PageRank 本地 拼接至 prompt 中 Aider 終端 pair programming
Cursor 內建索引 檔案分塊 → embedding 遠端 Turbopuffer + Merkle 樹同步 @Codebase Cursor IDE 內
Continue.dev tree-sitter 分塊 + embedding + FTS 本地 ~/.continue/index @Codebase / @Folder Continue IDE 外掛程式
Sourcegraph Cody SCIP（LSIF 後繼）+ embedding 遠端 Sourcegraph 實例 內建 + MCP server 企業程式碼搜尋
Augment Code 語意索引（專有 Context Engine） 遠端 MCP（遠端 HTTPS） 企業級 Agent，跨程式碼庫
Potpie.ai Neo4j 屬性圖 伺服器端（自行託管或 SaaS） FastAPI + 專用 Agent 企業 spec-driven 大型程式碼庫
Greptile 程式碼庫相依圖 遠端 SaaS PR review Agent AI code review
Bloop 語意搜尋 桌面／遠端 桌面 UI 自然語言程式碼搜尋
Repomix / Code2Prompt / yek 整庫拼接為長文本 本地 複製貼上 / MCP 供長上下文 LLM 進行一次性匯出
CodeQL 資料流 + 控制流 facts → Datalog 本地 QL 查詢 安全性分析／變異分析
Glean (Meta) 通用程式碼事實資料庫 + SCIP 輸入 伺服器端 Glass API Meta 內部 IDE／RAG
]]>https://lcz.me/post/8610https://lcz.me/post/8610Sun, 28 Jun 2026 03:06:09 GMT<![CDATA[Reply to 思路讨论 专业方向RAG与工作流 on Sun, 28 Jun 2026 02:36:16 GMT]]>@566656661 RAG的是有门槛的，不是个人随便玩得转的，无限上下文不太可能，但是可以通过构建只是文本数据库，而不是用RAG的方式来完成增强。就是RAG的性价比还不如本地文本检索增强。

]]>https://lcz.me/post/8604https://lcz.me/post/8604Sun, 28 Jun 2026 02:36:16 GMT<![CDATA[Reply to 思路讨论 专业方向RAG与工作流 on Sat, 27 Jun 2026 14:15:15 GMT]]>

@kop-wang 说:
如果正如LLM大厂吹的，26年内无限上下文实现，RAG瞬间就没有价值了。

這個我覺得應該是不太可能....吧

就算能用估計也不是一般人能用的

]]>https://lcz.me/post/8557https://lcz.me/post/8557Sat, 27 Jun 2026 14:15:15 GMT<![CDATA[Reply to 思路讨论 专业方向RAG与工作流 on Sat, 27 Jun 2026 13:48:14 GMT]]>目前的瓶颈还是“RAG输出的内容到底比正则、关键词检索强多少”这个话题。

目前行业通用开源的Agent，用RAG的属于少数。更多的还是坚守关键词、正则匹配。
RAG很难证明比正则+关键词强，尤其是在目前LLM在卷上下文最大长度这个情况下。

如果正如LLM大厂吹的，26年内无限上下文实现，RAG瞬间就没有价值了。

]]>https://lcz.me/post/8542https://lcz.me/post/8542Sat, 27 Jun 2026 13:48:14 GMT