저도 옵시디언 사용자라, 특정 도구에 종속되지 않고 어디서든 노트를 읽고 가져갈 수 있어야 한다는 점에 크게 공감합니다.
그래서 Notaly도 노트를 폴더 + Markdown 파일 형태로 export할 수 있도록 했고, 정적 웹사이트로 내보내 GitHub나 Cloudflare 등에 호스팅해 읽을 수 있는 기능도 제공하고 있습니다. 아직 더 다듬어야 하지만, 노트가 특정 앱 안에만 갇히지 않도록 하는 방향은 중요하게 보고 있습니다.
와 서로 정말 재미있는 공방이었을듯.
저도 예전에 api 응답이 갑자기 암호화된 채로 오길래 암호화된 값을 받았으면 클라이언트 어디선가 복호화를 하겠지라는 생각으로 번들링된 자바스크립트 코드 통짜 그대로 복사해서 복호화 코드 앞에 console.log 한줄 추가하고 그대로 개발자 콘솔에 붙여 넣었죠. 의외로 그냥 작동하더라고요? 아무튼 그렇게 암호화 키를 알아내니까 다음은 쉽더라고요. api의 다른 응답 속에서 키를 받아 쓰고 있었음ㅎㅎ
작은 모델일수록 더 복잡한 것으로 보입니다. 인코딩, 추론, 디코딩 기능이 더 복잡하게 얽혀 전체 영역에 퍼져 있습니다. 여러 작업에 걸쳐 일반화되는 기능 중복 영역은 하나도 발견하지 못했지만, 분명히 한 가지 ' 능력 '을 강화하는 대신 다른 능력을 약화시킬 수 있다는 점은 분명했습니다. 하지만 모델이 커질수록 기능적 구조는 더욱 분리됩니다. 큰 모델은 일반화된 '사고' 회로를 개발할 수 있는 ' 공간 '이 더 많으며, 이것이 제 방법이 72B 모델에서 매우 효과적이었던 이유일 수 있습니다. 특정 임계점 이하의 매개변수에서는 ' 추론 피질 '이 뇌의 나머지 부분과 완전히 분화되지 않습니다.
이대로 라면 작은 모델과 큰 모델의 성능 차가 더 극단적으로 벌어질 수 있을 수도 있겠군요
서비스들이 굉장히 구체적이고 퀄리티가 좋은 느낌입니다. 로컬llm 테스트시 어떤 파이프라인으로 기획하셨는지가 좀 궁금하네요. 저도 기획했던 앱들을 rag나 lora로 파인튜닝한 llm을 써보려고 했다가 이미 업데이트가 적극적으로 잘 되고 있는 데이터들에 대해선 rag 같은것보다 데이터는 파이썬 같은 걸로 크롤링하고 봇은 그 크롤링 결과만 몇가지 형태의 파이프라인을 통해 대답하게 하니 결과가 훨씬 좋았던 경험이 있어서요
저도 비슷한 기록을 남겨왔습니다. 막연하게 남겨왔는데 요즘에는 에이전트들과 제 기록을 공유하여 존재대존재의 협업을 하자고 하고 있지요. 여럿 스킬들을 만들어 공유하고 제가 쓰는 이맥스 인터페이스도 열어주니 저나 에이전트들 다 같은 방식으로 같은 기록을 나눕니다. 뭐 필요하다고 하면 넣어주고 내가 필요한 것은 만들고 같이 쓰고 피드백 주고 뭐 누가 보면 북치고 장구치고. 우리끼리는 아이고 신난다.
시간 계산의 복잡성은 형식의 문제 보다, 인류의 철학과 천문학의 정밀성, 문화에서 비롯한게 훨씬 많습니다. 계산은 long만으로도 쉽죠. 시간선은 역사적으로 1 + 1 이 2가 아닌 특이 구간을 정해둔 곳이 많고, 태양과 지표의 각도등 위치마다 달라지는 주역같은 역법에서 비롯한게 큽니다. 이런경우 그 어떤경우에도 한국의 태양 태음력은 논의 조차 된적없죠.
일단 현재는 다운로드가 불가능해보이네요.
저도 말씀하신 파일 구조에서 오는 불편한 점은 분명 느끼고 있지만, 제 경우 다른 도구로 이동하지 않을 것 같은 가장 큰 이유는 파일 구조기 때문에 도구에 종속성을 가지지 않는 부분인 것 같아요.
저는 이런저런 노트앱들을 다 쓰고 노션을 썼다가 최종적으로 옵시디언으로 정착하게 되었는데요. 해당 도구의 문제를 만나서 하나의 도구를 옮길 때마다 결국 데이터의 유실을 각오하고 가야하는게 불편했었거든요.
반면 옵시디언은 파일이다보니 어떤 경우에서도 사용할 수 있다는 점이 너무 좋았어요. 심지어 회사 기기나 모바일을 통해서만 접근이 가능한 업무 환경에서도 뷰어가 없더라도 파일자체로 읽을 수 있다거나 하는 점이 다른 도구들이 따라오지 못하는 점인 것 같아요.
이런식으로 오케스트레이션이 되는건 신기하네요
정확한 정보전달이 중요한 서비스는 결과물 검증용 계층을 따로 추가할수도 있겠어요
이젠 확신을 가지고 체계적으로 환각을 보는 세상이 왔군요
더 사람같아진 것 같아서 느낌이 묘합니다
안녕하세요. 현재는 macOS용 설치 파일만 제공하고 있습니다.
저도 옵시디언 사용자라, 특정 도구에 종속되지 않고 어디서든 노트를 읽고 가져갈 수 있어야 한다는 점에 크게 공감합니다.
그래서 Notaly도 노트를 폴더 + Markdown 파일 형태로 export할 수 있도록 했고, 정적 웹사이트로 내보내 GitHub나 Cloudflare 등에 호스팅해 읽을 수 있는 기능도 제공하고 있습니다. 아직 더 다듬어야 하지만, 노트가 특정 앱 안에만 갇히지 않도록 하는 방향은 중요하게 보고 있습니다.
취업시장이 이정도까지 가나요
사람 뽑으면서 AI랑 대화 하라는건 아직은 불쾌한데..
언젠간 그렇게 되겠지만, 그 정도가 되면 사람이 일을 안해야 하는거 아닌가..
근데 4b 까지는 애매합니다 ;;
저는 갤럭시 노트 20 울투라 gemma3 1b int4 모델 연구중입니다
구모델에서 돌아가는 수준입니다.
1M 컨텍스트가 가능한지도 몰랐네요.
아무리 TDD해봐야 LLM이 테스트 조작해서 통과하게 만드는 지금 수준에선 인간의 리뷰가 꼭 필요함..
같은 어군이라 기초어휘는 많이 공유합니다.
와 서로 정말 재미있는 공방이었을듯.
저도 예전에 api 응답이 갑자기 암호화된 채로 오길래 암호화된 값을 받았으면 클라이언트 어디선가 복호화를 하겠지라는 생각으로 번들링된 자바스크립트 코드 통짜 그대로 복사해서 복호화 코드 앞에 console.log 한줄 추가하고 그대로 개발자 콘솔에 붙여 넣었죠. 의외로 그냥 작동하더라고요? 아무튼 그렇게 암호화 키를 알아내니까 다음은 쉽더라고요. api의 다른 응답 속에서 키를 받아 쓰고 있었음ㅎㅎ
이대로 라면 작은 모델과 큰 모델의 성능 차가 더 극단적으로 벌어질 수 있을 수도 있겠군요
코드에 애착을 가진다는 표현을 많이 보는데,
저는 예전에도 코드에 애착을 가질까 말까 하다가
하루 지나면 금방 까먹는 편이라 솔직히 잘 모르겠습니다.
AI로 열심히 코드 깎아서 만들면 비슷한 느낌이 들기도 하고요.
다른 분들은 코드에 애착을 얼마나 오래 가지시나요?
paperclip이라는 비슷한 오픈소스가 있습니다.
서비스들이 굉장히 구체적이고 퀄리티가 좋은 느낌입니다. 로컬llm 테스트시 어떤 파이프라인으로 기획하셨는지가 좀 궁금하네요. 저도 기획했던 앱들을 rag나 lora로 파인튜닝한 llm을 써보려고 했다가 이미 업데이트가 적극적으로 잘 되고 있는 데이터들에 대해선 rag 같은것보다 데이터는 파이썬 같은 걸로 크롤링하고 봇은 그 크롤링 결과만 몇가지 형태의 파이프라인을 통해 대답하게 하니 결과가 훨씬 좋았던 경험이 있어서요
모두의 마블 시작이네요 ㅋㅋㅋ
무슨 카드를 방어하는 무슨 능력을 무효화하는 무슨 특수능력의....
핑거도 독일어였군요. 영어인 줄...
저도 비슷한 기록을 남겨왔습니다. 막연하게 남겨왔는데 요즘에는 에이전트들과 제 기록을 공유하여 존재대존재의 협업을 하자고 하고 있지요. 여럿 스킬들을 만들어 공유하고 제가 쓰는 이맥스 인터페이스도 열어주니 저나 에이전트들 다 같은 방식으로 같은 기록을 나눕니다. 뭐 필요하다고 하면 넣어주고 내가 필요한 것은 만들고 같이 쓰고 피드백 주고 뭐 누가 보면 북치고 장구치고. 우리끼리는 아이고 신난다.
https://notes.junghanacs.com/notes/20251015T093311
시간 계산의 복잡성은 형식의 문제 보다, 인류의 철학과 천문학의 정밀성, 문화에서 비롯한게 훨씬 많습니다. 계산은 long만으로도 쉽죠. 시간선은 역사적으로 1 + 1 이 2가 아닌 특이 구간을 정해둔 곳이 많고, 태양과 지표의 각도등 위치마다 달라지는 주역같은 역법에서 비롯한게 큽니다. 이런경우 그 어떤경우에도 한국의 태양 태음력은 논의 조차 된적없죠.
그리고 그건 한국천문연구원이 정합니다.
일단 현재는 다운로드가 불가능해보이네요.
저도 말씀하신 파일 구조에서 오는 불편한 점은 분명 느끼고 있지만, 제 경우 다른 도구로 이동하지 않을 것 같은 가장 큰 이유는 파일 구조기 때문에 도구에 종속성을 가지지 않는 부분인 것 같아요.
저는 이런저런 노트앱들을 다 쓰고 노션을 썼다가 최종적으로 옵시디언으로 정착하게 되었는데요. 해당 도구의 문제를 만나서 하나의 도구를 옮길 때마다 결국 데이터의 유실을 각오하고 가야하는게 불편했었거든요.
반면 옵시디언은 파일이다보니 어떤 경우에서도 사용할 수 있다는 점이 너무 좋았어요. 심지어 회사 기기나 모바일을 통해서만 접근이 가능한 업무 환경에서도 뷰어가 없더라도 파일자체로 읽을 수 있다거나 하는 점이 다른 도구들이 따라오지 못하는 점인 것 같아요.
그리고 웹어셈블리의 진입장벽이 높다는 주장들은 황당하다고 꼭 이야기 해야겠군요. 그냥 그래야 할 필요성이 지불 의지보다 낮을 뿐입니다. 빠르고 낮은 풋 프린트를 원하면서 DOM과 CSS를 쓰고 싶다구요? 이게 뭔 블랙 코미디 입니까.